Perché MD5 e SHA-1 sono ancora utilizzati per i checksum e i certificati se sono chiamati interrotti?

SHA-1 e MD5 sono interrotti nel senso che sono vulnerabili agli attacchi di collisione. Cioè, è diventato (o, per SHA-1, diventerà presto) realistico trovare due stringhe che hanno lo stesso hash.

Come spiegato qui , gli attacchi di collisione non influiscono direttamente sulle password o sull'integrità dei file perché questi cadono sotto il preimage e secondo caso di preimage, rispettivamente.

Tuttavia, MD5 e SHA-1 sono ancora meno computazionalmente costosi. Le password con hash con questi algoritmi sono più facili da decifrare rispetto agli algoritmi più potenti attualmente esistenti. Sebbene non specificamente rotto, è consigliabile utilizzare algoritmi più potenti.

Nel caso dei certificati, le firme indicano che un hash di un determinato certificato è valido per un determinato sito web. Ma se riesci a creare un secondo certificato con quell'hash, puoi impersonare altri siti web. Nel caso di MD5, questo è già successo ei browser elimineranno gradualmente SHA-1 come misura preventiva ( fonte ) -out-certificati-con-sha-1 una firma algoritmi basati-.

Il controllo dell'integrità dei file è spesso inteso a garantire che un file sia stato scaricato correttamente. Tuttavia, se viene utilizzato per verificare che il file non sia stato manomesso, è necessario prendere in considerazione un algoritmo più resistente alle collisioni (vedere anche: attacchi con prefisso prescelto ).

Per MD5, nessuno che sia rispettabile e competente lo sta utilizzando in un contesto in cui la resistenza alla collisione è importante. Per SHA-1, è in fase di eliminazione; la rottura di SHA-1 non era pratica quando è stata rilasciata, e solo ora sta diventando importante pensare di eliminarla gradualmente dove è richiesta la resistenza alle collisioni. In effetti, è in fase di eliminazione; per esempio, i certificati TLS a lungo termine con SHA-1 non funzionano più su Chrome, per spingere le persone a passare a SHA-2. Tuttavia, non è ancora praticamente rotto, quindi per ora è accettabile.

La ragione per cui non è stata rilasciata per tutto immediatamente è perché la sicurezza comporta dei compromessi. Non abbandonare uno standard importante e rendere tutto incompatibile con una base di installazione gigante sulla base di qualcosa che potrebbe portare a attacchi pratici nel giro di un decennio. La compatibilità è importante.

Inoltre, per molti usi, MD5 e SHA-1 non sono affatto incrinati. Entrambi hanno punti deboli contro la resistenza alle collisioni, il che significa che un utente malintenzionato può creare due messaggi che cancellano la stessa cosa. Nessuno dei due è rotto contro la resistenza di preimage (dato un hash, trova qualcosa che fa quell'hash), o contro la resistenza del secondo preimage (dato un messaggio, trova un messaggio diverso con lo stesso hash), o (le loro funzioni di compressione) come pseudo-casuale funzioni. Ciò significa che le costruzioni come HMAC-MD5 possono ancora essere sicure, perché non si basa sulla proprietà di MD5 che è rotta. Meno che ideale, certo, ma vedi "la compatibilità conta se è ancora sicuro" sopra.

Il controllo dell'integrità dei file tramite hash è quasi sempre inutile; a meno che gli hash non vengano inviati su un canale più sicuro del file, è possibile manomettere gli hash così facilmente come con il file. Tuttavia, se gli hash sono inviati in modo più sicuro del file, MD5 e SHA-1 sono ancora in grado di proteggere l'integrità dei file. Poiché l'autore dell'attacco non ha l'influenza alcuna sui file legittimi (e ci deve essere l'influenza zero per essere al sicuro), la creazione di un nuovo file con lo stesso hash richiede infrangendo la seconda resistenza preimage, che nessuno ha mai fatto per MD5 o SHA-1.

