3 risposte a “Google rompe lo SHA-1”

1. 

   giomba

   27 Febbraio 2017

   Come scritto nell’articolo, per definizione, l’hash prende in ingresso dei dati di tipologia e lunghezza arbitraria, e poi fornisce in uscita un codice di dimensione fissa basato sul contenuto dei dati in ingresso. Per una lunghezza di n bit del codice di uscita, si hanno 2^n possibili hash diversi. È evidente che io potrò sempre produrre più di 2^n dati diversi in ingresso, perché questi hanno lunghezza arbitraria. Mi basta, per esempio, generare tutti i dati di lunghezza 2^(n+1) per trovare sicuramente una collisione, quindi, non c’è proprio da stupirsi che sha1 (e prima md5, e in futuro anche sha256) possano essere non sicuri. Il fatto che un algoritmo di hash garantisca che due diversi dati di ingresso diano sempre due diversi hash, è semplicemente impossibile per definizione: al limite, si possono rendere le collisioni difficili da trovare, ma si sa fin dal principio che queste ci sono. Quindi, animo in pace, fin’ora abbiamo sempre usato md5 e sha1, e tra qualche anno, quando avremo sufficiente capacità di calcolo, anche sha256 farà la stessa fine, e ce ne sarà uno nuovo, che reggerà il compromesso finché i computer non saranno diventati abbastanza potenti da rendere obsoleto pure quello, e così via.

2. 

   Tullio Andreatta

   27 Febbraio 2017

   In realtà il testo dell’articolo è sbagliato, quando dice che un algoritmo di hash debba garantire che “Non esiste alcun altro file che generi la stessa stringa di caratteri”, proprio perchè matematicamente non avrebbe senso dire che possa esistere una funzione che trasforma ogni numero di 1000 cifre in uno di 32 cifre senza produrre duplicati (dopo che ho esaurito i numeri di 32 cifre, dovrò ripetermi).
   In realtà l’hash dovrebbe garantire invece che non sia FACILE, dato un certo file, creare un altro file con il medesimo hash.
   Google ha “solo” dimostrato che SHA-1 consente di trovare un file con lo stesso hash di un file dato con un algoritmo 100.000 volte più semplice di quelli ipotizzati finora.

3. 

   matteocappadonna

   27 Febbraio 2017

   Premettendo che non entro nelle ‘definizioni’ matematiche semplicemente perché -probabilmente- non sarei in grado di discuterne appieno, il punto di vista con cui ho affrontato la stesura di questo articolo è stato prettamente pratico.

   E’ vero che matematicamente è impossibile esprimere in maniera univoca con un numero limitato di caratteri l’intero spettro dei possibili file (soprattutto se consideriamo l’infinito come “campione” di input), è anche vero che, praticamente parlando, quello che ci si aspetta da un algoritmo di hashing è che due file producano sempre due risultati diversi.

   Quello che determina, IMHO, l’usabilità o meno di un metodo piuttosto che un altro è quindi il tempo necessario a rompere lo stesso; se è fattibile in un periodo di tempo “umano”, allora è da valutare un cambio.

   Google, come dici tu, ha fatto questo; non ha dimostrato che con lo SHA-1 è possibile avere collisioni, questo si sapeva già, ha solo dimostrato che è possibile averle (o generarle, come nel loro caso) in un tempo umanamente accettabile, cosa che rende automaticamente necessario valutare, dove possibile, il passaggio allo SHA-256 (o altri tipi di hash).