Domanda:
È sicuro utilizzare MD5 per verificare l'integrità di piccoli file (meno di 15 kb)?
thebunnyrules
2018-05-29 08:21:04 UTC
view on stackexchange narkive permalink

So che la collisione per MD5 è stata documentata dagli anni '90 e che i certificati digitali basati su MD5 hanno dimostrato di essere completamente compromessi nel 2010, ma quanto è efficace MD5 nel garantire che piccole quantità di dati non siano state manomesse ?

Ho alcuni piccoli file di testo che hanno una dimensione di poche pagine (diciamo di 15kb). Ho usato SHA-256 su di loro, ma sarebbe molto più comodo poter usare MD5.

Quanto sarebbe sicuro MD5 come digest hash per questi piccoli file di testo da 15kb? Un malintenzionato sarebbe in grado di produrre collisioni per una quantità di dati così ridotta o le dimensioni ridotte rendono questo compito difficile?

Perché?Perché dovresti volerlo?Perché MD5 dovrebbe essere "molto più conveniente"?
Vedi anche [Un hash crittografico o un checksum identici per due file significa che sono identici?] (Https://superuser.com/q/1324629/53590) su [su].
Sicuro è la parola che stai cercando?O intendi affidabile?Probabilmente non è necessario concentrarsi sulla sicurezza per questa attività.
Il 2004 non è esattamente gli anni '90.
I file piccoli non sono sicuri.Il [certificato CA non autorizzato del 2008] (https://www.win.tue.nl/hashclash/rogue-ca/) utilizzava una collisione MD5 su una parte "da firmare" di soli 927 byte e necessitava solo del controllodi 204 di quei byte (il "blocco di collisione") per creare la collisione.
A parte qualsiasi altra cosa, tieni presente che se MD5 è più conveniente di SHA-256, allora hai già un problema.Forse non è un problema che puoi fare qualcosa su te stesso (ad esempio, forse devi comunicare con qualcosa che utilizza un vecchio protocollo con MD5 intrinsecamente associato ad esso, o qualche pezzo di hardware con MD5 accelerato ma non SHA-256).Ma oltre a considerare se arrendersi e utilizzare MD5, vale anche la pena considerare se puoi attaccare qualunque vincolo stia cercando di imporvi MD5 :-)
Le risposte seguenti sono piuttosto tecniche e illuminanti, ma non cambiano la linea di fondo.MD5 è obsoleto e non dovrebbe essere utilizzato in nessuna nuova applicazione che necessita di un hash crittografico.Questo è vero da quasi 20 anni, così a lungo che ora si può dire la stessa cosa del suo successore SHA1.Se per "conveniente" ci si riferisce all'output a 128 bit, è meglio troncare un hash moderno a 128 bit piuttosto che utilizzare MD5.Non definire cosa intendi con "conveniente" rende questa domanda probabilmente un'istanza di un [problema X-Y] (https://meta.stackexchange.com/q/66377/141193)
@James K Polk Utilizzando un hash sha2 troncato, sha3 può essere interessante ma il troncamento non li renderebbe deboli come md5?
@kaspered dalla voce wiki su md5 "Nel 1996, Dobbertin ha annunciato una collisione della funzione di compressione di MD5".Non è nemmeno vicino al 2004.
@Gordon Davidson: Da quello che ho capito dalla risposta di Forest di seguito: una collisione è solo una minaccia se il file non è stato creato da me e non ero la persona che ha preso l'hash md5 iniziale.Se qualcuno dovesse prendere il mio file e sostituirlo con un file con lo stesso hash (un attacco preimage), sarebbe molto più difficile.C'è qualcosa che mi manca o c'è qualcosa che non va nella risposta stessa?Se è così per favore spiega, magari direttamente nei commenti della risposta in modo che Forest possa rispondere.
No, troncare l'hash non lo renderà * debole * come MD5.Sarà vulnerabile agli attacchi di collisione con un fattore di lavoro dell'ordine di 2 ^ 64 passaggi, ma questo è il prezzo che devi pagare per avere un hash a 128 bit.E non sembra che la tua applicazione sia vulnerabile agli attacchi di collisione.Ancora più importante, aiuta a impedire che MD5 inquini ulteriormente l'ecosistema crittografico.
Bene, visto che lo stai mettendo in modo così poetico, come posso dire di no ...
@thebunnyrules Sei ancora in pericolo se un utente malintenzionato può controllare * parte * di un file (e prevedere cosa viene prima della parte che controlla).Questa è essenzialmente la situazione con la collisione del certificato: un'autorità di certificazione legittima ha creato il certificato, ma l '"attaccante" è stato in grado di controllare parti del certificato generato e prevedere il resto;quello era abbastanza.Nel tuo caso, se nessun utente malintenzionato può controllare * qualsiasi parte * di uno qualsiasi dei file, gli aggressori sono bloccati con un secondo attacco prima dell'immagine, a cui MD5 non è noto per essere significativamente debole.Ma preferirei comunque troncare un hash migliore.
Proprio come dice @GordonDavisson, un utente malintenzionato deve solo influenzare entrambi i file, non necessariamente essere l'unico autore.Sebbene MD5 sia tecnicamente sicuro per un modello di minaccia limitato, è comunque una buona idea eseguire l'aggiornamento a qualcosa di meglio.Dopo tutto, MD5 ha una collisione 2 ^ 18, mentre qualcosa come SHA-256 troncato a 128 bit richiederebbe 2 ^ 64 per una collisione.
Cinque risposte:
#1
+93
forest
2018-05-29 09:58:51 UTC
view on stackexchange narkive permalink

La dimensione dell'input è irrilevante. In effetti, a causa del paradosso del compleanno, non hai bisogno di più della dimensione dell'hash per garantire le collisioni. Il modo migliore per evitare le collisioni è usare un hash più forte che non sia vulnerabile a loro, come SHA-2. Tuttavia, stai descrivendo un attacco più difficile di un attacco di collisione, chiamato attacco preimage , da cui MD5 è al sicuro.

Esistono tre tipi di attacchi * che si traducono in due file con lo stesso digest:

  • 1st preimage - Trova un input che si risolva in un hash specifico.

  • Seconda immagine preliminare : modifica un input senza cambiare l'hash risultante.

  • Collisione - Trova due input distinti qualsiasi con lo stesso hash.

Questi sono chiamati attacchi quando possono essere eseguiti in modo più efficiente rispetto alla ricerca di forza bruta. Le collisioni possono ancora verificarsi in modo naturale, e in effetti sono garantite con qualsiasi quantità di input non banale a causa del principio della casella, ma gli hash sono progettati per rendere difficile intenzionalmente eseguire. Per un hash con un output delle dimensioni di MD5, la possibilità di una collisione casuale e accidentale è estremamente bassa. Anche se si esegue l'hashing di 6 miliardi di file casuali al secondo , ci vorranno 100 anni prima di avere il 50% di possibilità che due hash entrino in collisione. MD5 è ottimo per rilevare la corruzione accidentale.

Una potente funzione hash n bit è progettata per avere un livello di sicurezza di 2 n contro il primo e il secondo attacco prima dell'immagine e un livello di sicurezza di 2 n / 2 contro gli attacchi di collisione. Per un hash a 128 bit come MD5, ciò significa che è stato progettato per avere un livello di sicurezza di 2 128 contro le preimmagini e di 2 64 contro le collisioni. Man mano che gli attacchi migliorano, il livello di sicurezza effettivo che può fornire viene gradualmente ridotto.

MD5 è vulnerabile a un attacco di collisione che richiede l'equivalente di solo 2 18 invocazioni hash invece delle 2 64 previste da sfruttare. A meno che l'aggressore non generi entrambi file, non si tratta di un attacco di collisione. Un utente malintenzionato che ha un file e desidera modificarlo in modo dannoso senza il la modifica dell'hash avrebbe bisogno di montare un secondo attacco preimage, che è completamente irrealizzabile contro MD5 con la tecnologia moderna (il miglior attacco ha una complessità di 2 123,4 sup >, rispetto al massimo teorico di MD5 di 2 128 ). Gli attacchi di collisione sono rilevanti in diverse situazioni. Ad esempio, se ti viene fornito un eseguibile creato da un utente malintenzionato senza backdoor, puoi eseguirne l'hash e salvare l'hash. Quell'eseguibile potrebbe quindi essere successivamente sostituito con una versione backdoor, ma l'hash sarebbe lo stesso di quello benigno! Questo è anche un problema per i certificati in cui qualcuno potrebbe inviare un certificato per un dominio che possiede, ma il certificato entrerebbe intenzionalmente in collisione con uno per un dominio che non possiede.

È sicuro utilizzare MD5 per verificare i file fintanto che l'hash memorizzato non è soggetto a manomissioni e ci si può fidare che sia corretto, e fintanto che i file da verificare non sono stati creati (o influenzati!) Da un utente malintenzionato. Potrebbe comunque essere una buona idea utilizzare un hash più forte, semplicemente per evitare che un potenziale attacco preimage pratico contro MD5 in futuro metta a rischio i tuoi dati. Se desideri un hash moderno che sia molto veloce ma ancora crittograficamente sicuro, potresti dare un'occhiata a BLAKE2.

* Sebbene ci siano altri attacchi contro MD5 come attacchi di estensione della lunghezza che interessano tutti gli hash Merkle – Damgård come menzionato da @LieRyan, questi non sono rilevanti per verificare l'integrità di un file rispetto a un hash noto e corretto.

Una variante dell'attacco di collisione chiamato attacco di collisione con prefisso scelto è in grado di accettare due messaggi arbitrari (prefissi) e trovare due valori che, quando viene aggiunto a ciascun messaggio, risulta in un digest in collisione. Questo attacco è più difficile da eseguire rispetto a un classico attacco di collisione. Come l'attacco di estensione della lunghezza, questo si applica solo agli hash Merkle – Damgård.

Va aggiunto che oltre al fatto che un secondo attacco preimage non è di per sé realizzabile, un secondo attacco preimage _ significativo_ è ancora più difficile.Non è necessario solo trovare _any_ blob che produce lo stesso hash (che è un'attività complessa 2 ^ 123), ma uno che sia plausibile (cioè in questo caso un file di testo leggibile, significativo, non incomprensibile).Ora aggiungi la lunghezza del file al tuo hash per rafforzarlo ulteriormente (rendendo impossibile, ad esempio, l'aggiunta di caratteri non stampabili) e vorrei davvero vedere qualcuno che lo tira fuori.
@Damon Non è necessario aggiungere la lunghezza del file a un hash.Infatti, gli hash Merkle – Damgård (di cui MD5 è uno) codificano la lunghezza dei dati da sottoporre ad hashing nel blocco finale.Inoltre, limitare i tipi di input non rende un attacco preimage molto più difficile.Significa solo che sei più limitato nei bit che puoi attivare, il che non è davvero un limite fintanto che sei in grado di attivare o disattivare alcune dozzine di bit.
Cosa intendi esattamente dicendo che SHA-2 "non è vulnerabile" alle collisioni?
@forest: Non sono sicuro che tu abbia ragione al 100%.Sebbene sia vero che gli hash M-D codificano la lunghezza dei dati, è comunque possibile hash "foo" e "foo2" benissimo, ed entrambi produrranno un blob a 128 bit che è agnostico della lunghezza del messaggio originale.Se "foo" e "foo2", o forse "foo1234" si scontrano, ed è tutto ciò che vuoi alla fine, hai un attacco funzionante.Se, tuttavia, è _esplicitamente_ noto che "foo" ha 3 lettere (non 4, né 6, né 8), allora è difficile da ottenere.
@Damon È esplicitamente noto che "foo" ha 3 lettere (o meglio, 3 × 8 = 24 bit).Vedere [RFC 1321] (https://www.ietf.org/rfc/rfc1321.txt) § 3.2.Ciò significa che non è agnostico rispetto alla lunghezza originale._H (m || length (m)) _ non offre alcun vantaggio rispetto a _H (m) _.
@forest: Immagino che allora i ragazzi che hanno hackerato Flickr nel 2009 fossero tutti bugiardi, dal momento che non esiste qualcosa come un attacco di estensione di lunghezza su MD5.Colpa mia, ho frainteso l'approccio.
@Damon Penso che tu fraintenda come funziona un attacco di estensione della lunghezza.C'è una [risposta utile] (https://crypto.stackexchange.com/a/3979/54184) sul sito Cryptography che spiega perché è possibile nonostante il riempimento.Puoi prevenirlo _prependendo_ un valore di lunghezza (o usando una costruzione progettata per resistere ad attacchi come HMAC), ma semplicemente "codificare esplicitamente la lunghezza" non è quasi sufficiente.
@chrylis Intendevo dire che tutti gli hash della famiglia SHA-2 non sono soggetti ad attacchi noti che rendono le collisioni significativamente più facili da costruire rispetto a una ricerca esaustiva.
Non è abbastanza che i file non siano "creati da un utente malintenzionato": anche se un utente malintenzionato controlla solo una parte dei file, potrebbe comunque essere in grado di forzare una collisione.
Cordiali saluti, il presunto attacco preimage a MD5 ha un rapporto prezzo / prestazioni molto peggiore rispetto agli attacchi generici;nel migliore dei casi è un'osservazione teoricamente interessante, nemmeno un attacco teorico.Ma io consiglio vivamente di evitare di cavillare sui dettagli di diversi tipi di attacchi su MD5 a un pubblico generale senza l'esperienza di riconoscere quanto sia difficile la progettazione del protocollo o di riconoscere come le collisioni o le estensioni di lunghezza possono essere sfruttate per la contraffazione.Il pensiero ingenuo a questo proposito induce le persone a fare scelte irresponsabili come usare MD5 in rsync e le rende resistenti alla risoluzione dei problemi.
Ad esempio, l'aggressore non deve produrre entrambi i file.I certificati MD5 sono stati falsificati _in pratica_ da un aggressore che poteva _predire_ parti dei file non sotto il loro controllo e controllare _alcuni_ file.In assenza di un modello molto più specifico di quali siano le azioni dell'utente legittimo e i poteri dell'avversario, è probabile che questo consiglio metta qualcuno nei guai se non si prende il tempo di studiare la progettazione del protocollo e calcolare le conseguenze per se stesso.
#2
+12
MechMK1
2018-05-29 14:26:50 UTC
view on stackexchange narkive permalink

Dipende da cosa vuoi difenderti

La sicurezza non è mai un gioco valido per tutti. Se lo fosse, non ci sarebbero 12941 algoritmi hash diversi. Invece, devi capire che ogni misura di sicurezza ti difende da un tipo specifico di attacco. Metti una password nel tuo computer per difenderti dall'accesso di persone casuali, non perché sia ​​così divertente digitare whereD1DweG0sowron6 ogni volta che accedi.

Per quanto riguarda gli algoritmi hash, puoi farlo grossolanamente classificarli come "hash crittografici" e "hash non crittografici". Gli algoritmi di hash crittografici sono progettati per resistere a numerosi attacchi, mentre gli hash non crittografici sono progettati per essere il più veloci possibile. 1 MD5, ad esempio, è considerato un hash crittografico, ma così rotto da essere utilizzabile solo come hash non crittografico.

Quando utilizzare un hash non crittografico

Se il tuo obiettivo è rilevare i salti di bit quando si copia un file da una posizione a un'altra ( diciamo, una pen drive per un laptop), quindi MD5 è assolutamente la scelta giusta. Mi spingerei addirittura a dire che qualsiasi hash veloce e non crittografico è buono. Quando copi i file, realisticamente non devi temere l'interferenza di un aggressore. Se sei paranoico sul fatto che gli hacker siano in grado di modificare il tuo kernel, l'aggiunta di hash non risolverà i tuoi problemi.

Verificare l'integrità del file con l'interferenza di un utente malintenzionato

Se intendi firmare e pubblicare quelli file, quindi un utente malintenzionato potrebbe avere la capacità di creare un file possibilmente legittimo con lo stesso hash, il che significa che la tua firma è altrettanto valida sul file dannoso.

Un esempio

Let's dì che il tuo messaggio originale m1 assomiglia a questo:

Con la presente dichiaro che le regole del coniglio!

Usi la tua funzione hash h (m1) e ottieni il digest d1 . Successivamente, firmi il digest d1 e ottieni una firma s1 .

Quindi pubblichi il tuo messaggio m1 , la tua firma s1 e la tua funzione hash h().

I potrebbe essere l'attaccante nello scenario e creare un messaggio m2 che abbia lo stesso hash nella funzione hash scelta:

È noto pubblicamente che i cani sono migliori di coniglietti sotto ogni aspetto ...

Poiché h (m1) = h (m2) = d1 , la firma s1 è valida sia per il tuo m1 originale e per il mio dannoso m2.

Per difenderti da tali attacchi, è fondamentale scegliere un algoritmo hash potente con alta resistenza agli urti. Ciò significa che diventa molto difficile per me trovare un m2 dove h (m2) = h (m1) .

Buone scelte includerebbero SHA256 e SHA512, così come tonnellate di altri. Sembra che tutti abbiano alcune funzioni hash preferite non tradizionali, ma SHA256 e SHA512 hanno un supporto molto diffuso e sarà difficile per te trovare un sistema che non supporti questi hash. E poiché i tuoi file sono molto piccoli, il calcolo dell'hash dovrebbe essere quasi istantaneo.

Ad esempio, sulla mia macchina a 800 MHz, il calcolo dell'hash SHA512 di un file casuale da 16k ha richiesto 3 ms, quindi anche su un tostapane dovrebbe essere relativamente veloce.


1 Puoi vedere la stessa cosa con i generatori di numeri casuali. I PRNG crittografici mirano a fornire numeri casuali che sono davvero difficili da indovinare, mentre i PRNG non crittografici mirano a fornire solo numeri che sembrano casuali a prima vista e lo fanno velocemente.

Anche se nulla di ciò che stai dicendo è sbagliato, non menzioni MD5 da nessuna parte nella risposta.Questa domanda riguarda MD5 e verifica dell'integrità del file.MD5 è AFAIK perfettamente adatto a questo scopo (con l'avvertenza che a volte le crepe nella progettazione dell'algoritmo suggeriscono altri possibili difetti).
L'attacco che stai descrivendo è un attacco in prima immagine.Lo scenario in cui un attacco di collisione sarebbe rilevante sarebbe se qualcun altro ti desse un programma e ti chiedesse di verificare che non ci fosse niente di male in esso e pubblicasse o firmasse un messaggio che dice "il programma con hash __ è sicuro".Un utente malintenzionato potrebbe (usando un attacco di collisione) escogitare due programmi identici tranne che per il contenuto di una stringa letterale, e escogitare cose in modo che (1) un programma fosse benigno e l'altro dannoso, e (2) entrambi i programmi avrebbero hashallo stesso valore.
@SteveSether Cito MD5 quando parlo di hash non crittografici.Se viene utilizzato esclusivamente per verificare l'integrità dei file senza l'interferenza di un utente malintenzionato, MD5 è sicuro da usare, ma non è la scelta migliore.
@supercat In effetti, ma era solo un esempio di come poteva apparire l'interferenza di un utente malintenzionato.In entrambi i casi, è una buona idea utilizzare un potente algoritmo di hash crittografico, come quelli che ho suggerito
Sto downvoting questo perché la risposta implica che MD5 non è adatto per hash crittografici.Come sottolinea la foresta sopra, è perfettamente accettabile per ALCUNI scopi crittografici, ma non per l'attacco di collisione menzionato da @supercat e dalla foresta.
@DavidStockinger: Non ho profilato le prestazioni di MD5 rispetto ad altri hash, ma nei casi in cui le prestazioni contano, un hash più veloce che non sarebbe sicuro in tutti i casi d'uso ma è sicuro in quello che conta, potrebbe essere migliore di un hash più lentoche sarebbe anche sicuro in casi d'uso irrilevanti.
#3
  0
Lie Ryan
2018-05-29 09:11:45 UTC
view on stackexchange narkive permalink

La dimensione del file non fa differenza. MD5 si basa sulla costruzione Merkle – Damgård, che è vulnerabile all ' attacco di estensione della lunghezza. 15kb sono sufficienti per l'attacco di estensione della lunghezza. Esistono molte collisioni e metodi noti per generare collisioni MD5 lunghe solo poche centinaia di byte e, una volta rilevata una collisione di base, essere vulnerabili all'estensione della lunghezza significa che possono essere utilizzati per generare un numero arbitrario di ulteriori collisioni.

In che modo l'attacco di estensione della lunghezza è rilevante per garantire che i file non siano stati manomessi?Tutte le collisioni arbitrarie richiedono che i file inizino effettivamente con una collisione, dopodiché può essere ulteriormente estesa.Non consente di sostituire un file arbitrario e innocuo con un file dannoso con lo stesso hash.
La spiegazione dell'attacco di estensione della lunghezza a cui ti colleghi su Wikipedia non corrisponde affatto a questa situazione, poiché è improbabile che produca un file compromesso che abbia un / matching / hash.
L'attacco di estensione della lunghezza è progettato per proteggersi dallo scenario in cui qualcuno che conosce l'hash di un messaggio ma non il suo contenuto può determinare quale sarebbe l'hash del messaggio se qualche contenuto aggiuntivo specifico fosse aggiunto.Dare all'attaccante un modo per capire quale sarebbe il valore hash di un file non sembra una grande vulnerabilità nello scenario dell'OP.
#4
  0
Peter Green
2018-05-29 22:36:24 UTC
view on stackexchange narkive permalink

La dimensione di per sé non è estremamente rilevante, i dati di collisione effettivamente possono essere piccoli come un singolo blocco.

Tuttavia sei molto più sicuro con una raccolta di file di testo che con una raccolta di PDF o simili.

Perché? perché i risultati di un attacco di collisione generalmente si traducono in entrambi i file della coppia contenenti alcuni "rifiuti dall'aspetto casuale". In un formato ricco, questa spazzatura dall'aspetto casuale può essere nascosta alla vista in modo che l'attaccante possa indurre l'amministratore della raccolta ad accettare uno dei loro due file in conflitto.

In un file di testo, tuttavia, il contenuto è visibile a tutti.

Questo è parzialmente errato.Un attacco di collisione MD5 non deve comportare il capovolgimento di bit casuali.Puoi facilmente limitare i bit che intendi capovolgere a quelli che cambiano semplicemente i caratteri ASCII stampabili in caratteri non stampabili (come ENQ o NAK).Per qualsiasi file ASCII non banale, ci saranno _ abbondanza_ di bit che puoi modificare liberamente senza danneggiare visibilmente il testo.
#5
  0
Squeamish Ossifrage
2018-05-30 18:40:10 UTC
view on stackexchange narkive permalink

Risposta breve: No, non è sicuro utilizzare MD5 per verificare l'integrità dei file, brevi o lunghi.

La risposta completa dipende da quanto si è sicuri sei nella distribuzione degli errori .

Esiste una possibilità casuale indipendente di salti di bit in ogni posizione nel file a causa della trasmissione su un canale leggermente con perdita come una porta seriale? Se è così, potresti usare MD5, ma è molto più economico usare un CRC, che è garantito per rilevare un singolo bit flip, e può essere garantito da scelte standard di polinomio CRC per rilevare tutti i numeri dispari di bit flip.

Ma hai chiesto informazioni su secure , il che suggerisce che stai considerando avversari leggermente più intelligenti di una porta seriale con perdita. Se non sei sicuro che gli errori siano lanci di bit casuali indipendenti, non utilizzare MD5 o un CRC. È molto facile per gli avversari intelligenti trovare le coppie di file distinti che condividono un hash MD5 comune, o checksum CRC, e in molti scenari questo può consentire a un avversario di falsificare documenti che il sistema MD5 non rileverà. La dimensione del file non è rilevante: è facile trovare collisioni MD5 in file di soli 64 byte, senza limiti sulla lunghezza che possono essere.

C'è un posto per discutere le differenze tecniche tra attacchi di collisione, attacchi preimage e attacchi second preimage. Una risposta a una domanda generale sul fatto che sia sicuro verificare l'integrità dei file non è un posto del genere. Quando hai in mente un protocollo specifico in cui puoi articolare i poteri precisi dell'avversario ed esattamente come si comporteranno gli utenti legittimi nel protocollo, e hai vincoli di implementazione che limitare la scelta delle funzioni hash in modo da dover considerare MD5, quindi possiamo discutere (magari su crypto.SE) se è sicuro utilizzare MD5 in quel protocollo per ottenere la sicurezza che speri di ottenere contro un tale avversario.

Ma sarebbe molto più semplice e sicuro per te usare semplicemente SHA-2, SHA-3 o BLAKE2.

Il downvoter si preoccuperebbe di spiegare ciò con cui non sei d'accordo in questo post?


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...