C'era già un argomento simile "Perché AES non è usato per l'hashing sicuro, invece di SHA-x?", ma non si trattava specificamente di file, e personalmente non sono convinto dalle risposte in esso contenute. "AES non è progettato per questo lavoro" non è una risposta.
Ciò che mi infastidisce di quelle risposte è che teorizzano su come AES è un diverso tipo di algoritmo e non è adatto per il lavoro, ma nessuno ha presentato casi reali - come in ", l'implementazione suggerita sarebbe incrinata con < strong> questa procedura ". Spero che stessero parlando in generale, e che l'hashing dei file potrebbe essere una storia diversa.
Un fattore importante deve essere preso in considerazione: tutti gli odierni algoritmi di hash crittograficamente protetti sono lenti. Le migliori implementazioni di SHA-256 raggiungono al massimo un paio di centinaia di megabyte al secondo. Hanno una proprietà inerente al criptaggio, che non possono essere calcolati in parallelo - la sequenza dei dati di input non può essere divisa.
I sistemi I / O di oggi sono già più veloci di quanto l'hardware del consumatore a thread singolo più veloce possa calcolare su questi hash. Ciò significa che questi algoritmi sono diventati il collo di bottiglia, e scendono solo da qui, perché le prestazioni single-thread non mostrano più alcun progresso serio (per diverse generazioni di CPU), mentre IO sta diventando più veloce rapidamente (grazie alle unità SSD e ai dischi RAM) , che alla fine ha iniziato a spingere in avanti le velocità di azionamento del piatto lungo-stagnante).
Il più grande vantaggio dell'hash AES è che abbiamo implementazioni hardware per esso e che l'hash AES può essere progettato per abilitare il parallelismo.
Diamo un'occhiata a uno schema semplice: AES256 (DATA_BLOCK_0 XOR COUNTER_0) XOR AES256 (DATA_BLOCK_1 XOR COUNTER_1) XOR ...
L'ultimo blocco dati è riempito di zeri. Il tasto AES è noto e preimpostato. Un'altra opzione è quella di utilizzare il blocco dati come chiave ogni volta e crittografare solo il contatore - non so adesso se questo può avere un impatto negativo sulla velocità, poiché la chiave deve cambiare per ogni blocco. Se non c'è un impatto serio, potrebbe essere la scelta migliore.
Ad ogni modo, lo schema dato è massicciamente parallelizzabile e può spingere 2.5 gigabyte al secondo su un quad-core moderno con accelerazione hardware AES. Si ridimensionerà perfettamente anche in futuro, che è sempre più core della CPU.
L'hash AES deve essere utilizzato a causa della velocità, ed è lo scopo principale dei file hash, e non quello di inizializzare le chiavi private e cose del genere. È meglio lasciarlo agli algoritmi di hash sicuri "reali", sono d'accordo.
Ora per qualche analisi.
Per quanto riguarda il rilevamento di errori casuali, non vedo alcun problema con lo schema sopra indicato. Dovrebbe mescolare bene e reagire in modo casuale per qualsiasi cambiamento.
Non dobbiamo preoccuparci di qualcuno che esegue il reverse-calcolo dei dati originali dall'hash. Gli hash dei file sono sempre distribuiti con i loro file e il loro scopo non è quello di oscurare i dati originali. Il loro scopo è quello di garantire (con ragionevole probabilità) che i dati non siano cambiati, che si tratti di un file non modificato. Gli hash dei file privati non dovrebbero essere resi pubblici in entrambi i casi, anche con algoritmi come SHA-256.
La parte problematica può essere solo un attacco intelligente che tenta di modificare il file in modo tale che l'hash non cambierebbe. Nello scenario più semplice, credo che un attaccante modifichi una parte di un blocco per raggiungere un obiettivo. Dopodiché, ha bisogno di modificare uno qualsiasi (o più) blocco, che è considerato non importante, in modo tale che produca un hash noto - uno XOR con il primo hash del blocco modificato in modo che la differenza venga eliminata e l'hash finale rimarrà lo stesso.
Lasciamo da parte il caso di attaccante che aggiunge dati al file, in quanto può essere facilmente rilevato e probabilmente non è più facile da calcolare comunque.
Sto osservando lo schema semplice di cui sopra, e per me sembra che l'attaccante debba cercare uno spazio di 2 ^ 256 per trovare l'input appropriato, che è all'incirca lo stesso di crack AES. E quello spazio è semplicemente troppo grande.
Ora, qualcuno può spiegare quale procedura consentirebbe l'attacco descritto?
Grazie.