it-swarm.it

Quanto tempo dovrebbe essere un hash per essere assolutamente sicuro?

Esiste una sorta di regola per determinare quanto deve essere grande un hash per garantire la sicurezza (che significa esattamente che un messaggio è associato a un determinato hash) di un messaggio? Qualcosa che può essere applicato a qualsiasi messaggio, come un numero a 32 bit o una 8 lettere ASCII.

18
SecurityStudent

esattamente un messaggio viene mappato su un determinato hash

Ciò non è possibile a causa del principio del buco del piccione. Finché il messaggio di input per la funzione hash può essere più grande dell'hash stesso, è garantito che alcuni messaggi si scontrano tra loro e mappino stesso hash. Questo è normale e non è un problema per la sicurezza degli hash da solo.

Devi solo assicurarti che la funzione hash sia così grande che intenzionalmente la ricerca di tali collisioni (un attacco di collisione) sia impossibile dal punto di vista computazionale. Un digest hash di n bit ha una resistenza alla collisione di n/2 bit. Per ottenere una sicurezza a 128 bit contro un attacco di collisione, è quindi necessario disporre di un digest hash di 256 bit. Questo, ovviamente, presuppone che l'hash sia crittograficamente sicuro ( come SHA-256 ) per evitare che ci siano attacchi che prendono una scorciatoia e possono trovare collisioni più facilmente che con la forza bruta.

87
forest

Dipende molto da ciò che vuoi ottenere. In primo luogo, come già sottolineato dalla foresta, ciò che si desidera in termini di una sola mappa di input è un hash - nel caso gernerale - impossibile. è possibile in casi speciali se l'hash è lungo quanto l'input o più lungo. Dal momento che hai citato numeri interi a 32 bit, esistono effettivamente hash da intero a intero a 32 bit.
Si noti tuttavia che il numero possibile di input è così piccolo a 32 bit che la costruzione di una tabella di ricerca è in realtà abbastanza fattibile (occupa solo 32 GB, quindi sul computer che sto usando in questo momento, la tabella di ricerca si adatterebbe completamente alla RAM!). Inutile dire che non lo è, e impossibile essere sicuro, indipendentemente dall'algoritmo che si utilizza.

Se prevedi di identificare qualcosa (come un file o una stringa) con l'hash e la manomissione dannosa non è non una considerazione o almeno non la tua prima priorità, quindi puoi praticamente considerare 64 bit "abbastanza buono" e 128 bit "assolutamente sicuro".
CRC32 che non fornisce nemmeno le garanzie fornite da hash crittograficamente sicuri è stato accettato come "abbastanza buono" per distinguere le cose e identificare in modo affidabile modifiche accidentali per molti anni (e 64 bit è un ordine di grandezza completamente diverso rispetto a 32 !!!). ID sono 128 bit e sono considerati "unici" quando chiaramente non lo sono. Ma per tutte le questioni pratiche, lo sono.
Stavo per aggiungere quel GIT, che viene utilizzato tra l'altro per ospitare il kernel Linux e altri software rilevanti per la sicurezza utilizzati in miliardi di dispositivi (rendendolo così un bersaglio molto interessante per un attacco ) usa hash a 128 bit per mantenere le cose separate e sicure, ma in realtà sono 160 bit ...

Ora, se la manomissione dannosa è una preoccupazione, tu molto probabilmente vuoi un sicuro = algoritmo hash (quindi CRC non farà il trucco), ma non hai necessariamente hai bisogno di più bit. Dipende solo da cosa vuoi proteggere, da quanto tempo e da che tipo di attacco.
Siphash o Cityhash (per impostazione predefinita, nella configurazione originale/comune, ci sono anche varianti a 32 e 128 bit) sono solo 64 bit. Il che è molto bello e assolutamente sicuro se lo usi ad es. per garantire l'integrità di alcuni messaggi di dimensioni ragionevoli inviati su Internet. Un attaccante sufficientemente potente potrebbe trovare una collisione entro 15-20 minuti? Sicuro. Ma chi se ne frega, dopo 15 minuti sono 14 minuti e 59 secondi troppo tardi per fargli fare qualcosa.
D'altra parte, per niente va bene se hai intenzione di usarlo per qualcosa che viene memorizzato per un tempo più lungo.

In tal caso, vuoi almeno 128, migliori 160 bit e, per dire con ragionevole certezza "assolutamente sicuro", avrai bisogno di 256 bit o più, di nuovo dipende che esattamente vuoi. AES-CGM, che è considerato "abbastanza buono per praticamente tutti" ha al massimo 128 bit (fino a 96).

Il tuo aggressore sta scegliendo due input, quindi è applicabile un attacco di compleanno? In tal caso, 128 bit valgono solo 64 bit (o, se le proiezioni valgono, 42 bit su computer quantistici). Questo è sicuramente un po 'scarso e non abbastanza per dire "abbastanza buono", figuriamoci "assolutamente sicuro".

Stai solo ti preoccupi degli attacchi seconda preimagine, ovvero devi scegliere uno degli input? In tal caso, 128 bit saranno "possibilmente eccellenti", 160 bit saranno "indistruttibili" e 256 bit "ridicolmente indistruttibili". A meno che l'algoritmo stesso non sia rotto, cioè.

