La dimensione dell'input è irrilevante. Infatti, a causa del paradosso dei compleanni , non è necessario più della dimensione dell'hash per rendere le collisioni garantite . Il modo migliore per evitare le collisioni è utilizzare un hash più strong che non sia loro vulnerabile, come SHA-2. Tuttavia, stai descrivendo un attacco più difficile di un attacco di collisione, chiamato attacco preimage , da cui MD5 è sicuro.

Ci sono tre tipi di attacchi ^* che danno due file con lo stesso digest:

• 1st preimage : trova un input che si risolve in un hash specifico.

• 2nd preimage : modifica un input senza modificare l'hash risultante.

• Collisione : trova due input distinti 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à non banale di input a causa del principio del pigeonhole , ma gli hash sono progettati per rendere difficile eseguire intenzionalmente . Per un hash con un'uscita della dimensione di MD5, la probabilità di una collisione casuale e accidentale è estremamente bassa. Anche se hai hash 6 miliardi di file casuali al secondo , ci vorranno 100 anni prima di avere il 50% di possibilità di scontrarsi con due hash. MD5 è ottimo per rilevare la corruzione accidentale.

Una potente funzione di hash bit n è progettata per avere un livello di sicurezza di 2 ⁿ contro gli attacchi di preimage di 1 ° e 2 ° e un livello di sicurezza di 2 ^{n / 2} contro gli attacchi di collisione. Per un hash a 128 bit come MD5, questo significa che è stato progettato per avere un livello di sicurezza di 2 ¹²⁸ contro pre-immagini e 2 ⁶⁴ contro le collisioni. Man mano che gli attacchi migliorano, il livello di sicurezza effettivo che può fornire viene lentamente eliminato.

MD5 è vulnerabile a un attacco di collisione che richiede l'equivalente di solo 2 ¹⁸ invocazioni di hash invece del previsto 2 ⁶⁴ da sfruttare. A meno che l'autore dell'attacco non generi file entrambi , non si tratta di un attacco di collisione. Un utente malintenzionato che ha un file e desidera modificarlo maliziosamente senza modificare l'hash, dovrà montare un secondo attacco preimage, che è completamente non applicabile contro MD5 con tecnologia moderna (il miglior attacco ha una complessità di 2 ^123.4 , rispetto al massimo teorico di MD5 di 2 ¹²⁸ ). Gli attacchi di collisione sono rilevanti in diverse situazioni. Ad esempio, se ti viene assegnato un eseguibile eseguito da un utente malintenzionato senza una backdoor, puoi cancellarlo e salvare l'hash. Quel eseguibile potrebbe in seguito essere sostituito con una versione backdoor, eppure 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 di sua proprietà, ma il certificato si scontrerà intenzionalmente con uno per un dominio di cui non sono proprietari.

È sicuro usare MD5 per verificare i file a patto che l'hash memorizzato non sia soggetto a manomissioni e ci si possa fidare che sia corretto, e fintanto che i file verificati non sono stati creati (o influenzati!) da un utente malintenzionato . Potrebbe comunque essere una buona idea usare un hash più strong, semplicemente per evitare che un potenziale attacco pre-attacco pratico contro MD5 in futuro metta a rischio i tuoi dati. Se desideri un hash moderno che sia molto veloce ma comunque crittograficamente sicuro, ti consigliamo di dare un'occhiata a BLAKE2 .

