Quale algoritmo di hashing dovrei usare per un checksum di file sicuro?

1

Per il mio lavoro dovrò fornire al mio cliente un file specifico che sarà il risultato del lavoro che ho svolto per loro.

Per proteggere l'integrità del lavoro che ho svolto e per garantire che non sia mai stato modificato, intendo aggiungere un checksum alla mia documentazione che verrà fornita con il file.

Dato che MD5 e SHA-1 non sono sicuri da molto tempo, mi chiedevo se li stessimo ancora usando per questo scopo o se ci fosse un algoritmo migliore che potrebbe fare lo stesso lavoro ma più sicuro.

Sto cercando la soluzione più affidabile. Sono consapevole che una prova al 100% non sarà mai possibile, ma mi chiedevo se MD5 fosse ancora valutato "buono" per questo scopo o se ci sono strumenti veramente nuovi e più sicuri.

    
posta gouaille 28.11.2018 - 17:01
fonte

2 risposte

1

Scelta dell'algoritmo di hash

Usa SHA-256 o SHA-512: uno dei due membri "principali" di SHA-2 famiglia. SHA-2 è il successore di SHA-1 ed è considerato sicuro. È l'hash da scegliere, a meno che tu non abbia una buona ragione per scegliere diversamente. Nel tuo caso la scelta tra SHA-256 e SHA-512 è indifferente. C'è un SHA-3 ma non è ancora ampiamente supportato e non è più sicuro (o meno sicuro) di SHA-2, è solo un design diverso.

Non usare MD5 o SHA-1. Non sono ovviamente inadatti al tuo scenario, ma potrebbero essere sfruttati con un po 'di lavoro extra. Inoltre, il fatto che questi algoritmi siano già parzialmente danneggiati li rende più a rischio di essere più frammentati nel tempo.

Più precisamente, per entrambi questi hash, è possibile trovare collisioni: è possibile trovare due documenti D1 e D2 tali che MD5 (D1) = MD5 (D2) (o SHA-1 (D1) = SHA -1 (D2)), e tale che D1 e D2 terminano ciascuna con un piccolo bit che deve essere calcolato e opzionalmente un suffisso scelto comune. Il bit che deve essere calcolato apparirà come una spazzatura, ma può essere nascosto in un commento, in un'immagine spostata fuori pagina, ecc. Produrre tali collisioni è banale su un PC per MD5 ed è fattibile ma costoso per SHA- 1 (a meno che non lo si desideri per due file PDF, nel qual caso i ricercatori hanno già speso i soldi per il calcolo per trovarne uno e averli pubblicati ).

Nel tuo scenario, per lo più non ti preoccupi delle collisioni, perché produrrai D1. Non hai intenzione di creare questo pezzo nel mezzo. Tuttavia, c'è il rischio che qualcuno possa ingannarti a iniettare questo bit, ad esempio fornendo un'immagine da includere nel documento. Sarebbe piuttosto complicato ottenere una collisione in questo modo, ma è fattibile in linea di principio.

Poiché esiste un rischio nell'utilizzo di MD5 e un vantaggio pari a zero rispetto all'utilizzo di SHA-256, utilizzare SHA-256.

Che cosa fare con un hash

Con un hash crittografico non interrotto come SHA-256, quello che sai è che se due file hanno lo stesso hash, allora sono identici. Viceversa, questo significa che se due file hanno hash diversi, allora sono diversi. Ciò significa che se si mantiene una copia attendibile dell'hash (ad esempio lo si stampa e lo si archivia o lo si autentica), si può dire in seguito "sì, questo file che si sta mostrando è lo stesso file" o " no, questo file che mi stai mostrando è diverso ".

