Le funzioni hash crittografiche popolari non dovrebbero codificare la lunghezza dei dati di input nell'output?

Question

Le funzioni hash crittografiche popolari non dovrebbero codificare la lunghezza dei dati di input nell'output?

#1 da (6 voti)
#2 da (4 voti)

1

EDIT2: questa discussione è stata ridotta a "le collisioni sono effettivamente più difficili da creare quando si aggiunge un vincolo di lunghezza?" che è più rilevante per lo scambio Crypto. Creerò una domanda lì e collegherò quando esiste. Grazie a tutti coloro che hanno partecipato alla discussione

EDIT: Il termine "Collision attack" in Wikipedia sembra parlare solo di trovare una collisione casuale, intendevo dire "Preimage attack ".

Mi sembrerebbe una buona idea, perché eviterebbe tutti gli attacchi di collisione che richiedono che l'attaccante modifichi la lunghezza dei dati. L'attaccante dovrebbe trovare una collisione con la stessa lunghezza esatta, che è ovviamente molto più difficile di trovare una collisione generale.

Gli attacchi di collisione di solito richiedono che l'attaccante modifichi la lunghezza dei dati (aggiungendo altri blocchi ai dati esistenti o qualcosa del genere), vero?

L'unico svantaggio che vedo è che richiederà che i risultati dell'hash siano più lunghi (il modo in cui lo vedo solo per 2-4 byte è "La lunghezza del modulo dati 2 ^ 16-2 ^ 32" dovrebbe essere abbastanza) quindi non di molto.

Questo ovviamente non deve essere parte della funzione di hash stessa, potrebbe essere solo una raccomandazione di sicurezza generale: "Verificare la lunghezza prevista dei dati, non solo che corrisponda all'hash calcolato, per evitare molti moduli di attacchi di collisione ".

Anche se non ho mai sentito dire o menzionato prima questa raccomandazione, anche se il modo in cui la vedo, ha molto senso.

Quindi, in generale, sto chiedendo qui: perché non è una buona idea? Dovrebbe essere codificato nelle funzioni di hash, quindi viene applicato automaticamente da chiunque usi quelle funzioni, o dovrebbe essere una raccomandazione di sicurezza generale che spetta all'utente della funzione hash implementare da solo, separatamente dalla funzione hash?

O forse mi manca completamente qualcosa che renda quest'idea ridicola?

hash

posta Omer 12.10.2017 - 21:58

fonte

2 risposte

Leggi altre domande sui tag hash

jQuery 2.1.1 è vulnerabile all'input del comando OS? Regole complesse per la password - è ragionevole?

score 6 · Answer 1

Ti manca un altro aspetto negativo: indica all'attaccante la lunghezza del testo in chiaro.

In alcuni casi si tratta di informazioni riservate. Ad esempio, se metto le password per forzature brute, mi stai dicendo che posso saltare provare tutte le password tranne quelle della lunghezza specificata. Fantastico, grazie.

Collision attacks usually require the attacker to modify the length of the data (by appending more blocks to the existing data or something like that), don't they?

Credo che tu stia descrivendo un attacco di estensione della lunghezza . I veri crittografi probabilmente mi arrostirebbero per averlo detto, ma ho ingenuamente una possibile soluzione per riempire il massaggio prima dell'hashing (a quel punto puoi cancellare l'intera codifica della lunghezza e usare solo una tradizionale funzione di hash): _ (davvero, don costruisco software basato su questo, non garantisco che sia sicuro)

hash( 0*(256 - (len(msg)%256) ) || msg)

Quindi, quando l'utente malintenzionato tenta di eseguire un attacco di estensione di lunghezza concatenando msg2 alla fine:

hash( 0*(256 - (len(msg||msg2)%256) ) || msg||msg2)

avranno un diverso numero di padding 0, che cambia il prefisso del massaggio e interrompe totalmente l'attacco dell'estensione di lunghezza.

(Più ci penso, meno voglio sostenere l'idea, probabilmente dovrei passare un po 'di tempo a cercare "mitigazione dell'attacco con estensione di lunghezza" piuttosto che sedermi qui e speculare)

score 4 · Answer 2

Una funzione di hash crittografica è progettata per avere grandi cambiamenti all'output anche su piccole modifiche all'output. Aggiungendo alcuni byte che descrivono la lunghezza dell'input, si modifica questa ipotesi, poiché questi bit di lunghezza creeranno solo piccole modifiche all'output su piccole modifiche all'ingresso.

A parte questo, hai già fatto emergere informazioni importanti sull'input come Mike Ounsworth . In sostanza si dice all'attaccante non solo per quanto tempo sarà l'input, ma anche che c'è sicuramente un certo valore per lungo tempo che si traduce in questo hash. Ciò riduce notevolmente lo spazio che l'utente malintenzionato deve sfruttare per ottenere lo stesso risultato hash, che in caso di password è tutto ciò che è necessario in quanto non è richiesta una collusione.

Ma anche nel caso in cui ci si preoccupi di una preimage non è chiaro che i bit che si aggiungono per codificare la lunghezza non sarebbero più utili invece di estendere la forza dell'hash stesso per evitare un attacco di pre-immagine. Mentre potrebbe essere d'aiuto nei casi in cui l'input deve essere più breve dell'hash stesso e quindi le preimmagini sono improbabili, penso che questi bit siano utilizzati meglio per un hash reale più lungo nel caso in cui l'input sia più lungo dell'output hash perché le pre-immagini della stessa lunghezza sono molto più probabile quindi.

The attacker would have to find a collision with the exact same length, which is obviously much harder than finding a general collision.

È davvero così evidentemente più difficile? Sono d'accordo sul fatto che è più difficile se l'input è più breve dell'hash, dal momento che si tratta di trovare pre-immagini di dimensioni così ridotte. Ma se l'input è molto più grande dell'hash (vale a dire con i certificati), dubito che richiedere una lunghezza specifica aggiunga davvero ulteriore complessità alla ricerca di un preimage, a meno che non vi sia qualche debole intrinseco nel modo in cui l'hash è costruito.