MD5 è ancora abbastanza buono per identificare in modo univoco i file?

139

L'hash MD5 è un file ancora considerato un metodo abbastanza buono per identificarlo in modo univoco, data la rottura dell'algoritmo MD5, i problemi di sicurezza ecc.? La sicurezza non è la mia preoccupazione principale qui, ma identificare in modo univoco ogni file lo è.

qualche idea?

hash md5

— Ranhiru Jude Cooray
fonte

2

Attualmente lo sto usando da solo in una delle mie applicazioni e, per quanto ne so, è abbastanza buono per identificare in modo univoco i file.

— Non disponibile dal

2

Probabilmente troverai questa domanda: stackoverflow.com/questions/862346/… utile.

— sharptooth,

Quanti file devi identificare? Produce 128 bit, quindi se stai cercando di identificare alcune migliaia di file, va bene. Ma se stai cercando di identificarti molto di più, potresti imbatterti in collisioni / il paradosso del compleanno.

— Marcin,

Saranno file di immagine, jpg, png e gif. E sì, penso che il limite sarebbe di qualche migliaio ... Ma quanti file pensi che mi causeranno problemi?

— Ranhiru Jude Cooray,

Correlati: stackoverflow.com/questions/14973197/...

— NeDark

89

Sì. L'MD5 è stato completamente rotto dal punto di vista della sicurezza, ma la probabilità di una collisione accidentale è ancora minuscola. Assicurati solo che i file non vengano creati da qualcuno di cui non ti fidi e che potrebbe avere intenzioni dannose.

— Marcelo Cantos
fonte

2

@none: per la tua prima domanda, vedi qui . Temo di non capire le altre domande.

— Marcelo Cantos,

9

@ 0xA3: Né tu né io abbiamo idea di quali file si riferisca all'OP o di quanti danni potrebbe causare un compromesso. Potrebbe essere la raccolta di foto per bambini del loro bambino per quanto ne sappiamo. Il mio obiettivo è fornire i fatti; ciò che qualcun altro fa con loro sono i loro affari. Considera anche che Bruce Schneier consiglia di scrivere la tua password; non tutto deve essere conservato a Fort Knox. Alcune cose andranno bene sotto il vaso di fiori.

— Marcelo Cantos,

3

@Marcelo Cantos, penso che ciò che manca qui sia una differenziazione o decompressione del termine "sicurezza". Ovviamente le persone stanno assumendo "sicurezza" per qualsiasi uso del lavoro di checksum, ma la nomenclatura che probabilmente Marcelo intende è "in un laboratorio".

— hpavc,

5

Sono fortemente in disaccordo. Un diverso valore di hash indica che i file sono diversi. Ma per un valore di hash uguale: non puoi dire "è molto probabile che entrambi siano uguali" se l'hash è lo stesso: puoi confrontare solo byte per byte. Un hash ha molti ordini di grandezza inferiori al numero di valori diversi per l'intero file, quindi ci sono molte, molte, molte possibili collisioni per ciascun valore di hash. Solo se stai copiando un file noto (con un hash noto) un identico valore hash "probabilmente significa" che il 2 ° è stato copiato correttamente (anche allora non è sicuro al 100%, ma molto probabile).

— Olivier Dulac,

3

OK, la mia matematica fa schifo. I GUID hanno circa 122 bit di entropia, quindi la probabilità di una collisione in un punto qualsiasi in un miliardo di file è di circa 2 ^ (2 * 30 - 122) = 2 ^ -62. Mentre questo è molto più alto del mio calcolo originale, è ancora minuscolo a circa uno su 4 quintilioni.

— Marcelo Cantos,

32

Ai fini pratici, l'hash creato potrebbe essere opportunamente casuale, ma teoricamente esiste sempre una probabilità di una collisione, a causa del principio Pigeonhole . Avere hash diversi significa sicuramente che i file sono diversi, ma ottenere lo stesso hash non significa necessariamente che i file siano identici.

L'uso di una funzione hash a tale scopo - indipendentemente dal fatto che la sicurezza sia un problema o meno - dovrebbe quindi essere sempre solo il primo passo di un controllo, soprattutto se è noto che l'algoritmo hash crea facilmente collisioni. Per scoprire in modo affidabile se due file con lo stesso hash sono diversi, è necessario confrontare tali file byte per byte.

— stapeluberlauf
fonte

16

