Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella nostra video anteprima!
Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella nostra video anteprima!
Siamo riusciti ad andare al quartier generale di Milano dove Samsung ci ha permesso di mettere le mani su tutte e tre le versioni dei nuovi smartphone Galaxy S21, S21+ e S21 Ultra. Tre diverse versioni proprio come tre erano gli smartphone lo scorso anno con la serie Galaxy S20. Ecco come sono fatti.
ASUS ZenBook Duo UX482: due schermi e tanta autonomia
ASUS ZenBook Duo UX482: due schermi e tanta autonomia
La nuova gamma di notebook ASUS per il 2021 vede il ritorno di modelli con due schermi, capaci di offrire un livello di produttività ancora più elevato dello standard. ZenBook Duo UX482 abbina uno schermo da 14 pollici Full HD al nuovo ScreenPad +, tutto su piattaforma Intel EVO con processore Core i7 Tiger Lake. Tanta potenza, dimensioni contenute e autonomia con batteria da vendere
Sony FE 35mm F1.4 GMaster, grande risoluzione e sfocato eccellente. La recensione
Sony FE 35mm F1.4 GMaster, grande risoluzione e sfocato eccellente. La recensione
Sony introduce per le sue mirrorless full frame un 35mm della famiglia GMaster, che si distingue per l'elevatissimo potere risolvente e l'eccellente resa dello sfocato.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 24-02-2017, 14:31   #1
Redazione di Hardware Upg
www.hwupgrade.it
 
Iscritto dal: Jul 2001
Messaggi: 75179
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.
Redazione di Hardware Upg è offline   Rispondi citando il messaggio o parte di esso
Old 24-02-2017, 15:15   #2
cignox1
Senior Member
 
Iscritto dal: May 2008
Messaggi: 1193
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?
cignox1 è offline   Rispondi citando il messaggio o parte di esso
Old 24-02-2017, 15:32   #3
banaz
Senior Member
 
Iscritto dal: May 2006
Messaggi: 3033
Quote:
Originariamente inviato da cignox1 Guarda i messaggi
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...
banaz è online   Rispondi citando il messaggio o parte di esso
Old 24-02-2017, 15:41   #4
djfix13
Senior Member
 
L'Avatar di djfix13
 
Iscritto dal: Oct 2009
Messaggi: 3109
da quello che so io 2 doc identici non danno lo stesso SHA1
djfix13 è offline   Rispondi citando il messaggio o parte di esso
Old 24-02-2017, 16:20   #5
coschizza
Senior Member
 
Iscritto dal: May 2004
Messaggi: 5219
Quote:
Originariamente inviato da djfix13 Guarda i messaggi
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.
coschizza è offline   Rispondi citando il messaggio o parte di esso
Old 24-02-2017, 16:36   #6
jepessen
Senior Member
 
L'Avatar di jepessen
 
Iscritto dal: Jul 2007
Città: Sicilia
Messaggi: 2707
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
jepessen è online   Rispondi citando il messaggio o parte di esso
Old 24-02-2017, 19:24   #7
kreijack
Junior Member
 
Iscritto dal: May 2011
Messaggi: 28
Quote:
Originariamente inviato da cignox1 Guarda i messaggi
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?
Quote:
Originariamente inviato da cignox1 Guarda i messaggi
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/200...ollisions.html
kreijack è offline   Rispondi citando il messaggio o parte di esso
Old 25-02-2017, 01:34   #8
rockroll
Senior Member
 
Iscritto dal: Feb 2007
Messaggi: 2086
Quote:
Originariamente inviato da cignox1 Guarda i messaggi
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!

Ultima modifica di rockroll : 25-02-2017 alle 01:36.
rockroll è offline   Rispondi citando il messaggio o parte di esso
Old 25-02-2017, 01:47   #9
melo86
Member
 
Iscritto dal: Mar 2010
Messaggi: 249
Quote:
Originariamente inviato da kreijack Guarda i messaggi
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).

Quote:
Originariamente inviato da kreijack Guarda i messaggi
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
melo86 è offline   Rispondi citando il messaggio o parte di esso
Old 25-02-2017, 02:30   #10
rockroll
Senior Member
 
Iscritto dal: Feb 2007
Messaggi: 2086
Quote:
Originariamente inviato da kreijack Guarda i messaggi
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/200...ollisions.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..

Ultima modifica di rockroll : 25-02-2017 alle 03:11.
rockroll è offline   Rispondi citando il messaggio o parte di esso
Old 25-02-2017, 13:53   #11
kaidan
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.
kaidan è offline   Rispondi citando il messaggio o parte di esso
Old 26-02-2017, 10:13   #12
kreijack
Junior Member
 
Iscritto dal: May 2011
Messaggi: 28
Quote:
Originariamente inviato da rockroll Guarda i messaggi
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/+LinusTorval...ts/7tp2gYWQugL
kreijack è offline   Rispondi citando il messaggio o parte di esso
Old 02-03-2017, 19:29   #13
kaidan
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.
kaidan è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella nostra video anteprima! Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella...
ASUS ZenBook Duo UX482: due schermi e tanta autonomia ASUS ZenBook Duo UX482: due schermi e tanta auto...
Sony FE 35mm F1.4 GMaster, grande risoluzione e sfocato eccellente. La recensione Sony FE 35mm F1.4 GMaster, grande risoluzione e ...
Motorola moto g 5G: vincente per l’autonomia incredibile! La recensione Motorola moto g 5G: vincente per l’autonomia inc...
Elgato 4K60 Pro: come registrare gameplay di qualità su PS5 e Xbox Series X Elgato 4K60 Pro: come registrare gameplay di qua...
Patriot, schede microSDHC/XC serie EP: e...
Grandi offerte Amazon oggi: Xiaomi Mi Tr...
Erik Buell, in serbo un'altra due ruote ...
Virgin Orbit riesce a lanciare un razzo ...
Sapphire, una RX 5700 XT fanless per rac...
Il test di NASA SLS non va come previsto...
Apple investe nei progetti degli imprend...
Tesla, arriva l'inverter per impianti fo...
Enel X, colonnine di ricarica ultra rapi...
Aorus Gen4 7000s, i nuovi SSD PCI Expres...
La 'talpa' fallisce: la NASA rinuncia a ...
2020, uno degli anni più caldi mai regis...
Samsung Galaxy Fit2, è un'ottima ...
Nasce Stellantis, da oggi effettiva la f...
Corsair 5000, ancora più spazio p...
Dropbox
BurnAware Premium
BurnAware Free
K-Lite Codec Pack Update
K-Lite Mega Codec Pack
K-Lite Codec Pack Full
IObit Uninstaller
IObit Smart Defrag
Opera Portable
3DMark
Opera 73
Prime95
CCleaner Portable
CCleaner Standard
Advanced SystemCare
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 09:29.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Served by www1v
1