Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

NVIDIA Blackwell B200: due chip in uno per rivoluzionare l'intelligenza artificiale
NVIDIA Blackwell B200: due chip in uno per rivoluzionare l'intelligenza artificiale
Due GPU (die) su un unico package per un totale di 208 miliardi di transistor: la nuova GPU Blackwell di NVIDIA nasce per accelerare l'innovazione nel campo dell'intelligenza artificiale come mai prima d'ora. La nuova proposta è accompagnata da 192 GB di memoria HBM3E per una bandwidth di 8 TB/s. A comporre la nuova offerta di NVIDIA troviamo tre soluzioni: B100, B200 e GB200.
HP Envy Move, un PC All-In-One con la batteria che si può spostare facilmente
HP Envy Move, un PC All-In-One con la batteria che si può spostare facilmente
HP Envy Move non è un PC all-in-one come tutti gli altri: si può spostare facilmente e usare lontano dalla presa di corrente. Lo schermo touch consente di usarlo anche come un grande tablet e può diventare un display aggiuntivo. Il tutto condito da un'attenzione all'ambiente grazie all'uso di materiali riciclati.
MSI MPG 321URX QD-OLED: un monitor completo per i giocatori
MSI MPG 321URX QD-OLED: un monitor completo per i giocatori
MSI MPG 321URX QD-OLED è un monitor completo, con diagonale da 32 pollici, risoluzione UHD, porte HDMI 2.1, frequenza di aggiornamento di 240 Hz e con un pannello OLED che offre diverse caratteristiche interessanti per il pubblico dei giocatori
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: 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.
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: 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?
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: 3077
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: 3358
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: 6500
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: 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
jepessen è offline   Rispondi citando il messaggio o parte di esso
Old 24-02-2017, 19:24   #7
kreijack
Member
 
Iscritto dal: May 2011
Messaggi: 103
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: 2314
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: 253
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: 2314
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
Member
 
Iscritto dal: May 2011
Messaggi: 103
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


NVIDIA Blackwell B200: due chip in uno per rivoluzionare l'intelligenza artificiale NVIDIA Blackwell B200: due chip in uno per rivol...
HP Envy Move, un PC All-In-One con la batteria che si può spostare facilmente HP Envy Move, un PC All-In-One con la batteria c...
MSI MPG 321URX QD-OLED: un monitor completo per i giocatori MSI MPG 321URX QD-OLED: un monitor completo per ...
realme 12 Pro+ 5G: un potente mid-range con teleobiettivo sotto i 400 euro. La recensione realme 12 Pro+ 5G: un potente mid-range con tele...
Fujifilm Simulazione Pellicola – Guida all'uso Fujifilm Simulazione Pellicola – Guida all'uso
Offerte Ring Intercom di Amazon: il cito...
ho.mobile passa con Vodafone a Swisscom:...
Dell amplia la collaborazione con NVIDIA...
Elon Musk parla nuovamente delle future ...
Comedy Wildlife Photography Awards: Niko...
realme: il 2024 è l'anno della co...
Salesforce: è iniziata la migrazi...
Sony Xperia 1 VI: addio al display 4K e ...
Il proprietario di Epic Games insult&ogr...
iliad aggiunge il roaming gratuito negli...
Amazon svende alcuni NAS decisamente int...
Hertz cambia rotta: il CEO dell'azienda ...
Microsoft promette: 'Copilot sarà...
ASUS annuncia la disponibilità in...
HPE GreenLake for File Storage si aggior...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
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:10.


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