@Ranhiru. No. L'hash ti dà un valore "sommario" che (per MD5) è lungo solo 16 byte. Per garantire che i file siano identici, è necessario effettuare un controllo byte per byte. Questo è vero indipendentemente dall'algoritmo di hash che scegli, c'è sempre la possibilità di una collisione.

— PaulG,

6

@Ranhiru. Rileggi questa risposta, è la più completa qui. L'hashing potrebbe essere usato come primo passo, che ti porta al 99,99 ^ e% certezza che i file sono identici, ma se vuoi essere assolutamente sicuro al 100% , dovrai fare un controllo byte per byte. Questo è vero se usi MD5, SHA o qualsiasi altro algoritmo.

— PaulG,

7

Questa risposta è sbagliata La prevenzione della manomissione e la verifica dell'unicità sono la stessa cosa. Inoltre, mentre l'hashing non garantisce l'unicità, non lo è nemmeno il confronto effettivo. In effetti, la probabilità che un hash si scontri accidentalmente è in realtà inferiore alla probabilità che il confronto fallisca a causa di anomalie nella CPU generate dalle normali emissioni di raggi gamma solari. E non dimenticare che spesso l'unica fonte del file si trova dall'altra parte del mondo all'interno di un server Web e l'unica informazione indipendente che hai a fini di confronto è l'hash.

— Marcelo Cantos,

8

@Marcelo. Non sopporta il ragionamento logico che la collisione accidentale è meno probabile dei capovolgimenti accidentali dei bit (mentre si effettua un confronto byte per byte). Hai ancora la stessa possibilità di lanci di bit durante la creazione dell'hash (e probabilmente di più poiché è necessario più tempo di elaborazione). @Thomas ha sollevato il punto originariamente per suggerire che non esiste un modo garantito per identificare l'unicità, sebbene l'impatto dei bit flip sia altamente discutibile. La stima più pessimistica è 1 capovolgimento per GB / ora e la RAM ECC eliminerebbe anche quello.

— PaulG

2

"la probabilità che un hash si scontri accidentalmente è in realtà inferiore alla probabilità che il confronto fallisca a causa di anomalie nella CPU generate dalle normali emissioni di raggi gamma solari" [citazione necessaria]

— endolith

20

MD5 sarà abbastanza buono se non hai avversari. Tuttavia, qualcuno può (di proposito) creare due file distinti che hanno lo stesso valore (che si chiama collisione), e questo può o meno essere un problema, a seconda della situazione esatta.

Poiché sapere se i punti deboli noti di MD5 si applicano a un determinato contesto è una questione sottile, si consiglia di non utilizzare MD5. L'uso di una funzione hash resistente alle collisioni (SHA-256 o SHA-512) è la risposta sicura. Inoltre, usare MD5 è una cattiva relazione pubblica (se usi MD5, preparati a giustificarti; mentre nessuno metterà in dubbio l'utilizzo di SHA-256).

— Thomas Pornin
fonte

2

Questa risposta potrebbe essere un po 'fuorviante se il lettore non ha familiarità con l'hashing. Non c'è nulla di magico in SHA che prevenga le collisioni di hash, sono solo più resistenti agli attacchi di collisione di hash . Se si desidera essere più del 99.999 ^ e% certi che i file siano identici, è comunque necessario un controllo byte per byte.

— PaulG,

7

In realtà un confronto byte-byte può fallire a causa di un raggio cosmico che si ribalta un po '(ad es. Trasformando a return 0;in a return 1;). Ciò è altamente improbabile, ma il rischio di una collisione con SHA-256 è persino inferiore. Matematicamente, non si può essere sicuri che due file con hash dello stesso valore siano identici, ma non si può essere sicuri nemmeno confrontando i file stessi, purché si usi un computer per il confronto. Quello che voglio dire è che non ha senso andare oltre 99.999 .... certezza del 9% e SHA-256 ne fornisce già di più.

— Thomas Pornin,

2

Cosa, non usi la memoria ECC? ;). Buon commento, pensieri molto interessanti.

— PaulG,

1

Non dimenticare il cappello di stagnola! Più seriamente, come conosci questi factoidi sulle collisioni e lo hai verificato in qualche modo?

— James P.

@ThomasPornin Il lancio di bit di raggi cosmici influirebbe anche sul metodo MD5, quindi è ancora peggio.

— endolith,

9

Un md5 può produrre collisioni. Teoricamente, sebbene altamente improbabile, un milione di file di fila può produrre lo stesso hash. Non testare la fortuna e controllare le collisioni md5 prima di memorizzare il valore.

