È AES possibile per i file hashing sicuri? [chiuso]

0

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.

    
posta user37442 17.01.2014 - 10:03
fonte

2 risposte

7

Ecco il file che descrive i nostri archivi presso la First Bank of Craptology. È un formato semplice con record a larghezza fissa: un nome utente a 16 byte e un bilancio a 16 byte.

user37442_______0000000099999999
Gilles__________0000000000000042

Sotto la tua proposta (se l'ho letto correttamente, la tua affermazione non è molto precisa), il suo hash è AES [K] (your_name ⊗ (C + 0)) ⊗ AES [K] (your_balance ⊗ (C + 1)) ⊗ AES [K] (my_name ⊗ (C + 2)) ⊗ AES [K] (my_balance ⊗ (C + 3)) dove C è il valore del contatore iniziale e K è un tasto. Ecco un altro file con lo stesso hash, supponendo che C sia un multiplo di 4:

user37442_______0000000000000040
Gilles__________0000000099999997

Quindi hai uno schema crittografico che non puoi rompere? Grande affare. Il tuo compito è quello di elaborare uno schema che nessuno può rompere.

Sono sicuro che puoi inventare una semplice modifica del tuo schema che farebbe fallire il mio contro-esempio. Molto probabilmente, se ci pensi, sarai in grado di trovare uno schema che I non può rompere. Ma io non sono un crittografo.

Se vuoi essere preso sul serio, allora:

  1. Capisci di cosa stai parlando. Leggi cosa definisce un hash crittografico . Quello che stai cercando qui è più debole di un hash - un hash crittografico deve avere resistenza pre-imaging. Ok, potrebbe esserci un punto in una primitiva più debole, ma è necessario essere più chiari su ciò che si sta tentando di fare. Definisci correttamente il tuo problema di sicurezza.
  2. Lavorare seriamente per attaccare il tuo schema. Non limitarti a dire che "dovrebbe mescolare bene e reagire in modo casuale". Leggi come sono stati violati i piani di altre persone e prova le stesse tecniche contro la tua proposta.
  3. Una volta che hai qualcosa che non puoi interrompere - e che hai seriamente cercato di interrompere - pubblicalo.
  4. Attendi fino a quando sono passati anni e molti crittografi professionisti hanno tentato di attaccare il tuo schema e hanno fallito tutti. A quel punto, il tuo schema può essere preso seriamente in considerazione per l'utilizzo nelle applicazioni.

Sul tema specifico dell'uso di algoritmi basati su AES per l'hashing, ecco un po 'di lettura:

Avere una CPU in grado di tenere il passo con un sistema IO non è un grosso problema nella maggior parte delle applicazioni. Di solito il sistema IO viene utilizzato da più istanze in parallelo comunque.

    
risposta data 17.01.2014 - 12:11
fonte
4

Rifiutare le argomentazioni generali e insistere sull'avere la tua "specifica" "proposta" in modo da convincere tu è un errore noto. È la tattica principale della maggior parte dei pazzi, che cerca di attirare alcuni esperti in un ciclo infinito di "è rotto in questo modo - sì ma cosa succede se cambio questo bit? - allora è rotto in questo modo - ok ma che mi dici di XORing che è un po 'lì? - ... ". Quando l'esperto alla fine si annoia a parlare con l'equivalente di rete di un pappagallo, o ha del lavoro da fare, e se ne va, il crackpot rivendica la vittoria.

Una decente proposta crittografica viene fornita con argomenti positivi che non possono essere infranti, non argomenti su come tu non sai come romperlo. Altrimenti, è inutile e nessuno la guarderà.

Anche se nel tuo caso, le preimmagini sono banali. Se K è noto, allora decryption di K è facile come la crittografia di K ; corrispondentemente, dato AES K (dati XOR counter0), ottenere "data XOR counter0" è una questione di 28 cicli di clock, non di più. Il tuo "hash" non può nemmeno essere definito "debole"; non offre alcuna resistenza agli attacchi. È anche povero contro i non-attacchi, e incorrerà in ulteriori collisioni spurie se usato su "dati normali" rispetto a un CRC32 o MD4.

Infatti ricordo di aver fatto questo esempio (con un altro codice a blocchi) usato in un corso introduttivo sulla crittografia per dimostrare come queste cose non siano improvvisate. Gli studenti alle prime armi sono attesi per trovarlo banalmente irrisolvibili.

    
risposta data 17.01.2014 - 13:38
fonte

Leggi altre domande sui tag