Link alla notizia: http://www.hwupgrade.it/news/sicurezza-software/google-da-la-mazzata-finale-all-algoritmo-crittografico-sha1_67370.html

Google ha finalmente crackato l'agoritmo SHA1, utilizzato come funzione di hashing per verificare l'attendibilità di un file o identificare eventuali modifiche forzate

Click sul link per visualizzare la notizia.

Qualcuno ha dato una occhiata ai due file? Immagino che al massimo uno dei due "abbia senso", mentre l'altro sia un accrocchio di byte cercati proprio perché fornissero la stessa hash.

Corretto?

Qualcuno ha dato una occhiata ai due file? Immagino che al massimo uno dei due "abbia senso", mentre l'altro sia un accrocchio di byte cercati proprio perché fornissero la stessa hash.

Corretto?

https://shattered.it/static/shattered-1.pdf

https://shattered.it/static/shattered-2.pdf

due click ci son voluti eh...

da quello che so io 2 doc identici non danno lo stesso SHA1

da quello che so io 2 doc identici non danno lo stesso SHA1

io ci ho messo invece 4 click per fare questo

38762cf7f55934b34d179ae6a4c80cadccbb7f0a *shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a *shattered-2.pdf

e poi se 2 doc identici non danno lo stesso SHA1 allora a che servirebbe lo SHA, a nulla.

Un conto e' essere uguali dal punto di vista del contenuto, un punto e' essere uguali dal punto di vista binario, o quantomeno nel calcolo dell'hash.

Il concetto e' che puoi avere un file qualunque che, con opportuno codice aggiunto, presenta lo stesso hash di un altro.

L'esempio dei PDF e' fatto perche' il formato di file permette di aggiungere informazioni in un header che non inficia il documento... Teoricamente potrebbe essere fatta la stessa cosa per I tag dei file MP3.. potresti avere un file con un hash e poi un altro diverso dove aggiungi dei byte in un tag, tipo quello della copertina, per fare in modo che alla fine il calcolo dell'hash sia lo stesso.

Qualcuno ha dato una occhiata ai due file? Immagino che al massimo uno dei due "abbia senso", mentre l'altro sia un accrocchio di byte cercati proprio perché fornissero la stessa hash.

Corretto?

Qualcuno ha dato una occhiata ai due file? Immagino che al massimo uno dei due "abbia senso", mentre l'altro sia un accrocchio di byte cercati proprio perché fornissero la stessa hash.

Corretto?

Credo che la tecnica sia un po' più raffinata.

Queste checksum vengono calcolate a blocchi. Il che significa che se trovo due blocchi diversi con la stessa checksum, concatenandoli ad un file ottengo due file *diversi* che continuano ad avere la *stessa checksum*.

Infatti confrontando i due file, solo 62 byte sono differenti (ed hanno la stessa lunghezza).

A questo punto se il tipo di file può contenere del codice eseguibile, questo codice può verificare quale file è verificando se è presente (o meno) uno dei due blocchi ed eseguire delle azioni che sono diverse a seconda del blocco.

La prima volta che ho sentito parlare di questo problema, era relativo ad un documento postscript ed ad una collisione md5 ; visto che gli esempi sono dei PDF (che credo possano a loro volta contenere del codice javascript), mi viene da pensare che la tecnica usata sia simile

Questo spiega perchè non ha senso firmare digitalmente documenti che possano contenere codice (vedi file word o similia).

Riassumendo, è vero quello che dici tu (non è possibile creare due blocchi arbitrari con la stessa checksum); ma, per alcuni file, potrebbero apparire simili.


http://www.educatedguesswork.org/2005/06/md5_collisions.html

Qualcuno ha dato una occhiata ai due file? Immagino che al massimo uno dei due "abbia senso", mentre l'altro sia un accrocchio di byte cercati proprio perché fornissero la stessa hash.

Corretto?

Penso anch'io.

Ciò non toglie che da un punto di vista teorico anche files che non hanno alcun senso devono essere sempre distinguibili con hash univoco (pensa a files binari magari criptati); e questo non sarà matematicamente mai garantito (per improbabile che sia in pratica) se l'hash contiene meno bit del file!

Questo spiega perchè non ha senso firmare digitalmente documenti che possano contenere codice (vedi file word o similia).


le firme di questi file ne garantiscono l'autenticità, basti pensare ai certificati rilasciati per i vari siti web che devono essere firmati da un garante fidato (e sono file di testo, nondegli eseguibili).


Riassumendo, è vero quello che dici tu (non è possibile creare due blocchi arbitrari con la stessa checksum); ma, per alcuni file, potrebbero apparire simili.


l'articolo dice esattamente che è possibile creare blocchi arbitrari con la stessa checksum, non ho capito cosa intendi

Credo che la tecnica sia un po' più raffinata.

Queste checksum vengono calcolate a blocchi. Il che significa che se trovo due blocchi diversi con la stessa checksum, concatenandoli ad un file ottengo due file *diversi* che continuano ad avere la *stessa checksum*.

Infatti confrontando i due file, solo 62 byte sono differenti (ed hanno la stessa lunghezza).

A questo punto se il tipo di file può contenere del codice eseguibile, questo codice può verificare quale file è verificando se è presente (o meno) uno dei due blocchi ed eseguire delle azioni che sono diverse a seconda del blocco.

La prima volta che ho sentito parlare di questo problema, era relativo ad un documento postscript ed ad una collisione md5 ; visto che gli esempi sono dei PDF (che credo possano a loro volta contenere del codice javascript), mi viene da pensare che la tecnica usata sia simile

