|
|
|
|
Strumenti |
24-02-2017, 14:31 | #1 |
www.hwupgrade.it
Iscritto dal: Jul 2001
Messaggi: 75175
|
Link alla notizia: http://www.hwupgrade.it/news/sicurez...ha1_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. |
24-02-2017, 15:15 | #2 |
Senior Member
Iscritto dal: May 2008
Messaggi: 1837
|
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? |
24-02-2017, 15:32 | #3 | |
Senior Member
Iscritto dal: May 2006
Messaggi: 3077
|
Quote:
https://shattered.it/static/shattered-2.pdf due click ci son voluti eh... |
|
24-02-2017, 15:41 | #4 |
Senior Member
Iscritto dal: Oct 2009
Messaggi: 3358
|
da quello che so io 2 doc identici non danno lo stesso SHA1
|
24-02-2017, 16:20 | #5 | |
Senior Member
Iscritto dal: May 2004
Messaggi: 6500
|
Quote:
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. |
|
24-02-2017, 16:36 | #6 |
Senior Member
Iscritto dal: Jul 2007
Città: Sicilia
Messaggi: 5412
|
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.
__________________
Non abbiamo ereditato il mondo dai nostri padri L'abbiamo preso in prestito dai nostri figli |
24-02-2017, 19:24 | #7 | ||
Member
Iscritto dal: May 2011
Messaggi: 103
|
Quote:
Quote:
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/200...ollisions.html |
||
25-02-2017, 01:34 | #8 | |
Senior Member
Iscritto dal: Feb 2007
Messaggi: 2314
|
Quote:
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! Ultima modifica di rockroll : 25-02-2017 alle 01:36. |
|
25-02-2017, 01:47 | #9 | |
Member
Iscritto dal: Mar 2010
Messaggi: 253
|
Quote:
l'articolo dice esattamente che è possibile creare blocchi arbitrari con la stessa checksum, non ho capito cosa intendi |
|
25-02-2017, 02:30 | #10 | |
Senior Member
Iscritto dal: Feb 2007
Messaggi: 2314
|
Quote:
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.. Ultima modifica di rockroll : 25-02-2017 alle 03:11. |
|
25-02-2017, 13:53 | #11 |
Member
Iscritto dal: Sep 2007
Messaggi: 52
|
Birthday attack
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. |
26-02-2017, 10:13 | #12 | |
Member
Iscritto dal: May 2011
Messaggi: 103
|
Quote:
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/+LinusTorval...ts/7tp2gYWQugL |
|
02-03-2017, 19:29 | #13 |
Member
Iscritto dal: Sep 2007
Messaggi: 52
|
Collisioni datate
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. |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 09:10.