Personalmente mi piace creare md5 di stringhe casuali, il che riduce il sovraccarico di hashing di file di grandi dimensioni. Quando vengono rilevate le collisioni, eseguo l'iterazione e la ripetizione dell'hash con il contatore di loop aggiunto.

Puoi leggere sul principio del buco del piccione .

— afilina
fonte

6

Non lo consiglierei. Se l'applicazione funzionasse su un sistema multiutente, potrebbe esserci un utente che avrebbe due file con lo stesso hash md5 (potrebbe essere ingegnere e giocare con tali file, o essere solo curioso - sono facilmente scaricabili da http: / /www2.mat.dtu.dk/people/S.Thomsen/wangmd5/samples.html , io stesso durante la scrittura di questa risposta ho scaricato due esempi). Un'altra cosa è che alcune applicazioni potrebbero archiviare tali duplicati per qualsiasi motivo (non sono sicuro, se ci sono tali applicazioni ma esiste la possibilità).

Se stai identificando in modo univoco i file generati dal tuo programma, direi che va bene usare MD5. Altrimenti, consiglierei qualsiasi altra funzione hash in cui non sono ancora note collisioni.

— Tach
fonte

2

Personalmente penso che le persone utilizzino checksum non elaborati (scegli il tuo metodo) di altri oggetti per agire in modo eccessivo come identificatori univoci quando vogliono veramente fare è avere identificatori univoci. L'impronta digitale di un oggetto per questo uso non era l'intento ed è probabile che richieda più pensiero che usare un uuido o un meccanismo di integrità simile.

— hpavc
fonte

0

MD5 è stato rotto, è possibile utilizzare SHA1 invece (implementato nella maggior parte delle lingue)

— Guillaume Lebourgeois
fonte

Questa è una risposta perfettamente valida. MD5 è inaccettabile per i casi d'uso in Diritto e contabilità in Europa da maggio 2018 in poi.

— Bert Sinnema,

@BertSinnema potresti indicarmi la fonte che definisce quali funzioni di hash sono accettabili ecc., Per favore?

— berezovskyi,

@GregSchmit forse perché a OP non interessava la forza crittografica in sé. Ho capito la domanda come "Uso già MD5 in un contesto non di sicurezza, devo dedicare tempo per aggiornare il codice?" tipo di cosa. E in questo contesto la risposta era probabilmente sbagliata e anche SHA1 è stata interrotta da allora.

— berezovskyi,

0

Quando si esegue l'hashing di stringhe (o file) brevi (<poche K?), È possibile creare due chiavi hash md5, una per la stringa effettiva e una seconda per il contrario della stringa concatenata con una stringa asimmetrica breve. Esempio: md5 (reverse (stringa || '1010')). L'aggiunta della stringa aggiuntiva garantisce che anche i file costituiti da una serie di bit identici generino due chiavi diverse. Si prega di comprendere che anche con questo schema esiste una probabilità teorica che le due chiavi hash siano identiche per stringhe non identiche, ma la probabilità sembra eccessivamente piccola - qualcosa nell'ordine del quadrato della singola probabilità di collisione md5 e il risparmio di tempo può essere considerevole quando il numero di file è in aumento. Potrebbero essere considerati anche schemi più elaborati per la creazione della seconda stringa,

Per verificare le collisioni, è possibile eseguire questo test per l'univocità delle chiavi hash md5 per tutti i bit_vector in un db:

seleziona md5 (bit_vector), count (*), bit_and (bit_vector) da db con bit_vector
group di md5 (bit_vector), bit_vector con bit_and (bit_vector) <> bit_vector

— Marco Polo
fonte

Idea intelligente. Se un "attaccante" crea un file falso con lo stesso hash md5, non sarà di aiuto a meno che non conosca il tuo "salting", e invertire i contenuti creerebbe un hash diverso. L'uso di 2 tasti md5 in questo modo ridurrebbe molto le probabilità. Se è solo per prevenire un "attacco" usando un sale prima di calcolare localmente sarà sufficiente.

— Wolf5,

0

Mi piace pensare a MD5 come un indicatore di probabilità quando si memorizza una grande quantità di dati di file.

Se gli hash sono uguali, so che devo confrontare i file byte per byte, ma ciò potrebbe accadere solo poche volte per un falso motivo, altrimenti (gli hash non sono uguali) posso essere certo che stiamo parlando di due file diversi .

— Shimmy Weitzhandler
fonte