Conoscere l'hash del file non dimostra che l'hai scritto. Non esiste un modo crittografico per dimostrare la paternità. Il meglio che puoi fare è provare che avevi il file prima di chiunque altro possa provarlo. Puoi farlo senza rivelare il file comunicando l'hash a una terza parte che tutti si fida per ricordare correttamente la data in cui hai mostrato loro l'hash; questa terza parte potrebbe essere un notaio pubblico o la Wayback Machine se si inserisce l'hash in una pagina Web che indicizza. (Se pubblichi l'hash, in teoria qualcuno potrebbe capire il file da esso, ma non c'è modo migliore di farlo se non provare tutti i file plausibili finché non trovano quello giusto. Se sei preoccupato di questo, usa una firma del file invece di un hash e autentica la firma e la chiave pubblica ma tieni la chiave privata per te.)

Esempio di qualcosa per cui un hash va bene: il tuo cliente vuole supporto, ma sei solo pronto a supportare il tuo prodotto originale e non un prodotto modificato. Quindi li fai calcolare l'hash di ciò che vogliono che tu supporti. Se il valore hash non è quello che hai fornito, ti rifiuti di fornire supporto. Si noti che è necessario fidarsi del cliente per calcolare l'hash del prodotto e non calcolare l'hash di una copia dell'originale o leggerlo dal buono di consegna.

Esempio di qualcosa a cui un hash non va bene: qualcun altro sostiene di essere l'autore del documento. Dici "no, guarda, conosco il suo hash, sono 1234 ...". Ciò non aiuta: chiunque può calcolare l'hash.

Esempio di qualcosa a cui un hash va bene se usato in modo appropriato: qualcun altro afferma di aver appena scritto il documento. Dici "no, guarda, ho autenticato l'hash 6 l'anno scorso, quindi non puoi averlo scritto la settimana scorsa".

Esempio di qualcosa per cui un hash non va bene: qualcuno modifica leggermente il documento. Avrà quindi un hash diverso. Tutto quello che puoi dire è che il documento è ora diverso, ma questo non trasmette alcuna informazione su quanto siano diversi. L'hash di un documento completamente diverso è tanto diverso quanto l'hash di una versione con correzione di errori di battitura o una versione codificata in modo diverso.

    
risposta data 28.11.2018 - 22:07
fonte
1

Per garantire che il prodotto di lavoro rimanga invariato, anche MD5 è ragionevole.

La capacità di un attaccante di progettare una collisione è pericolosa quando, ad esempio, può generare un eseguibile. Quel eseguibile può impiegare 500 Kb per fare qualcosa di male e spendere altri 50.000 Kb per estrarre i bit inutilizzati solo per ottenere la collisione. Va bene se quei bit sono inutilizzati; si vede semplicemente un eseguibile con l'hash giusto e si è ingannati.

Progettare una collisione che corrisponda sia all'hash MD5 sia alla documentazione credibilmente errata non è fattibile. È più probabile che tu finisca con la documentazione che legge " prendi la spina e inseriscila nel $ # WG% ga 940 [2aj2'rj09 [3j59g; qa1j; socke t" - chiunque sembri in quel momento capirai che la documentazione è stata manomessa. Anche una serie in fasi di scimmie shakespeariane non può girare una collisione MD5 che sembra ancora una documentazione.

Guardando più da vicino, vedo che non è la documentazione che stai proteggendo; includeresti l'hash del "file specifico che sarà il risultato del lavoro che faccio per loro". Ancora una volta, non sapendo che quel file è - eseguibile? codice sorgente? - è computazionalmente irrealizzabile che possano modificarlo in modo tale da rivendicare credibilmente che è ciò che gli hai dato, e allo stesso tempo progettare una collisione di hash.

Vedi anche questa risposta su Crypto.SE che riassume:

MD5 is currently considered too weak to work as a cryptographic hash. However, for all traditional (i.e. non-cryptographic) hash uses MD5 is often perfectly fine.

Non stai guardando un uso crittografico di un hash, quindi MD5 va bene per te. Eviterà la sostituzione di sostituzioni modificate o credibilmente contraffatte del prodotto di lavoro che le hai fornite.

    
risposta data 28.11.2018 - 17:25
fonte

Leggi altre domande sui tag