Newsgroup: it.comp.os.linux.software
Titolo: sha1 o md5 ?

sha1 o md5
poi un altra domanda
quante probabilita ci sono di avere piu di un file con lo stesso md5/sha1 e
la stessa dimensione ?
ovviamente diversi


ma si basa in qualche modo sulla dimensione l'md5? credevo di no...

 ha scritto nel messaggio
news:20021227025612.3...@inwind.it...

no, non si basa sulla dimensione ma un file con la stessa dimensione di un
altro puo avere lo stesso md5 ?
o uso md5 e sha1 che credo sia impossibile che 2 file diversi abbiano sia
md5 che sha1
identici credo che usero questa soluzione (sha1 e md5 almeno sono quasi
certamente sicuro
che non esistono 2 file "identici")

 che non esistono 2 file "identici")
io sarei molto sicuro anche solo con md5 ad esempio, non mi risulta che
qualcuno al mondo abbia ottenuto 2 checksum identici finora... o sbaglio alla
grande?

 ha scritto nel messaggio
news:20021227163927.7...@inwind.it...


Ho letto questo thread qualche giorno fa...
ho pensato: le prob sono bassissime!
ebbene...
oggi ho fatto un prog in perl e in ul albero di direcrory con circa 200
files ne ho trovati due con lo stesso hash MD5.
O la probabilità è bassa, o la sfiga ci vede benissimo!!!
MAx

ma cacchio... possibile? ma a che serve allora sto md5 se la probabilita e cosi
alta?

Sei sicuro?? Sono files sicuramente diversi?? Se non ci sono
segreti particolari potresti pubblicarli!! E' molto interesante.
(HEMM!! non e' che uno e' un soft-link all' altro?? :))))
Comunque riassumendo:
MD5 64 cicli di applicazioni di funzioni in combinazione non lineare
per produrre 128 bits di fingerprint.
SHA1 80 cicli per produrre 160 bits di fingerprint.
Quindi inevitabilmente esplorando tutti i possibibili messaggi binari
scrivibili con 129 bits per MD5 o 161 bits per SHA1 INEVITABILMENTE
si avranno messaggi diversi che collidono almeno 2 volte allo stesso
fingerprint. Dato che non credo che nessuno abbia mai esplorato
tutto, non e' detto che non esistano valori impossibili da generare,
o addirittura valori unici, ma se cosi' fosse, altri messaggi
colliderebbero di piu'.
Naturalmente con messaggi con un senso compiuto (fossero anche binari
o compressi) cio' e' MOLTO IMPROBABILE, piu' improbabile con SHA1
che con MD5, forte com' e' dei suoi 160 bits. MD5 comunque non e'
da buttare secondo me e rimarra' sicuro per parecchio.
Ciao.
Roberto.


 (HEMM!! non e' che uno e' un soft-link all' altro?? :))))
Guarda, per me la probabilità di trovare due files uguali era prossima allo
zero, quindi seguii il thread senza valotarlo troppo.
Poi mi sono sviluppato dei programmmini in perl che, con Digest::MD5
potessero confrontare le modifiche fatte a dei files rispetto agli
originali.
Con immensa sorpresa, mi sono accorto che due di questi, in dir. separate e
non symlinkati, avevano lo stesso hash.
Erano due files in php, delle librerie particolari, a dire la verità che non
avrei problemi a pubblicare.
La tua richiesta, però, arriva un pò tardino, nel senso che i files li ho
già modificati.
Dovrei andare a ricercare il backup del giorno prima, ammesso e non concesso
che contenesse le versioni incriminate e non quelle pre-modifiche.
I files avevano lunghezza uguale, ma contenuti (leggermente differenti).
In ogni modo, ci sono rimasto malissimo!
Max

 
Non è che c'e' un tranello nel modo in cui calcoli l'MD5?
Non è improbabile che molti algoritmi che ci sono in giro in realtà 
applichino l'hash solo ad una parte del file, e non tutto. Quindi se 
erano solo "leggermente differenti" è probabile che la parte con le 
differenze sia stata ignorata...
bye!
-- 
Fabrizio "Hermooz" Ermini

> Non è che c'e' un tranello nel modo in cui calcoli l'MD5?
Controlla tu!
Può essere che abbia fatto qualche c<bip>zata!
Max
#******************************************************************
sub CalcolaMd5File {
 my ($file)=@_;
 open(FILE, $file) or die "Can't open '$file': $!";
 binmode(FILE);
 $md5 = Digest::MD5->new;
 while (<FILE>) { $md5->add($_); }
 close(FILE);
 return $md5->b64digest;
}

 già modificati.
Io, tempo fa, ho tentato di trovare una collisione tra circa 15 miliardi di
digest md5 ottenuti da file pseudo-casuali lunghi 64 bytes. Niente da fare,
nemmeno una collisione.
Questo per dire che un evento simile è talmente eccezionale che i due file
li dovevi backuppare 10 volte in 10 supporti diversi per stare tranquillo
che non andassero persi!
Poi li dovevi postare per dar modo a chiunque di verificare.
Ormai... pazienza! :-)
Cristiano

 applichino l'hash solo ad una parte del file, e non tutto.
Voglio sperare che programmi simili non esistano! :-)
Autenticare soltanto un pezzo di un file non capisco a che servirebbe.
Cristiano

 Autenticare soltanto un pezzo di un file non capisco a che servirebbe.