_{* Mentre ci sono altri attacchi contro MD5 come gli attacchi di estensione della lunghezza che riguardano tutti gli hash di Merkle-Damgård come menzionato da @LieRyan, questi non sono rilevanti per verificare l'integrità di un file rispetto a un hash noto-corretto.}

Dipende da cosa ti vuoi difendere contro

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

Come per gli algoritmi hash, puoi classificarli grossolanamente come "hash crittografici" e "hash non crittografici". Gli algoritmi di hash crittografici sono progettati per resistere a un numero di attacchi, mentre gli hash non crittografici sono progettati per essere il più veloci possibile. ¹ MD5, ad esempio, è considerato un hash crittografico, ma è così rotto che è utilizzabile solo come hash non crittografico.

Quando utilizzare un hash non crittografico

Se il tuo obiettivo è quello di rilevare i bit-flip quando copi un file da una posizione a un'altra (ad esempio, una pen drive a un laptop), quindi MD5 è la scelta giusta. Mi spingerei persino a dire che qualsiasi hash veloce e non crittografico è buono. Quando copi i file, realisticamente non devi temere l'interferenza dell'attaccante. Se sei paranoico sul fatto che gli hacker possano modificare il tuo kernel, l'aggiunta di hash non risolverà i tuoi problemi.

Verifica dell'integrità dei file con interferenze da parte dell'utente malintenzionato

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

Un esempio

Diciamo che il tuo messaggio originale m1 assomiglia a questo:

I hereby declare that the bunny rules!

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() .

Potrei essere l'autore dell'attacco nello scenario e creare un messaggio m2 che ha lo stesso identico hash nella funzione hash scelta:

It is publicly known that dogs are better than bunnies in every regard...

Poiché h(m1) = h(m2) = d1 , la firma s1 è valida sia per il tuo% originalem1 che per il mio% dannoso% co_de.

Per difendersi da tali attacchi, è fondamentale scegliere un algoritmo di hash strong con elevata resistenza alle collisioni. Ciò significa che diventa molto difficile per me trovare un m2 dove m2 .

Buone scelte includevano 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 a 16k ha richiesto 3 ms, quindi anche su un tostapane dovrebbe essere relativamente veloce.

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

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

La risposta completa dipende da quanto sei sicuro nella distribuzione degli errori .

Esiste una possibilità casuale indipendente di bit flip in ogni posizione nel file a causa della trasmissione su un canale un po 'smarrito come una porta seriale? Se è così, è possibile utilizzare MD5, ma è molto più economico utilizzare un CRC, che è garantito per rilevare un singolo bit flip, e può essere garantito dalle scelte standard del 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 smarrita. Se non sei fiducioso che gli errori sono bit di bit casuali indipendenti, non utilizzare MD5 o un CRC. È molto facile per gli avversari intelligenti trovare coppie di file distinti che condividono un comune hash MD5 o checksum CRC e in molti scenari questo può consentire a un avversario di falsificare documenti che il sistema MD5 non rileva. La dimensione del file non è rilevante: è facile trovare collisioni MD5 in file di soli 64 byte, senza limiti di tempo.

C'è un posto dove discutere le differenze tecniche tra gli attacchi di collisione, gli attacchi di pre-avvistamento e gli attacchi di seconda preimage. Una risposta a una domanda generale sul fatto che sia sicuro per verificare l'integrità dei file non è un posto del genere. Quando hai un protocollo specifico in mente dove puoi esprimere i precisi poteri dell'avversario e esattamente come si comportano gli utenti legittimi nel protocollo, e hai vincoli di implementazione che limitare la scelta delle funzioni hash in modo che debba prendere in considerazione MD5, quindi possiamo discutere (forse su crypto.SE) se è sicuro usare MD5 in quel protocollo per raggiungere la sicurezza che speri di ottenere contro un simile avversario.

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

Le dimensioni per-se non sono estremamente relavent, 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 file PDF o simili.

Perché? perché i risultati di un attacco di collisione generano in genere entrambi i file della coppia che contengono "spazzatura dall'aspetto casuale". In un formato ricco questa spazzatura dall'aspetto casuale può essere nascosta alla vista in modo che l'attaccante possa ingannare l'amministratore della raccolta ad accettare una delle loro coppie di file in collisione.

Tuttavia, in un file di testo, il contenuto è chiaro per tutti da vedere.

La dimensione del file non fa la differenza. MD5 è basato su costruzione Merkle-Damgård , che è vulnerabile a attacco di estensione della lunghezza . 15kb è un sacco per fare l'attacco di estensione della lunghezza. Esistono numerose collisioni e metodi noti per generare collisioni MD5 lunghe solo poche centinaia di byte e una volta trovata una collisione di base, essere vulnerabili all'estensione di lunghezza significa che possono essere utilizzati per generare un numero arbitrario di ulteriori collisioni.