Domanda:
La scelta dell'algoritmo di crittografia non aggiunge di per sé entropia?
Robert
2019-01-30 17:22:18 UTC
view on stackexchange narkive permalink

Diciamo che qualcuno ha i miei dati crittografati e vuole decrittarli. La gente parla sempre di come la lunghezza della chiave (ad esempio 256 bit) decide dell'entropia della crittografia, il che ha perfettamente senso. Se l'aggressore prova tutte le 2 256 possibilità, il suo grande-grande- ... -nonno avrà i miei dati.

Ma cosa succede se per tutti gli anni ha usato l'algoritmo sbagliato ? La scelta dell'algoritmo stesso non aggiunge anche l'entropia o mi sbaglio? Quindi, invece di nominare il mio file super_secret.aes256 lo chiamerei semplicemente super_secret.rsa256 o forse non gli darei nemmeno un file che termina?

Supponiamo che ci siano 8 cifrari tra cui scegliere nel 2019 con chiavi a 256 bit e che non ci fosse modo per un utente malintenzionato di guardare il testo cifrato e dire quale tipo di algoritmo è stato utilizzato, quindi la tua scelta di algoritmo segreto è l'aggiunta di log2(8) = 3 bit di entropia.Questo è un rumore trascurabile rispetto ai 256 bit della chiave.
@MikeOunsworth Vale anche la pena considerare che alcuni cifrari potrebbero richiedere più tempo per essere applicati, ma in realtà la maggior parte dei formati di crittografia dicono esplicitamente quale cifrario viene utilizzato comunque.
Non potresti usare un attacco a canale laterale per scoprire se si trattava di un algoritmo a chiave simmetrica o a chiave pubblica?
C'è un caso in cui questo è utile, lo schema di crittografia è stato creato da te e non hai mai rivelato il design anche se è difficile da ottenere.Di quanto è quasi impossibile da rompere.
@kelalaka se tu o io (o chiunque abbia meno di diversi decenni nel campo con ampie revisioni tra pari) abbiamo inventato il nostro schema di crittografia, è praticamente certo che [sarebbe così debole] (https://crypto.stackexchange.com/q / 43272/17796) verrà crackato in dozzine di modi che sono mooolto più veloci del bruteforcing.
@Matija Nalis, la crittografia è più della semplice applicazione di codici.Inventare un codice richiede ricerche, calcoli e conoscenze approfonditi."Inventare la propria crittografia" significa pensare a come combinare gli strumenti esistenti per proteggere le proprie comunicazioni.Include dettagli come il modo in cui le chiavi vengono scambiate, se le chiavi hanno tempi di scadenza, chi nell'organizzazione è autorizzato a certificare le chiavi, quali crittografie devono essere utilizzate, cosa succede se i servizi non possono fidarsi l'uno dell'altro ...
@sleblanc Certo, ma anche quando usi solo cifrari sicuri conosciuti, ci sono [molti] (https://en.wikipedia.org/wiki/HMAC#Design_principles) [di] (https://crypto.stackexchange.com/a / 205/17796) [insidie] (https://research.swtch.com/openssl) per le persone non ampiamente sul campo.(Inoltre, questa domanda riguardava esclusivamente i codici, non PKI o altri problemi che potresti avere nel mondo delle criptovalute)
Cerca [BassOmatic] (https://en.wikipedia.org/wiki/BassOmatic).
Sette risposte:
#1
+93
John Deters
2019-01-30 20:05:41 UTC
view on stackexchange narkive permalink

Se stai progettando un sistema crittografico, la risposta è No . Il principio di Kerckhoffs afferma "Un sistema crittografico dovrebbe essere sicuro anche se tutto ciò che riguarda il sistema, tranne la chiave, è di dominio pubblico". Ribadito come la massima di Shannon, ciò significa che "si dovrebbero progettare sistemi partendo dal presupposto che il nemico acquisirà immediatamente piena familiarità con essi".

Assumere che l'attaccante non apprenda il tuo algoritmo è security through obscurity, un approccio alla sicurezza considerato inadeguato.

Affidarsi all'aggressore per non conoscere l'algoritmo non aggiungerà alcun lavoro da parte sua, perché secondo Kerckhoff, lui o lei lo sa, o ci si può ragionevolmente aspettare che lo scopra. Se non aggiunge incertezza, non aggiunge entropia. E le loro capacità non sono qualcosa che puoi quantificare.

Nel caso di un criptosistema perduto, come descrivi, di solito ci sono abbastanza informazioni storiche o statistiche per determinare la natura dell'algoritmo (se non la chiave stessa). Ma non puoi progettare un sistema presumendo che andrà perso non appena verrà utilizzato. Questo è OpSec, non crittografia.

MODIFICA I commenti hanno menzionato l'utilizzo della selezione dell'algoritmo come parte della chiave. Il problema con questo approccio è che la selezione dell'algoritmo deve necessariamente essere determinata prima della decrittografia dei dati. Questo è esattamente il modo in cui oggi funzionano i protocolli come TLS.

Se stai veramente cercando di mescolare insieme gli algoritmi e utilizzare un fattore della chiave per determinare cose come la selezione S-box, ecc., stai effettivamente creando un singolare nuovo algoritmo (adottando tutto il bene rischi noti che comporta il rollio del tuo algoritmo.) E se hai creato un nuovo algoritmo, allora tutti i bit della chiave fanno parte di quel calcolo dell'entropia. Ma se puoi indicare bit specifici che determinano l'algoritmo invece del materiale chiave, devi comunque trattarli come bit di protocollo ed escluderli.

Per quanto riguarda la segretezza degli algoritmi, il tuo protocollo potrebbe essere segreto oggi, ma se uno dei tuoi agenti viene scoperto e il suo sistema viene copiato, anche se nessuna chiave è compromessa, i vecchi messaggi non utilizzano più algoritmi segreti. Qualsiasi "entropia" che potresti aver loro attribuito è persa e potresti anche non saperlo.

Non è sicurezza attraverso l'oscurità.Non è "fare affidamento sulla segretezza del progetto o dell'implementazione come metodo principale per fornire sicurezza".Potresti usare lo stesso ragionamento per sostenere che supporre che l'attaccante non trovi la tua chiave privata è sicurezza attraverso l'oscurità.Non ha molto senso preoccuparsi dell'entropia aggiunta dalla scelta dell'algoritmo, perché puoi comunque ottenere abbastanza entropia dalla chiave.
@FINDarkside "_Potresti usare lo stesso ragionamento ..._" La differenza è che, data una corretta gestione delle chiavi, un aggressore non dovrebbe mai essere in grado di elaborare la tua chiave privata.Tuttavia, devi presumere che abbiano l'opportunità di scoprire sempre più dettagli di implementazione, ad esempio attraverso il reverse engineering del codice.
@FINDarkside, il richiedente sta chiedendo se la segretezza dell'implementazione aggiunge entropia.In altre parole, sta chiedendo specificatamente se la sicurezza attraverso l'oscurità debba essere presa in considerazione nell'equazione.La risposta è no in parte perché non c'è modo di quantificare le capacità dell'autore dell'attacco a questo riguardo.Hai ragione sul fatto che tutta l'entropia deve provenire dalla chiave.
È necessaria l'energia per ottenere le informazioni sull'algoritmo, che si tratti di intelligenza umana, ingegneria inversa o ingegneria sociale, puoi fattorizzare una stima di questa energia con l'energia media richiesta per aggirare plausibilmente il tuo algoritmo una volta che hanno quella conoscenza.E forse in certi contesti questo può essere usato per esprimere un giudizio sulla sicurezza in un'organizzazione.Da un contesto di scienza dell'informazione, come fai notare, * Crittografia * questo è fuori ambito e non quantificabile.
Volevo sottolineare l'aspetto "sicurezza dall'oscurità" di questo, ma vedo che hai già trattato quel punto.+1 da me.
@TripeHound Stai assumendo che la scelta dell'algoritmo sia un dettaglio di implementazione che può essere scoperto o decodificato.Potrebbe anche essere un input per il processo di crittografia / decrittografia (ad esempio, l'utente seleziona l'algoritmo ogni volta da un elenco).In questo caso, la scelta dell'algoritmo diventa effettivamente * parte * della chiave.EDIT: ho appena notato che in effetti hai pubblicato una risposta a questo effetto.Lascio questo commento poiché questa risposta non ha tenuto conto di questa possibilità e IMO è sbagliato come scritto."No" dovrebbe leggere "dipende".
@FINDarkside Il problema è che non puoi proteggere gli algoritmi nello stesso modo in cui puoi proteggere la chiave.La chiave può essere omessa dal sistema (memorizzata separatamente o anche archiviata solo nella memoria di una persona), ma l'algoritmo non può (supponendo che non permettiamo all'utente di caricare la propria tramite codice arbitrario).Un utente malintenzionato avrà almeno lo stesso accesso all'algoritmo di un utente legittimo, probabilmente di più.
@jpmc26 La domanda non menziona alcun server o sistema live.Se ho una quantità di dati, non posso semplicemente "scoprire" l'algoritmo perché Kerckhoff ha detto che dovresti presumere che posso.
@FINDarkside Gli utenti legittimi devono avere accesso o conoscenza dell'algoritmo indipendentemente dal fatto che si tratti di un sistema live.Il principio di Kerchoff non è un'affermazione definitiva che l'attaccante scoprirà sempre l'algoritmo.È una regola pratica che dovresti presumere che lo faranno perché gli aggressori sono, in pratica, ** molto più ingegnosi e intelligenti ** di quanto pensi che saranno.Gli aggressori sono * molto bravi * a ricavare informazioni che non pensi possano, ad esempio determinare l'algoritmo dall'analisi dei dati crittografati.La chiave, tuttavia, può sempre essere separata dall'algoritmo e protetta.
@jpmc26 Sembra che tu stia facendo delle supposizioni su questo "sistema".Esistono scenari in cui l'algoritmo è "separato" quanto la chiave privata, supponendo che l'aggressore non fosse già infiltrato nel sistema quando il file è stato crittografato.Non penso che abbia senso discuterne però.
@FINDarkside Senza alcuni presupposti di base, non puoi nemmeno avere una discussione.Mi sembra che tu non voglia nemmeno avere una discussione, ma sei qui a discuterne.Ci sono dati.Vive da qualche parte.L'algoritmo è intrinsecamente legato ai dati crittografati in un modo in cui la chiave non lo è.È legato al formato * di input / output *, ad esempio, noto a un utente malintenzionato che ha ottenuto i dati.
@FINDarkside, credo di capire da dove vieni.Stai considerando uno scenario di "messaggio perso", privo di contesto o informazioni al riguardo.Stai anche valutando la segretezza, forse anche per evitare di essere scoperto.Questi sono attributi di OpSec e possono assolutamente aiutare ad aumentare la sicurezza generale.Ma poiché non sono determinati matematicamente, non possono essere presi in considerazione in un calcolo dell'entropia.Pensala in questo modo: la tua sicurezza complessiva include l'entropia del tuo algoritmo come componente, ma la sicurezza complessiva non è misurata dall'entropia, è misurata dal rischio.
@JohnDeters Ok ho capito ora, scusa per la confusione.
Gli algoritmi @jpmc26 NSA Suite A sono tutti classificati e, per quanto ne so, nessuno è trapelato.La mia comprensione è che sono spesso implementati in software azzerato in caso di manomissione.Un aspetto è che evita con successo il controllo accademico, quindi i college non stanno facendo il lavoro di intelligence straniera per loro.
@jpmc26 Penso che tu stia parlando di mele (l'algoritmo) mentre l'OP sta parlando di arance (la * scelta * dell'algoritmo).L'implementazione deve contenere gli algoritmi effettivi (e sono quindi rilevabili da un utente malintenzionato) ma la * scelta * di quale algoritmo utilizzare può rimanere nella testa dell'utente, proprio come la chiave.
@FINDarkside Nella tua citazione hai perso la fine che la mette in relazione con "un sistema _o un componente di un sistema_".Direi che se la tua barriera all'ingresso per coinvolgere un criptosistema è che hai nascosto quale algoritmo è in uso, allora hai impiegato la sicurezza dall'oscurità per quella parte di esso.Ora, gli altri tuoi "componenti" potrebbero non essere sensibili a questo, ma si può almeno aggirare uno "strato" del sistema scoprendo un fatto.
#2
+47
TripeHound
2019-01-30 20:49:59 UTC
view on stackexchange narkive permalink

In termini pratici, no, come spiega chiaramente la risposta di John.

Ipoteticamente, se avessi abbastanza metodi di crittografia sicuri tra cui scegliere, potrebbe potenzialmente selezionare un metodo a caso e utilizzarlo per crittografare i dati utilizzando, ad esempio, una chiave a 256 bit. La scelta dell'algoritmo utilizzato dovrebbe essere "aggiunta" alla chiave e diventare parte del " segreto da non rivelare " (portando l'entropia combinata a 259 bit se ci fossero otto algoritmi di crittografia da scegliere tra).

I problemi con questa operazione includono:

  • Viene aggiunto solo un piccolo numero di bit: otto algoritmi aggiungono solo tre bit di entropia. Per aggiungere otto bit (per un totale di 264 bit con una chiave a 256 bit) sarebbero necessari 256 diversi algoritmi di crittografia. Trovare abbastanza algoritmi sicuri per fare una differenza pratica è quasi certamente molto più difficile che estendere semplicemente la lunghezza della chiave di un singolo algoritmo noto all'attaccante.

  • Devi "estendere" la chiave con la scelta dell'algoritmo: questo significa passare la scelta all '"utente" per essere "ricordato" accanto alla chiave normale. Ciò complica notevolmente il processo di gestione delle chiavi. Memorizzare la scelta nei dati crittografati non è un inizio, poiché un utente malintenzionato con "conoscenza totale" sarebbe in grado di trovare le informazioni e sapere quale algoritmo utilizzare.

  • Se uno qualsiasi degli algoritmi scelti lascia una sorta di "impronta digitale" che consente a un utente malintenzionato di identificare l'algoritmo utilizzato (o almeno di ridurre la gamma di possibili algoritmi), quindi questo annullerà (parzialmente) i bit extra di entropia.

Nel complesso, è molto più facile estendere la lunghezza della chiave utilizzata e non preoccuparti che un utente malintenzionato conosca il metodo di crittografia.

Per peggiorare le cose, è necessario inventare in qualche modo i bit utilizzati nella selezione dell'algoritmo.Se si dispone di un algoritmo che può utilizzare una chiave a 256 bit e si ha effettivamente 256 bit di entropia, la probabilità di compromesso per entropia insufficiente sarà essenzialmente zero.Se non si hanno 256 bit di entropia reale, prendere l'entropia che avrebbe potuto essere utilizzata per la generazione della chiave e usarla per la selezione dell'algoritmo non migliorerà nulla.
Suppongo che se vuoi essere davvero pedante riguardo alla domanda, * potresti * consentire agli utenti di caricare i propri algoritmi piuttosto che scegliere da un elenco predefinito.Ma gli svantaggi associati all'esecuzione di codice arbitrario, il fatto che la maggior parte degli utenti non sceglierebbe un algoritmo sicuro e la maggiore difficoltà nella gestione dell'utente superano ovviamente i vantaggi.
Un'interpretazione del principio di Kerckhoffs è che le informazioni che devono essere tenute segrete ** comprendono ** la chiave, che è ciò che stiamo dicendo qui.Quindi una scelta di algoritmo da un set fisso di 8 richiede 3 bit extra nel tuo archivio chiavi.Una scelta di algoritmo che hai codificato aggiunge una quantità molto maggiore all'archivio delle chiavi (almeno l'entropia di Shannon del codice).Non è un ottimo rapporto qualità-prezzo.
#3
+11
Conor Mancone
2019-01-31 02:06:06 UTC
view on stackexchange narkive permalink

Le risposte di @John Deter e @TripeHound spiegano le cose molto bene, ma volevo fornire un esempio che mettesse in contesto il principio di Kerckhoffs. È naturale affrontare queste domande dal punto di vista di un aggressore esterno, ma non è l'unico modello di minaccia rilevante. In effetti, circa la metà di tutte le violazioni dei dati parte da agenti interni (ovvero dipendenti, appaltatori, ecc ...), con un mix di perdite accidentali e intenzionali.

Vettori di minacce più realistici

Avere un algoritmo di crittografia nascosto può aiutare contro un aggressore esterno se non riesce a dedurre facilmente quale sistema hai utilizzato. Tuttavia, non fornisce assolutamente alcuna protezione aggiuntiva contro un utente malintenzionato interno che ha accesso al tuo codice. Ad esempio, se il tuo sistema conserva informazioni di identificazione personale (PII) critiche nel tuo database, ma entrambe le credenziali di accesso al database di produzione, gli algoritmi di crittografia e le chiavi di crittografia sono archiviate direttamente nel tuo repository di codice, allora hai effettivamente dato a tutti coloro che hanno accesso al tuo repository di codice l'accesso a tutte le PII dei tuoi clienti.

Ovviamente non vuoi farlo, quindi mantieni i sistemi di produzione separati da tutti quelli che ti aspetti dagli amministratori, mantieni le chiavi di crittografia archiviate in un sistema di gestione delle chiavi accessibile (per quanto possibile) solo all'applicazione, ecc ... I tuoi sviluppatori sanno quali algoritmi di crittografia vengono utilizzati (perché possono vederli nel repository del codice), ma non hanno accesso al database di produzione e anche se avessero ottenuto l'accesso in lettura al database, non avrebbero le chiavi per decrittografare i dati presenti.

Applicazione del principio di Kerckhoff

Questo è il punto centrale del principio di Kerckhoffs: l'unica cosa che devi mantenere segreto è il vero segreto (ovvero la tua chiave di crittografia). Tutto il resto può essere conosciuto da tutti e sei comunque al sicuro. Il che è positivo, perché mantenere un solo segreto è già abbastanza difficile. Cercare di ideare un sistema che nasconda non solo le chiavi ma anche gli algoritmi di crittografia e altri dettagli al maggior numero di persone possibile è un po 'più difficile e più incline al fallimento.

In breve, le persone non sono brave a mantenere il segreto. Di conseguenza, progettare il tuo sistema in modo da avere meno segreti da mantenere in realtà ti rende più sicuro, anche se sembra controintuitivo. Dopo tutto, ciò che suggerisci ha senso a un certo livello: perché dovremmo crittografare solo i nostri dati? Nascondiamo anche il metodo di crittografia e siamo più sicuri! In pratica, però, nascondere più cose ti dà più spazio per commettere errori e un senso di falsa sicurezza. È molto meglio utilizzare un metodo di crittografia efficace che renda la conservazione dei segreti il ​​più semplice possibile: nascondi la chiave e il messaggio è al sicuro.

#4
+8
Christoph Burschka
2019-01-31 22:32:01 UTC
view on stackexchange narkive permalink

In astratto, se ci fossero 2 ^ n schemi di crittografia che fossero esattamente ugualmente difficili da violare e avessero lo stesso spazio di possibili chiavi, allora certo, potresti definire un nuovo schema di crittografia come "scegli a caso uno di questi 2 ^ n schemi "e considerare efficacemente quegli n bit da aggiungere alla chiave.

Ma in pratica, anche se ciò fosse possibile, si tratta di una complessità non necessaria quando si potrebbe invece semplicemente scegliere un singolo algoritmo e fare chiave un po 'più a lungo.

#5
+1
drjpizzle
2019-02-01 05:56:31 UTC
view on stackexchange narkive permalink

Penso che la domanda dell'OP dimostri intuizione e la risposta è, almeno in teoria, sì. C'è qualcosa qui. Penso che questo sia il primo punto che dovrebbe essere fatto Le risposte date sono per lo più del punto di vista: in pratica non funziona così Non sono sbagliate ma penso che manchino la validità / interesse del punto di OP.

Il modo in cui lo ragiono: Da un punto di vista teorico della scatola nera la scelta tra 2 sistemi di crittografia è analoga alla scelta del primo bit della chiave. In effetti sono davvero la stessa cosa (se aggiungi il bit indietro). In una scatola nera, non c'è davvero niente di speciale nella chiave. Sono solo un buon modo per enumerare le opzioni di quali trasformazioni di crittografia si desidera utilizzare.

Per vedere questo:

Supponiamo che crei una nuova variante di AES128 chiamiamola JES_0_128. Il modo in cui funziona è: aggiungo una codifica binaria di 0 (in questo caso 128 zeri) alla parte anteriore della chiave fornita e lo uso in AES256 (standard). Quindi ne creo un altro chiamato JES_1_128: una codifica di 1 ecc. Fino a JES_ (qualunque sia 2 ^ 128 in base 10) _128. Tutti questi sono algoritmi di crittografia della chiave a 128 bit perfettamente validi. Ma se non sai quale ... è un algoritmo di crittografia della chiave a 256 bit. AES256 per essere precisi. Il che è davvero molto più entropico.

La differenza che evidenziano le altre risposte è che in pratica una chiave è un ottimo modo per scegliere quale dei 2 ^ 256 algoritmi di crittografia AES-256 utilizzare. flessibile, ben compreso e lascia agli utenti la generazione e la fiducia del reciproco segreto. Perché usare qualcos'altro?

D'altra parte, scegliere una delle poche famiglie di algoritmi di crittografia a 256 bit da utilizzare e codificarla come hardcoded non è un ottimo modo. Anche rispetto a un piccolissimo aumento della dimensione della chiave. O per niente. Puoi anche dirlo a tutti. Da un punto di vista pratico / di scrittura / tipo non è affatto sicuro fare affidamento sul fatto che questo venga tenuto lontano da un attaccante di qualsiasi interesse. Ci sono molte ragioni per cui. Non da ultimo perché se un attaccante avesse una copia quale valore hai scelto sarebbe facile testare quale. Ma sono "solo" considerazioni pratiche ...

#6
  0
Damon
2019-01-31 19:38:26 UTC
view on stackexchange narkive permalink

Se si crittografa qualcosa con un algoritmo e si finge che ne sia stato utilizzato un altro, il principio di Kerckhoff si applica come indicato in altre risposte, quindi è un po 'inutile, almeno contro un utente malintenzionato con conoscenza della nostra implementazione. Continuerà a "funzionare" contro un utente malintenzionato che ad es. ruba il file crittografato dal tuo OneDrive o da qualsiasi altro archivio cloud senza sapere nulla al riguardo.

Se desideri che la scelta dell'algoritmo di crittografia sia inclusa nel processo di decrittografia (ovvero il tuo strumento sceglie uno tra diversi algoritmi, a seconda di ciò che inserisci), aggiungi effettivamente bit alla lunghezza della chiave. Il principio di Kerckhoff non si applica qui. Tuttavia è piuttosto difficile aggiungere una quantità significativa di bit - uno avrebbe bisogno di molti algoritmi tra cui scegliere - e non ha alcun senso (vedere l'ultimo paragrafo).

In entrambi i casi, qualunque quello che vuoi fare è praticamente inutile. L'ipotesi che i pronipoti di qualcuno possano avere i tuoi dati se investono un paio di miliardi in apparecchiature e fattura di elictricità è verosimilmente vera per le chiavi nell'intervallo 90-100 bit. Anche se realisticamente, nessuno (nemmeno la NSA) lo farebbe. Il rapporto costi-benefici non lo rivela. L'ingegneria sociale, o la tortura seguita dall'omicidio, è un approccio molto più economico, veloce e pratico.

Per qualsiasi cosa notevolmente più grande di 110 o giù di lì bit, un attacco di forza bruta non è realistico anche se si trascura rapporto costi-benefici. Dovresti essere più preoccupato per le backdoor integrate in AES, che è più probabile che sia il caso di quanto tu veda una sola chiave a 128 bit rotta dalla forza bruta durante la tua vita.

Ora, la semplice idea di decifrare una chiave a 256 bit tramite la forza bruta è assolutamente ridicola, e l'idea di aggiungere bit in cima a ciò non ha senso, fa esattamente la differenza zero. Impossibile non c'è niente di meglio di "impossibile".

Non vedo davvero cosa questo aggiunga a nessuna delle altre risposte che sono state già fornite.Potresti elaborare?
@TomK: Se non altro, il fatto che anche solo il pensiero di forzare brute una chiave a 256 bit o le ipotetiche conseguenze di ciò sia assurdo (o aggiungerlo a una chiave a 256 bit).Che nessun altro sembra considerare affatto.Pensare alla possibilità di forzare brute una chiave a 128 bit è già abbastanza assurdo, sebbene possa essere fisicamente possibile.
#7
  0
benrg
2019-02-04 00:31:25 UTC
view on stackexchange narkive permalink

Penso che questo sia un buon modo per vederlo:

Hai un segreto, che potrebbe essere una chiave a 256 bit, o una password da cui derivare quella chiave, o uno di questi oltre ad altre informazioni come l'algoritmo di crittografia utilizzato.

L'aggressore vuole indovinare il tuo segreto. Lo fanno provando varie possibilità finché non trovano quella giusta o finiscono il tempo, i soldi o la motivazione.

Non hai idea di quali possibilità stanno provando . Nella tua domanda, dici "e se per tutti gli anni avesse usato l'algoritmo sbagliato?" e l'unica risposta è "e se non lo fosse?" Non hai alcun controllo su questo. Se sapessi quali possibilità tenterà l'aggressore, potresti semplicemente scegliere come segreto qualsiasi cosa non presente nell'elenco e il problema di sicurezza sarebbe risolto banalmente.

Quello che puoi fare, però, è approssimativamente stimare quante possibilità possono provare prima di esaurire il tempo e / o il denaro, in base allo stato della tecnologia informatica. Ciò presuppone che non abbiano accesso segretamente a tecnologie che il resto del mondo non ha, come l'informatica quantistica o una backdoor in AES, il che è probabilmente un presupposto sicuro poiché in tal caso avrebbero cose migliori da fare di prova a decifrare la tua password. (Cf Taglia Lex Luthor a Check, anche se vedi anche questa confutazione.)

Puoi anche provare il seguente risultato : se scegli il tuo segreto in modo uniforme a caso (utilizzando un RNG di alta qualità) tra n possibilità e l'attaccante prova k possibilità, non importa quali siano , la possibilità che indovinino il tuo segreto è al massimo k/n.

La cosa bella è che n cresce in modo esponenziale con la quantità di informazioni che devi memorizzare / ricordare, mentre k cresce solo linearmente con la quantità di tempo / denaro che spendono, quindi non è difficile guadagnare k / n molto piccolo.

Quindi, dovresti scegliere il tuo segreto in modo uniforme e casuale da un ampio insieme di possibilità. Una chiave simmetrica casuale a 256 bit viene scelta in modo uniforme da un set di dimensione 2 256 , che è (molto più che) abbastanza grande.

Puoi scegliere a caso da un sacchetto di (algoritmo, chiave) anche coppie, ma è inutile perché ogni singolo algoritmo offre già molte scelte.

Puoi scegliere un algoritmo oscuro e sperare che l'aggressore non lo provi, ma non è a casuale non più, e quindi non puoi dimostrare che aiuta affatto. Se non ci fossero altre opzioni, sarebbe meglio di niente, ma ci sono altre opzioni.

Questa è la ragione fondamentale per cui i crittografi ti consigliano di considerare solo la chiave come tuo segreto: ci sono molte chiavi e le chiavi sono la cosa più facile da scegliere a caso. Non hai bisogno di nient'altro.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...