Questo spiega perchè non ha senso firmare digitalmente documenti che possano contenere codice (vedi file word o similia).

Riassumendo, è vero quello che dici tu (non è possibile creare due blocchi arbitrari con la stessa checksum); ma, per alcuni file, potrebbero apparire simili.


http://www.educatedguesswork.org/2005/06/md5_collisions.html

Parlo con te che mi sembri il più ferrato sull'argomento; io, nella mia dabbenaggine idealistica, ho sempre snobbato questo campo, per cui sono ignorante, ma questo non significa privo di logica.
Ripeto anche a te quello appena detto rispondendo a cignox1: da un punto di vista teorico anche files che non hanno alcun senso devono essere sempre distinguibili con hash univoco (pensa a files binari magari criptati); e questo non sarà matematicamente mai garantito (per improbabile che sia in pratica) se l'hash contiene meno bit del file!

Un hash, per lungo che sia, sarà nella realtà composto di un numero di bit nh di parecchi ordini di grandezza inferiore al numero di bit nf del file da esaminare. Come si può pretendere che un numero di configurazioni possibili 2^nh possa individuare univocamente tutte le 2^nf configurazioni possibili di un file composto di nf bit, dove nh << nf ???
Pur ammettendo una distribuzione ottimale delle corrispondenze generate dal calcolo dell'hash, ci sarà sempre inevitabilmente almeno un numero 2^(nf-nh) di casi in cui si presenta almeno un doppione, cioè in cui lo stesso hash corrisponde ad almeno due files diversi, e chiedo scusa se quel numero di casi è troppo piccolo...

L'unica cosa di cui siamo sicuri è che a files uguali corrispondono hash uguali.

Che poi all'atto pratico le cose possano andar decisamente meglio, questo non inficia quanto ho esposto.

Perchè decisamente neglio? Perchè all'atto pratico si vuol evitare che qualcuno cambi qualche valore (in sostanza pochi bit) su un documento che comunque dovrebbe mantenere una conformazione che corrisponda ad un documento possibile e riconoscibile come tale. Da quanto su esposto è sicuramente possibile, con le attuali potenze di calcolo, creare in tempi ragionevoli un file di ugual hash, ma che questo possa corrispondere ad un documento valido come caratteristiche è molto più difficile, è potrebbe essere impossibile, dipende da come è strutturato l'algoritmo, che potrebbe essere in grado, riconoscendo la struttura nota del documento, di orientare il calcolo dell'hash in maniera da differenziare sicuramente l'hash per pochi bit di differenza in zone ristrette del file documento.
Certo se il documento contiene delle zone cieche nelle quali posso mettere manciate di bit che poi non vengono evidenziati e non vanno ad inficiarne la conformazione e le caratteristiche di utilizzo (Vedi PDF contenente Java o Tag mp3), se voglio hackerare il contenuto ho a disposizione la zona cieca per riportare l'hash al valore voluto, per lungo che sia se vado a brute force, basta che la zone cieca contenga pochi bit più dell'hash, a meno che l'algoritmo sia a conoscenza della zona cieca e la escluda dal calcolo hash..

Si tratta di un birthday attack. Si modifica leggermente un file di partenza e ne si calcola l'hash. E' un attacco di forza bruta allo scopo di trovare collisioni tra due input molto simili, ma differenti. Il vantaggio è che sono necessario 2^n/2 tentativi invece di 2^n tentativi per trovare con probabilità maggiore del 0,5 una collisione.
Per adesso basta usare algoritmi con digest superiore a 160bit, simile a come avvenuto quando è stato crackato il DES che poi fu sostituito da 3DES.

Certo se il documento contiene delle zone cieche nelle quali posso mettere manciate di bit che poi non vengono evidenziati e non vanno ad inficiarne la conformazione e le caratteristiche di utilizzo (Vedi PDF contenente Java o Tag mp3), se voglio hackerare il contenuto ho a disposizione la zona cieca per riportare l'hash al valore voluto, per lungo che sia se vado a brute force, basta che la zone cieca contenga pochi bit più dell'hash, a meno che l'algoritmo sia a conoscenza della zona cieca e la escluda dal calcolo hash..

Google ha trovato una "collisione", ovvero due blocchi di dati che hanno la stessa checksum. Ma non sono due blocchi arbitrari. Questo significa che non si è ancora in grado di alterare un file arbitrario in maniera arbitraria e mantenere la stessa checksum. Questo è importante.

Però file con "zone ceche", come le chiami tu, sono più sensibili a questo tipo di attacchi. Per cui è possibile generare due PDF che hanno la stessa checksum.

Comunque il problema è noto da tempo: le tecniche e le potenze di calcolo si evolvono nel tempo, e sono necessari nuovi algoritmi di hash. Prima era sconsigliato l'MD5, ora sarà lo SHA1... e così via. Basta saperlo e tenersi aggiornati.

Qui c'è un post di Torvarlds, che spiega che pur essendo sha1 vulnerabile alle collisioni, non è detto che sia un problema per tutti i tool che lo usano, e fa l'esempio di GIT.

https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

Ho letto due testi diversi, entrambi del 2005 (nell'ultima versione quindi probabilmente è anche una notizia più vecchia) e già avevano trovato delle collisioni per lo SHA-1 più di dieci anni fa.
Anche se ora sembrano voler formalizzare la cosa, era un problema noto da tempo.