tl; dr
Tutto sommato, se preferisci una risposta incondizionata che non richiede di prendere in considerazione le condizioni preliminari, dovresti considerare che la risposta è 256 o più .
256 bit è nel regno di "ridicolmente impossibile", ma si dovrebbe considerare che gli algoritmi si rompono nel tempo, quindi un algoritmo a 256 bit potrebbe vale solo un carico di lavoro di 2 ^ 140 o 2 ^ 150 in 10-20 anni, non c'è modo di saperlo. Se sei un po 'paranoico, potrebbe non essere sufficiente per dirti "assolutamente sicuro" (anche se per la maggior parte delle persone immagino che sia ancora abbastanza).

Quindi, senza conoscere il tuo livello di paranoia, dico "256 o più". Alcuni bit extra non costano molto, ma hanno un impatto enorme. Renderlo 384 o addirittura 512, perché no. Se un algoritmo a 512 bit è molto, molto significativamente rotto e indebolito a un carico di lavoro, diciamo 2 ^ 300, e i computer iper-quantistici-super-magici inventati dagli alieni para-dimensionali possono, applicando matematicamente e fisicamente impossibile magic, riducilo ulteriormente a un carico di lavoro di 2 ^ 150 bit, quindi sei ancora abbastanza bravo da fare.

12
Damon

La dimensione di output di una funzione hash pone un limite superiore al suo livello di sicurezza. Le tre proprietà principali che ogni funzione hash crittografica dovrebbe avere è la resistenza agli attacchi di collisione, prima pre-immagine e seconda pre-immagine.

Se un algoritmo ha n - bit di sicurezza, significa che non esiste alcun attacco che rompe le proprietà di sicurezza rilevanti che richiederebbero molto meno di 2 n  passi (approssimativamente e in media) per avere successo. Se n è abbastanza grande, allora possiamo praticamente essere certi che nessuno ha abbastanza potenza di calcolo per attaccare un sistema.

Da una funzione hash con n - bit output, possiamo aspettarci fino a n - bit security quando si tratta di attacchi preimage, ma non superiore . Si potrebbe ipoteticamente cercare un preimage con la forza bruta e riuscire dopo, in media, 2 n  cerca.)

Per resistenza alla collisione, tuttavia, problema di compleanno significa che avresti bisogno di 2 * n bit invece di n bit.

Puntiamo spesso alla sicurezza a 128 bit, quindi ciò significa che la dimensione digest accettabile più piccola è 256 bit. La sicurezza a 128 bit ti lascia con un margine di sicurezza abbastanza grande che probabilmente saresti ancora sicuro usando pochi bit di output in meno, ma usare troppi bit è rischioso.

Nota: Questo è un limite superiore. Sebbene algoritmi come Murmur3, CityHash, xxHash e altri possano dichiarare di essere di alta qualità e avere output lunghi, non offrono una sicurezza significativa.

Sicuramente non scegliere un algoritmo basato solo sulla sua dimensione di output. Le dimensioni dell'output determinano solo la forza teorica massima di un hash. Non è la sua vera forza.

Scegli invece una funzione hash resistente alle collisioni che le persone concordano sul fatto che siano al sicuro, ad es. Blake-2, SHA-3, Skein o SHA-2.

Nota 2: Se stai usando qualcosa come SHA-512, puoi considerare l'algoritmo come se input distinti si traducessero sempre in output unici. Con una probabilità quasi uguale a uno, non otterrai digest duplicati per nessun set di input del mondo reale.

La reale probabilità di vedere digest in collisione dipende sia dal numero di messaggi che si tenta di eseguire l'hash sia dal numero di output possibili che possono esserci. Il numero di messaggi distinti che potresti provare a eseguire l'hash è naturalmente limitato perché il tuo potere di calcolare gli hash è limitato.

Le funzioni hash non sono veramente iniettive, ma gli sviluppatori di software possono utilizzare una grande funzione hash resistente alle collisioni e trattarla come se fosse vera. La possibilità di produrre inavvertitamente una o più collisioni è tecnicamente diversa da zero, ma il cervello di una persona non può comprendere quanto sia incredibilmente improbabile.

4
Future Security

Se dobbiamo averlo in modo tale che ogni digest del messaggio corrisponda esattamente a un messaggio, allora il nostro digest deve essere grande quanto il messaggio più lungo possibile.

Prendiamo il messaggio come un intero N-bit gigante e ne calcoliamo un altro intero N-bit usando una funzione invertibile. Un modo per farlo sarebbe quello di crittografare il messaggio con una cifra simmetrica (la cui chiave specifica quindi la funzione di hashing).

Naturalmente, gli hash che sono lunghi quanto il messaggio più lungo sono poco pratici, perché un requisito chiave per i digest dei messaggi è che hanno dimensioni fisse, di piccole dimensioni, che spesso sono molto più piccole dei messaggi digeriti stessi.

Tuttavia, se per qualsiasi motivo dovessi mai convertire un piccolo messaggio in un codice privo di collisioni e dal quale il messaggio è difficile da recuperare, quanto sopra sarebbe un modo per farlo.

1
Kaz