Dipende cosa ci devi fare. Un hash può essere utili a molti scopi: se 
vuoi solo usarlo per generare una chiave univoca relativa al file, ad 
esempio, usare un "campionamento" del file originario può essere un buon 
compromesso tra velocità di calcolo e robustezza dell'algoritmo. Per la 
verifica dell'autenticità invece hai ragionissima, è assolutamente 
indispensabile considerare TUTTO il file...


 }
L'alternativa è che sei stato decisamente sfigato ;-)
Ciao!
-- 
Fabrizio "Hermooz" Ermini

Ho collaudato il suo codice e confrontato con md5sum di linux.
Parrebbe funzionare sempre. Siccome so' come si calcola MD5
per averlo scritto in C, ho provato per file di dimensioni
caratteristiche, come files di 512 bits (dimensione di blocco
per ogni md5->add), 512 - 8, 512 + 8, 440, 448, 456, 512 + 
[440 o 448 o 456] e sempre il risultato corrisponde a quello di
md5sum di Linux. Queste prove e ho fatte ipotizzando bug sw
nel modulo perl, nel normalizzare l' ultimo input a un blocco
o 2 blocchi (a seconda dei casi) di 512 bits.
Comunque non e' escluso che il suo modulo sia buggato e quello che
ho usato io no quindi la tua ipotesi rimane pertinente. Oltretutto
sembre che la chiamata return $md5->b64digest; oltre che dare
in output l' MD5 fin li' calcolato, esegue la fase di "chiusura"
(appende un bit a 1, esegue la normalizzazione a 448 bits se
possibile, altrimenti a 512 + 448, aggiunge 64 bint in little-endian
di contatore di bits del flusso dati). Magari con files di certe
dimensioni marticolari questa operazione non avviene correttamente
e l' ultimo blocco viene escluso dal calcolo.
Comunque qui da me funzia.
L' opporunita' di poter esaminare due files diversi col lo stesso
MD5 e' da non buttare. Per esempio sapere se concatenandoli con 
uno stesso SEED danno ancora MD5 uguali.
Se ne trovate NON BUTTATELI!! SONO ORO!!
Ciao.
Roberto.


 Se ne trovate NON BUTTATELI!! SONO ORO!!
Eh.. ribeccarli mifarebbe comodo... comunque ti posso dire che al backup
precedente erao lunghi cira 3800 bytes...
ora ipnitizzo me e quelli che ci hanno messo le mani e vedo se riesco a
farci ripetere quello che abbiamo fatto...
Sapete dove posso trovare l'Hypnicic-Howto? :-)
Max....
ah... uso debian, quindi niente hypnotic-1.3.4-i386.rpm
quello l'ho trovato anche io ed è buggato...

ah... uso debian, quindi niente hypnotic-1.3.4-i386.rpm
prova ad "alienizzarlo".
-- 
Maurizio - Tannoiser - Lemmo
Founder Member of ERLUG (Emilia Romagna Linux User Group)
http://erlug.linux.it

 nemmeno una collisione.
Forse era meglio se invece di generare file casuali generavi file
diversi per esempio "sommando" 1 al file precedente (partendo dal file
con tutti 0)... in questo modo eviti sicuramente le collisioni fra i
file casuali :-)....
l'esperimento rifallo fra una decina di anni quando ci saranno
computer super veloci... troverai due digest uguali dopo il
2^128esimo file :-)  
super OT 
ma vedi se è possibile che alle 4:50 invece di dormire sto a farmi
queste seghe mentali :-)
non ho sonno... sarà per il fatto che qualche giorno fa ho avuto
ospiti proprio a quest'ora... ladri... sono entrati con noi in casa
che dormivamo (mai successo dalle nostre parti, stiamo in un piccolo
paese e la mia casa è in campagna vicina ad altre 4 case anch'esse
ripulite :-))...
da me non hanno fatto in tempo a salire al piano di sotto perchè sono
dovuti scappare... da un mio vicino sono saliti su e si sono presi il
telefonino da sopra il comodino vicino al letto (e c'era una persona
che ci dormiva)...
fine super ot 

 2^128esimo file :-)
A parte che basta un pò di culo per farlo... io ci sono riuscito per puro
caso...
Comunque, per le vare leggi matematiche, puoi trovarla dopo 2 tentativi o
dopo 2^12121271879 o non trovarla mai.
Se tiri un dado, può anche non uscirti mai 6...
Era giusto una precisazione, per "fare la punta al ca?zo"
Max

 che ci dormiva)...
Mi dispiace per l'accaduto.
Probabilmente usano spray soporiferi o similari, al risveglio non ti accorgi
di nulla.
Cristiano