In TrueCrypt ho notato l'opzione per crittografare un volume con più algoritmi di crittografia, ad esempio AES-Twofish-Serpent. Sarebbe utile criptare qualcosa con lo stesso algoritmo più volte? Ad esempio AES-AES-AES. Direi che se venisse scoperto un difetto o una backdoor nell'algoritmo questa difesa sarebbe inutile, ma renderebbe più difficile l'attacco brute force?
EDIT: come si applicano più iterazioni?
Sì, fa la differenza. Rende il tuo sistema più rischioso.
Nel rispondere a questa domanda, assumerò che tu stia implementando una cascata AES-AES usando una modalità operativa ragionevole (ad esempio CBC o GCM) e con chiavi indipendenti.
Il vantaggio che sembri proporre è che potresti prevenire gli attacchi di forza bruta usando più livelli. Il problema è che, se un avversario ha qualche possibilità di rompere una chiave a 128 bit, allora dovendo rompere tre di loro fa quasi zero differenza per loro. Stai parlando della differenza tra le operazioni 2 128 e 2 129.58 . Considerando che i limiti di calcolo riducono i costi associati al cracking di una chiave a 128 bit da qualche parte nella regione di 1/100 di tutta la potenza mai prodotta dall'uomo, quel qualcosa in più non ha importanza.
L'unico vantaggio che una cascata AES-AES potrebbe portare è che molte classi di attacchi contro cifrari a blocchi sono rese più difficili. Ad esempio, gli attacchi di testo in chiaro scelti si basano sull'ottenere un sistema per crittografare i testi in chiaro selezionati dall'attaccante e, in genere, comportano il confronto dei testi cifrati risultanti. Tuttavia, con le cascate AES-AES, non è possibile selezionare l'input per il secondo cifrario.
C'è un problema, però. Ricordi quando ho detto che avrei presumo che avevi preso decisioni equilibrate? Ecco dove le cose iniziano a cadere a pezzi. Aumentando la complessità del tuo sistema, aumenti il numero di decisioni di sicurezza che devi prendere e aumenta il potenziale di errori e bachi di sicurezza. Esegui due trasformazioni sequenziali di blocchi AES per ogni processo a blocchi in CBC oppure crittografare tutto con AES-CBC e quindi crittografarlo di nuovo? Hai usato due IV separati? Stai selezionando le IV in modo indipendente? Stai selezionando i tasti in modo indipendente? Come stai applicando e controllando l'autenticità? Come farai a scambiare, conservare o derivare in modo sicuro le chiavi e le IV nel tuo protocollo? Tutte le tue implementazioni sono forti contro gli attacchi di canale laterale come attacchi DPA e timing? Ci sono un sacco di domande da chiarire e molte potenziali aree per il fallimento.
Infine, vorrei ricordarvi lo scopo delle cascate: garantire che una debolezza in un codice non determini una perdita di riservatezza dei dati. Implementando correttamente una cascata di, ad esempio, AES-Serpent, si garantisce che sia AES che Serpent devono essere interrotti prima che i dati vengano compromessi.
Utilizzare lo stesso algoritmo due volte non offre una sicurezza aggiuntiva significativa. Saresti vulnerabile a un attacco meet in the middle . L'utilizzo dello stesso algoritmo tre volte fornisce una sicurezza aggiuntiva equivalente all'incirca al raddoppio della dimensione della chiave. È possibile utilizzare la stessa chiave per la prima e l'ultima delle tre crittografie. Usare solo due chiavi in questo modo è probabilmente altrettanto sicuro che usare tre diversi.
Questo approccio con 2 o 3 tasti è stato utilizzato con l'algoritmo DES ed è noto come Tripple DES .
Un approccio più semplice e molto più rapido consiste nell'applicare XOR con una costante prima e dopo l'applicazione del codice. Questo approccio è stato utilizzato con DES ed è noto come DES-X .
Una generalizzazione potrebbe alternarsi tra XOR con una chiave e cifratura con una chiave. Inizio e fine con XOR. Impostando le chiavi in modo appropriato questo approccio generalizzato potrebbe ridurre a Tripple DES o DES-X. Ma questo approccio generalizzato non ha avuto molta analisi.
Nel caso di AES, l'applicazione di uno degli approcci precedenti equivarrebbe all'utilizzo di AES con un programma di chiavi diverso. Questo non è generalmente vero per ogni cifrario, è specifico per la struttura di AES.
L'implicazione di questo è che uno qualsiasi degli approcci sopra sarebbe davvero di aiuto solo se la dimensione della chiave di AES fosse troppo piccola, o se ci fosse qualche debolezza nella pianificazione delle chiavi standardizzata di AES. In altre parole, applicare AES-128 tre volte con chiavi diverse dovrebbe fornire la stessa sicurezza di AES-256. Se non c'è stato alcun punto debole nella pianificazione dei tasti AES.
Tuttavia ci sono dei punti deboli noti nella programmazione dei tasti AES, e in particolare AES-256 ha dimostrato di essere molto più debole di quanto ci si aspetterebbe da una chiave a 256 bit. Quindi applicare AES-128 tre volte con chiavi diverse è, per quanto ne so, più sicuro di AES-256.
Risposta breve:
Da un punto di vista pratico, è impossibile forzare la chiave a 128 bit di qualcosa originariamente crittografato con AES. Tecnicamente parlando, è possibile ma richiederebbe un miliardo di miliardi di anni (1,02 x 10 ^ 18) per computer, test ed esaurimento dello spazio delle chiavi, motivo per cui è praticamente impossibile. Prendendo questa logica in avanti, la crittografia di qualcosa per 3 volte sarebbe impossibile ^ 3 per rompere (alias impossibile ancora). E mentre non ci sarebbe alcun vantaggio per la riservatezza dei dati da crittografare mediante la crittografia 3 volte, questi 2 ulteriori passaggi di crittografia richiederebbero il 200% in più di risorse computazionali di quelle richieste per un singolo passaggio di crittografia.
dettagli:
In termini di forza bruta, l'uso dello stesso algoritmo di crittografia e della chiave più volte per crittografare i dati non modificherà l'esito dell'attacco. Ciò significa che se l'attacco avrebbe avuto successo contro i dati crittografati solo una volta da un algoritmo / chiave, lo stesso attacco verrà utilizzato con successo contro i dati crittografati più volte utilizzando lo stesso algoritmo / chiave. Ciò è dovuto principalmente al componente di crittografia che ha ceduto alla forza bruta (suggerimento: non all'algoritmo).
Ci sono due parti fondamentali della crittografia che possono essere vulnerabili agli attacchi: l'algoritmo e la chiave. Ognuna di queste due parti è vulnerabile a diversi rischi. Gli algoritmi possono essere vulnerabili a backdoor e difetti matematici, nessuno dei quali viene direttamente messo a rischio da un attacco di forza bruta. E nessuno dei quali è stato scoperto in AES utilizzando una chiave a 128 bit, anche se l'algoritmo è al 100% open source per il mondo. (nota: c'è un difetto nell'algoritmo AES quando si usano chiavi a 192 e 256 bit che alla fine le rendono più deboli di se fosse stata usata una chiave a 128 bit - non preoccupatevi di questo, dato che 128 è matematicamente abbastanza strong (maggiori informazioni su questo in basso)). Con non molto da attaccare all'algoritmo, diamo un'occhiata all'altra metà.
Diversamente dagli algoritmi, le chiavi di crittografia sono molto suscettibili agli attacchi di forza bruta, ma tale suscettibilità esiste solo quando la chiave di crittografia viene generata da dati non randomizzati (ad esempio un utente che immette una "password" di crittografia). In casi come questi, la forza dell'algoritmo di crittografia non può essere massimizzata e la forzatura bruta diventa possibile. Per le chiavi a 128 bit di dimensioni massime create da dati randomizzati, gli attacchi di forza bruta non funzionano. In realtà funzionano, ma il possibile spazio chiave è troppo grande da calcolare nelle nostre vite, anche se si utilizza l'elaborazione distribuita e il calcolo per la legge di Moore. Gli attacchi di forza bruta contro i tasti a 128 bit cercano 1 chiave fuori dal possibile spazio di 340 spettrometri (aka 3.4 × 10 ^ 38). Matematicamente parlando, non è possibile forzare brutalmente una chiave da quello spazio nelle nostre vite, o anche nella vita di qualsiasi generazione di discendenti che verranno dopo di te.
Tuttavia, se la password utilizzata per generare la chiave è debole (ad esempio "P @ ssW0rd1", ecc ...), lo spazio della chiave non è stato esaurito e la forza bruta è possibile lì. Morale della storia: randomizza le chiavi di crittografia e sfrutta appieno lo spazio delle chiavi. Ciò elimina tutto, tranne difetti di algoritmo e backdoor, nessuno dei quali deve essere preoccupato per AES, dal momento che l'algoritmo completo è visibile dal mondo per più di un decennio. Basta tenere la chiave al sicuro e anche tu sei al sicuro.
Sono d'accordo sul fatto che i vantaggi della crittografia multipla siano piccoli, che ci siano diversi potenziali insidie da fare correttamente (senza ricadere sulla sicurezza della singola crittografia) e che c'è un costo della CPU per fare la crittografia aggiuntiva. Tuttavia, non penso che sia un anti-pattern di sicurezza come inventare il tuo cifrario.
Sì, ogni volta che aggiungi complessità a un sistema, potresti inavvertitamente aprirti agli attacchi di un canale laterale. Certo, il codice dell'applicazione per farlo non deve essere ingombrante o complesso.
Secondo me usando E AES (K 1 , E AES (K 2 , E < sub> AES (K 3 , P))), in quanto il codice a blocchi non ti apre più attacchi di quelli che hanno usato E AES (K 1 , P) come codice a blocchi.
In superficie, hai appena cambiato il codice a blocchi con una chiave a 128 bit in uno con una chiave a 384 bit, quindi a prima vista si potrebbe affermare che tu sei molto più sicuro con il nuovo schema.
Ci sono dei caveat:
Dovresti fare attenzione che non sia possibile rompere le tue chiavi in sequenza. Se è possibile verificare che hai rotto la prima chiave, invece di avere la chiave a 384 bit, hai solo 129 bit di sicurezza. Dovresti trattare E (K 1 , E (K 2 , (E (K 3 , P block ) )) come codice a blocchi e applica la modalità di cifratura a blocchi della crittografia (ad esempio, CBC con padding) in cima a questo nuovo codice. Un errore sarebbe utilizzare E CBC (K 1 , E CBC (K 2 , (E CBC (K 3 , P message ))), dove E AES-CBC aggiunge il padding secondo lo schema di padding PKCS7 e opera sull'intero messaggio. Nota Schema di riempimento di PKCS-7 aggiunge un blocco completo (128-bit = 16 byte per AES) di riempimento quando il testo in chiaro è un multiplo esatto del blocco Pertanto, per le due fasi di crittografia CBC esterne, si aggiungeranno blocchi di 128 bit alla fine del messaggio prima di crittografare, quindi è possibile risolvere K 1 e K 2 tentando di crittografare il blocco padding con tutte le 2 chiavi 128 fino a trovare le due chiavi che corrispondono a queste due ultimi blocchi nella modalità di crittografia a blocchi.
Se un utente malintenzionato sa o può intuire un blocco di testo in chiaro che corrisponde a un blocco di testo cifrato, allora c'è un attacco meet-in-the-middle che richiede O (2 128 ) di spazio e prende O (2 256 ) di tempo. L'incontro nell'attacco centrale è il motivo per cui il DES triplo è costituito da tre round di crittografia piuttosto che da un doppio DES. Molto spesso è possibile per un utente malintenzionato essere in grado di indovinare ragionevolmente un blocco, quindi è più corretto dire che in pratica questo schema AES triplo fornirebbe solo sicurezza a 256 bit.
Non è proprio vero che la crittografia a 256-bit (il tempo per la forza bruta è 2 256 ) è più sicuro della crittografia a 128 bit (tempo di forza bruta 2 128 ). Entrambi sono ben al di fuori dei limiti degli attaccanti. 2 128 = 340 282 366 920 938 463 463 374 607 431 768 211 456 (340 miliardi di miliardi di miliardi di miliardi). Questo è un miliardo di persone al mondo che gestiscono un milione di computer con ogni computer che tenta un miliardo di chiavi al secondo per un milione di anni prima di avere il 10% di possibilità di forzare la chiave. Quindi, la forzatura bruta è molto fuori questione a 2 128 - quindi la discussione di tali attacchi è irrilevante a fini pratici a meno che non ci siano grandi progressi nelle nostre capacità computazionali. Altri attacchi devono essere utilizzati come keylogger, rubare chiavi dalla RAM, chiave $ 5 , difetti nel codice a blocchi. Quindi anche se 2 256 è molto più grande (2 128 volte più grande di fatto) di 2 128 , è in gran parte irrilevante. Un po 'come paragonare la tua capacità di viaggiare ad Alpha Centauri (a 4 anni luce di distanza) rispetto alla tua capacità di viaggiare nella galassia di Andromeda (2,5 milioni anni luce di distanza). (Per riferimento, la Luna si trova a soli 0.000.000 di anni luce da noi.) Sì, la galassia di Andromeda è molto più lontana, ma non è chiaro se viaggiare in realtà è più difficile in pratica, poiché entrambi sono attualmente impossibili. Certo, sembra che se l'umanità dovesse mai viaggiare verso altre stelle, probabilmente saremo in grado di viaggiare per la prima volta ad Alpha Centauri, ma non è noto se viaggeremo in altre stelle e se così fosse richiede qualche incredibile scoperta che potrebbe farcela è possibile viaggiare in altre galassie abbastanza facilmente portando entrambe le attività a portata di mano.
L'uso dello stesso algoritmo più volte non ti dà necessariamente la maggiore sicurezza che ti aspetti: il motivo è che consente " si incontrano negli attacchi centrali ". Lasciatemi citare una parte dal link di riferimento:
"When trying to improve the security of a block cipher, a tempting idea is to simply use several independent keys to encrypt the data several times using a sequence of functions (encryptions). Then one might think that this doubles or even n-tuples the security of the multiple-encryption scheme, depending on the number of encryptions the data must go through.
The Meet-in-the-Middle attack attempts to find a value using both of the range (ciphertext) and domain (plaintext) of the composition of several functions (or block ciphers) such that the forward mapping through the first functions is the same as the backward mapping (inverse image) through the last functions, quite literally meeting in the middle of the composed function."
L'algoritmo TripleDES vecchio stile ha fatto il seguente modo:
ciphertext = EK3(DK2(EK1(plaintext))), plaintext = DK1(EK2(DK3(ciphertext)))
dove K1, K2, K3 sono chiavi indipendenti, E è la crittografia e D la funzione di decrittazione.
Ma probabilmente stai cercando cascate per rafforzare l'algoritmo di crittografia. TrueCrypt fornisce questo implementando le seguenti cascate:
L'idea alla base è che se ci sono dei punti deboli rivelati in futuro, i tuoi dati sono ancora protetti da un secondo (o terzo) algoritmo di crittografia indipendente.
Un'altra tecnica sta proteggendo la chiave casuale nell'intestazione usando un SALE e aumentando il numero di iterazioni in > 1000 (SALT protegge contro gli attacchi dei tavoli arcobaleno aumentando il numero di possibili combinazioni che devi provare in un attacco di forza bruta, mentre aumentando il numero di iterazioni ti protegge rallentando l'algoritmo: devi scorrere tutte le iterazioni in per decifrare l'intestazione: rallentarlo significa avere meno "tentativi" al secondo e la forza bruta è più lunga).
Aggiornamento: (Sulla domanda: "Come si applicano le iterazioni in modo diverso dall'applicare AES più volte?")
Codici di blocco come AES ripetono le loro trasformazioni più volte a seconda delle dimensioni della chiave (i cosiddetti cicli o iterazioni) per aumentare l'entropia della crittografia (10 cicli per chiavi a 128 bit, 14 cicli o iterazioni per chiavi a 256 bit). Questo non è lo stesso che applicare AES più volte, perché i cicli fanno parte dell'algoritmo stesso. Se si implementa l'algoritmo, è possibile aumentare il numero di cicli, ma si noti che si modifica l'implementazione standard se lo si fa. Una funzione di derivazione chiave come PBKDF2 è definita come segue:
DK = PBKDF2(PRF, Password, Salt, c, dkLen)
Uno dei parametri è c, e specifica il numero di cicli (iterazioni), che è usato per rinforzare l'algoritmo, perché è necessaria una quantità arbitrariamente grande di tempo di calcolo se il parametro c è scelto abbastanza grande. Ma si noti che nello stesso articolo di Wikipedia si nota che uno dei punti deboli di PBKDF2 è che gli attacchi ASIC e GPU possono essere usati per romperlo. Ciò significa che aumentare il numero di iterazioni non garantisce che la forza aumenti automaticamente.
Aggiornamento: Sostituito il vecchio URL di truecrypt.org da quello nuovo ospitato in Svizzera perché gli sviluppatori originali non stanno continuando il loro lavoro.
Leggi altre domande sui tag encryption