Newsgroup: it.comp.lang.visual-basic
Titolo: [ot] md5 - crc32

se due file hanno identici md5 e crc32 sono sicuramente identici?
e' sufficiente uno solo dei due?
grazie, a.

 grazie, a.
Prego, Lokar 

 No :)
fantastico :)
allora a che bip servono i due?
ciao, a.

 allora a che bip servono i due?
Il crc2 viene normalmente utilizzato per validare l'integrita' di un file, 
ad esempio dopo un download.
Se dopo il trasferimento il crc2 e' uguale, si puo' presumere con una certa 
sicurezza che il file sia "integro".
md5, come sha1 e algoritmi di hash analoghi, codifica una stringa in modo 
non reversibile, per cui (per definizione) allo stesso md5 possono 
corrispondere piu' stringhe diverse. Normalmente vengono utilizzati per 
codificare le password in un db. In questo modo non viene registrata la 
password, ma solo il suo hash non reversibile. Durante l'autenticazione si 
confronta l'hash dell'input utente con quello archiviato, e poiche' 
l'algoritmo e' abbastanza "forte" la validazione fatta in questo modo e', 
nelle procedure di sicurezza "generiche", sufficientemente sicura. Avrai 
sentito parlare di rainbow tables: essendo l'md5 una codifica a 128 bit 
indipendentemente dalla stringa originale (e quindi esiste un numero finito 
di combinazioni/hash), sono state calcolate tutte le possibili "parole" 
corrispondenti ad ogni hash md5.
hth,
Lokar 

 certa sicurezza che il file sia "integro".
ma, stando al "no" di prima, deduco, non con certezza...
hmmm... stavo cercando un metodo abbastanza rapido di eliminare doppioni. al 
momento uso dupelocater, ma e' lento.
rigrazie, a.

 al momento uso dupelocater, ma e' lento.
Non conosco il programma, ma a naso se non controlli proprio TUTTO il 
contenuto, non sarai mai certo al 100% :)
Buone pulizie di pasqua,
Lokar 

 ma, stando al "no" di prima, deduco, non con certezza...
Io non ne so nulla, ma il CRC 32 in genere è impossibile che contenga 
tutte le informazioni di un file di dimensione qualunque, altrimenti 
sarebbe l'algoritmo di compressione più potente del mondo :-)
Quindi, se così stanno le cose, non può avere una relazione univoca con 
un determinato file.
Se il CRC 32 è un numero a 32 bit, allora la probabilità che due file 
diversi abbiano lo stesso CRC 32, senza conosce nulla a priori sui file, 
dovrebbe meramente essere 1 su 2^32, ossia 1 su altre 4 miliardi.
-- 
news:it-alt.comp.software.openoffice : Il newsgroup dedicato a
OpenOffice.org, la suite open source di applicazioni per ufficio.
Saluti, VITRIOL

 contenuto, non sarai mai certo al 100% :)
direi sia quello che fa lui. carica l'elenco dei file, poi li riscontra uno 
per volta su tutti gli altri. se i file sono 40k, si fa notte.
l'1/2^32 che dice vitriol sarebbe attraente, basterebbe calcolarlo per tutti 
(al momento sono file piccoli, ho provato ora e servono 12" per il crc32 e 
6" per l'md5 di 500 file), e ordinare l'array scorrendolo per trovare valori 
identici. ma ne so troppo poco per fidarmi.
grazie a tutti e due.
ciao, a.

 identici. ma ne so troppo poco per fidarmi.
Puoi pensare di usare un setaccio a maglie sempre più strette. Prima 
controlli le dimensioni, di quelli che hanno dimensione identica 
controlli il CRC, quelli che hanno anche identico CRC li controlli bit 
per bit. Immagino sia il metodo che ti può garantire la massima velocità.


 Immagino sia il metodo che ti può garantire la massima velocità.
buona idea. appena riesco, provo.
grazie e ciao, a.

 velocità.
Quoto il concetto. Però, se due file hanno la stessa dimensione,
lo stesso CRC e lo stesso MD5, e NON sono identici... via, una
sfiga così non capiterebbe neanche a me :-/
Un Paperino "almeno spero" :-(. 

 una sfiga cosě non capiterebbe neanche a me :-/
forse non sai di cosa sono capace. be' no, a pensarci bene episodi recenti 
li sai :)
ciao, a.

 recenti li sai :)