Notare la differenza tra controllo dell'integrità e certificati. I certificati sono emessi da una CA da un CSR creato dall'utente; l'attaccante può avere un'influenza enorme sul contenuto del certificato reale, quindi un attacco di collisione consente a un utente malintenzionato di creare un certificato legittimo e falso che collide, ottiene il certificato legittimo e utilizza la firma su quello falso. Al contrario, nell'integrità dei file, l'attaccante normalmente ha il controllo zero sul file legittimo, quindi ha bisogno di ottenere una collisione con un file dato , che è molto più difficile (e che per quanto sappiamo non può essere fatto con MD5).

MD5 e SHA-1 sono veloci e potrebbero essere supportati nell'hardware, a differenza degli hash più recenti e più sicuri (anche se Bitcoin probabilmente lo ha cambiato con l'uso di SHA-2 dando origine al mining chip che calcolano collisioni SHA-2 parziali).

Le collisioni MD5 sono fattibili e sono stati fatti avanzamenti di attacco preimage; è a collisione SHA-1 pubblicamente per l'algoritmo ufficiale a tutto tondo, dopo altri attacchi che riducono significativamente la sua effettiva complessità , che potrebbe non essere ancora abbastanza pratico per l'attaccante occasionale ma nel regno delle possibilità, motivo per cui può essere chiamato rotto.

Ciononostante, gli hash "deboli" o interrotti possono ancora essere utili per gli usi che non hanno bisogno di algoritmi crittograficamente sicuri, ma per molti scopi che inizialmente non erano considerati critici possono risulta per esporre una potenziale superficie di attacco.

Buoni esempi potrebbero trovare file duplicati o utilizzare in sistemi di controllo della versione come git - nella maggior parte dei casi, si desiderano buone prestazioni con elevata affidabilità, ma non è necessaria una protezione rigorosa - dando a qualcuno l'accesso in scrittura un repository git ufficiale ti richiede già di fidarti di altre persone per non scherzare, e i controlli di duplicazione dovrebbero anche confrontare i contenuti dopo aver scoperto che due file hanno le stesse dimensioni e hash.

Il backup non sufficientemente accurato di hash con fatti (ad es. confronto byte per byte) può essere un rischio, ad es. quando a qualcuno come Dropbox è stata applicata la deduplicazione con MD5 senza una corretta verifica e un utente malintenzionato si è intrufolato nei dati con collisioni di hash per causare la perdita di dati.

git affronta questo problema "fidandosi l'anziano ", come Linus stesso ha detto:

if you already have a file A in git with hash X is there any condition where a remote file with hash X (but different contents) would overwrite the local version?

     

No. Se ha lo stesso SHA1, significa che quando riceviamo il   oggetto dall'altra parte, non sovrascriverà l'oggetto   già.

     

Quindi quello che succede è che se mai vedremo una collisione, la "prima"   l'oggetto in un particolare repository finirà sempre per sovrascrivere.   Ma nota che "prima" è ovviamente per-repository, nel senso   che la rete dell'oggetto Git genera un DAG che non è completamente   ordinato, così mentre diversi repository saranno d'accordo su ciò che è   "prima" nel caso di discendenza diretta, se l'oggetto è venuto attraverso   rami separati e non direttamente collegati, due diversi repository possono   ovviamente hanno ottenuto i due oggetti in ordine diverso.

     

Tuttavia, il "precedente sostituirà" è molto quello che vuoi da un   punto di vista della sicurezza: ricorda che il modello git è quello che dovresti   fidatevi principalmente del vostro repository proprio . Quindi se fai un "git pull",   i nuovi oggetti in arrivo sono per definizione meno affidabili di   oggetti che hai già, e in quanto tale sarebbe sbagliato consentire a   nuovo oggetto per sostituire uno vecchio.

[Fonte originale: link

E come si suol dire, un errore del disco è probabilmente più probabile che incontrare una collisione dell'hash accidentale (diversi ordini di grandezza - collisione SHA-1 < 10 ^-40 ; errore di bit non ripristinabile del disco ~ 10 ^-15 ).

Sebbene possano esistere collisioni, controllare l'integrità di un file quando sia un MD5 che SHA1 esistono è improbabile che consenta una collisione. quindi se entrambi questi semplici controlli convalidano lo stesso file è abbastanza buono. A malapena vedo che le persone ne verificano anche solo uno nella maggior parte dei casi.