Detecteert (MD5) checksum verify bitrot?

[droner]

Eigenlijk alleen even kort deze vraag.

Achtergrond een topic wat ik een tijd geleden startte en een later topic waar ik zojuist op stumblede. Ik leefde tot voor kort in de illusie dat ik door (MD5) checksums te verifyen bitrot op zou kunnen sporen. Disclaimer: svp antwoord zonder de termen ZFS en BTRFS (wat natuurlijk ook nergens voor nodig is gezien de korte vraag, maar, ik weet.)

[Rannasha]

Ja.

Zolang je zeker weet dat op het moment dat je de MD5 hash genereert het bestand OK is, dan kun je vervolgens de hash gebruiken om later te controleren of het bestand ongewijzigd is.

Let wel op dat eventuele bitrot zowel het daadwerkelijke bestand als de MD5 hash (die ongetwijfeld ook ergens opgeslagen is) kan treffen. Het is dus mogelijk dat het bestand 100% in orde is, maar de hash niet klopt omdat de opgeslagen hash is gewijzigd.

[droner]

Thanks Rannasha! Da's alles wat ik wilde weten.

[Gomez12]

En je hebt nog een bijna puur theoretische kans dat de bitrot exact gelijk is aan een collission.

Maar alhoewel md5 geen supergigantische entropie heeft blijft het een bijna puur theoretische kans.

Zou je hier toch rekening mee willen houden dan zou je gewoon nog een hashing met een grotere entropie kunnen pakken (sha1, sha256 etc) alleen je blijft de puur theoretische kans behouden, je maakt hem alleen steeds kleiner.

[begintmeta]

Zoals hierboven aangegeven kan dat op zich dus inderdaad. Overigens gebruikt btrfs (en nilfs) vziw crc32c en zfs fletcher4 of SHA256.

[droner]

Gomez12 schreef op dinsdag 07 juni 2016 @ 00:03:
En je hebt nog een bijna puur theoretische kans dat de bitrot exact gelijk is aan een collission.(...)

In plaats van 'En' bedoel je dus 'Maar', waarbij je dus eigenlijk aangeeft dat checksums nooit 100% zekerheid kunnen bieden ivm die collision, correct? Wat volgens begintmeta dus ook geldt voor de in deze thread verboden termen maar dan met minder risico?

[ Voor 12% gewijzigd door droner op 07-06-2016 01:04 ]

[Gomez12]

droner schreef op dinsdag 07 juni 2016 @ 01:02:
[...]


In plaats van 'En' bedoel je dus 'Maar', waarbij je dus eigenlijk aangeeft dat checksums nooit 100% zekerheid kunnen bieden ivm die collision, correct? Wat volgens begintmeta dus ook geldt voor de in deze thread verboden termen maar dan met minder risico?

Correct, hashes / checksum kunnen simpelweg geen 100% zekerheid geven want je kan niet magischerwijs een 4GB bluray in 256 tekens kwijt.
Echter is het wel een 99,9999999999999999 (en nog een paar negens)% zekerheid qua bitrot.

Want het kan best zijn dat die 4GB bluray dezelfde checksum heeft als een 10kb text-bestand (of vele bestanden ertussen) maar de kans dat je bitrot echt daadwerkelijk je 4GB bestand aantast zodat het exact op een collision uitkomt is 0,0000(en dan nog een hele hele heleboel nullen)1%.

Simplistisch gesteld is de kans dat je vandaag van alle loterijen op de wereld 1 ticket koopt en daarmee de hoofdprijs van elke loterij wint groter dan dat bitrot in een 100-jarig leven dezelfde checksum oplevert van 1 bestand (mits normale bestanden, er zijn specifieke situaties te forceren waarin je heel vaak collisions tegen gaat komen maar dan moet je zo ongeveer hashing gaan bruteforcen en dan ook nog alle tussenresultaten naar disk gaan schrijven)
Oftewel de kans is er, alleen praktisch gezien is die er bijna niet. Je moet echt al de pech in de wereld hebben dat het optreed en dan alsnog zal het maar voorkomen bij 1 bestandje.

Kijk eens hoeveel bestanden op je hdd staan en kijk dan eens om hoeveel bestanden je iets geeft. Een windows-bestand mag van mij best corrupt raken, ik vind het ongemakkelijk en wellicht betekent het een reinstall maar ik ben geen data kwijt.

P.s. ik weet niet waarvoor je het exact wilt gebruiken maar persoonlijk zou ik kiezen voor een sha-256 checksum en niet voor een md5, alhoewel het met md5 al een theoretisch iets is maak je de kans toch nog net een stukje kleiner met sha-256 alleen dit kost je wel snelheid. Alhoewel ik het met hedendaagse computers en met goed geschreven software snelheid geen issue meer vindt, veelal is het toch je hdd/ssd die je tempo bepaalt en niet je hashing algoritme.

[ Voor 11% gewijzigd door Gomez12 op 07-06-2016 01:46 ]

[droner]

Windows en bitrot lijkt me juist een erg aangename combinatie; eindelijk gerechtigheid voor al die keren dat ik me zat te verbijten tijdens ongevraagde update installaties zonder voortgangsindicatie, onzinnige foutmeldingen, kromme interacties, et cetera et cetera.

Los daarvan, dank voor je uitgebreide geruststelling. Rannasha had dus inderdaad gelijk - Geen gelijk gelijk, maar wel gelijk genoeg. Prettig voor de nachtrust!