Eh, beh... lasciamo perdere, va. Basta dire che se c'č uno che
ti capisce sono io.
Bye, G. 

 se due file hanno identici md5 e crc32 sono sicuramente identici?
Ovvio che no.
Altrimenti avresti un compressore dalle potenzialità enormi.
Se con md5 e crc32, quindi al massimo qualche decina/centinaio di byte 
in tutto, tu avessi la individuazione certa e deterministica di un 
determinato file di 100GB, significa che esisterebbe una relazione 1:1, 
quindi potresti memorizzare solo cento byte e avresti lo stesso 
contenuto informativo.
Il ragionamento degli algoritmi di checksum/hashing, quali essi siano, 
è che valgono solo per la negazione: se due file hanno un qualunque 
hash diverso, essi sono SICURAMENTE DIVERSI. Ma non è detto il 
viceversa.
Volendo semplificare all'estremo: tu potresti scrivere un hashing in 
cui HASH=<primi 100 byte>
E' evidente che se HASH_1 <> HASH_2 => File_1 <> File_2
Ma se HASH_1 = HASH_2, non è detto che i byte successivi al centesimo 
siano identici in file_1 e file_2.
Ciao
Alberto
-- 
La forza di volontà è guardare negli occhi una ragazza in topless.

 contenuto informativo.
Mica tanto... Da qualche parte quei 100MB devi pigliarli e non č 
detto che la relazione univoca sia pure reversibile.
-- 
IBM: Insidious Byzantine Mentality
News 2002 [v 2.07] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 diverso, essi sono SICURAMENTE DIVERSI. Ma non è detto il viceversa.
molto chiaro, grazie.
ciao, a.

 grazie e ciao, a.
Più che controllare bit/bit, ti conviene in chunck di 'n' byte
Ciao
-- 
Gianluca Cannalire
Microsoft MVP/MCP - Visual Basic
http://www.visual-basic.it
http://community.visual-basic.it/gianluca
 

 dovrebbe meramente essere 1 su 2^32, ossia 1 su altre 4 miliardi.
Infatti per verificare l'integrità dei files usano tutti MD5 e non CRC, 
probabilmente proprio perchè essendo a 128bit è comunque più affidabile.
Il CRC è molto usato da algoritmi di compressione ma credo perchè è molto 
più veloce da calcolare e quindi non influisce sulle prestazioni 
dell'elaborazione. 

 detto che la relazione univoca sia pure reversibile.
Che la relazione, o meglio trasformazione, non sia reversibile, è 
appunto identificativo che l'identificazione non sia deterministica.
Se fosse deterministica, in qualche modo sarebbe reversibile (vedi 
esempio sotto). E se fosse reversibile, sarebbe un 'compressore'.
Ma proprio perchè non è deterministica, non è reversibile, quindi non è 
un compressore.
Se i cento byte, o quelli che sono, dell'hash, garantissero che il file 
è esattamente quello, e non diverso di neppure un bit, significherebbe 
che il contenuto informativo dell'hash sarebbe sufficiente a 
individuare DETERMINISTICAMENTE un file di 100GB. Quindi, da un punto 
di vista puramente teorico, tu potresti avere un archivio di tutti i 
file potenzialmente esistenti, e con una banale ricerca dell'hash 
idoneo, avresti il file originale. Questa è ovviamente una 
modellizzazione puramente accademica, che mi auguro ti chiarisca il 
perchè la relazione non sia reversibile.
Alberto
-- 
Charles Baudelaire: C'è un solo modo di dimenticare il tempo: 
impiegarlo.

 file potenzialmente esistenti, e con una banale ricerca dell'hash 
Non sarebbe ugualmente un compressore. Da quei 100 byte NON ESTRAI un
file senza avere l'archivio di TUTTI i files...
-- 
IBM: I'm Beyond Mistakes


 file senza avere l'archivio di TUTTI i files...
Non importa.
Anche i compressori possono avere dentro archivi, seppur parziali. 
Magari hanno una cosa del tipo "se trovi Ax100 significa cento volte il 
carattere A", ed un elenco di questo non è altro che un archivio di 
array di dati.
Cerca di capire il concetto (l'esempio era per tentare di spiegare): i 
file di 100GB esistono in N combinazioni diverse di bit (e il numero N 
è veramente molto grosso), se l'hash fosse univoco occorrerebbe che 
esso potesse rappresentare le stesse N combinazioni. Ma per 
rappresentare le stesse N combinazioni, dovrebbe possedere lo stesso 
contenuto informativo. E se una cosa contiene lo stesso contenuto 
informativo, è reversibile. E se è reversibile, è un 
compressore/decompressore.
Il fatto che questo sia irreale, è proprio perchè l'hash non è univoco.
Alberto
-- 
Henry David Thoreau: L'uomo è tanto più ricco quanto meno costano i 
suoi piaceri.

 compressore/decompressore.
Sembra piů un semplice indice. Se assegno un numero ad ogni file del 
mondo senza aver limiti posso identificare *univocamente* ognuno di 
essi ma da qui a tornare agli originali ce ne passa.
-- 
IBM: Insignificant Bothersome Machine


 essi ma da qui a tornare agli originali ce ne passa.
sul semplice e sull'univocamente vorrei avere le tue certezze. intanto ci 
ragiono e cerco di seguirvi...
ciao, a.

 ragiono e cerco di seguirvi...
Se hai 1000 file, e li numeri da 1 a 1000 hai un indice. Se siamo 
d'accordo su questa numerazione e tutti e due abbiamo i 1000 file 
possiamo indicarli in modo molto compatto. Ti posso dire, leggi il file 
732. Magari è la Divina Commedia e io ti ho comunicato tutto il testo 
della Divina Commedia con un numero di 3 cifre... potente come 
compressione, vero? :-)
Peccato che serve a poco. Devi avere tutti i file e anche la tabella che 
li correla. Lo schedario di una biblioteca non contiene l'informazione 
dei libri, ma ne è solo un indice per aiutari a trovare quella informazione.
La corrispondenza è biunivoca, ma lo puoi fare solo perché il numero di 
libri è ragionevolmente piccolo.
Se invece io voglio trovare un algoritmo di compressione senza perdita e 
che funziona su tutti i file possibili, devo necessariamente mantenere 
intatto tutto il contenuto informativo nella trasformazione. Ho una 
corrispondenza biunivoca tra due file, contengono la stessa informazione 
e si spera che il secondo sia più piccolo del primo. Questo funziona 
perché quasi sempre i file non sono casuali, e quindi si può trovare una 
regola (algoritmo) per esprimerli in una "notazione" abbreviata. A quel 
punto io ti do il file "stenografato" e tu con la regola recuperi il 
file originale. E' quello che fanno i compressori.
Ma come devono essere questi file perché in metodo sia applicabile e 
utile? Quanto deve essere lungo e complesso l'algoritmo da utilizzare, e 
come questo dipende dal contenuto informativo? Questa roba è la teoria 
dell'informazione, con tanta matematica e teoremi rigorosi.
Visto che non sono un informatico ma un chimico, queste cose me le ero 
chieste pure io, e un po' mi sono informato. diciamo quel minimo che 
basta per placare la curiosità e avere presente il concetto generale... 
molto generale :-)
Se ti interessa l'argomento ti posso cercare il link di un documento 
agevole e abbastanza divertente sulla teoria dell'informazione. Parla 
proprio di queste cose.


 proprio di queste cose.
si', grazie mille, anche per la pazienza a spiegare.
ciao, a. 

andrea palazzi wrote:

http://www2.ing.unipi.it/~d4200/caso.pdf
