Voor iemand mij verwijst naar een andere plek, ik heb deze al uitvoerig bekeken:

https://stackoverflow.com/questions/8184941/uniform-distribution-of-truncated-md5
http://michiel.buddingh.eu/distribution-of-hash-values

Vroeger volstonden MD5-sommen vaak. Tegenwoordig wordt MD5 niet meer voldoende geacht door de vele aangetoonde mogelijkheden om collisions te veroorzaken, d w.z. het genereren van een afwijkend bestand met eenzelfde checksum. Later zijn SHA(1) en SHA2 meer in gebruik genomen. Ik kan alleen maar gokken dat MD5 voor backwards-compatibility nog gegenereerd wordt.

Misschien is het nog informatief om te lezen wat GnuPG hierover te zeggen heeft: https://gnupg.org/faq/gnupg-faq.html#define_sha.

Ze zijn alleen RIPEMD160 vergeten in deze FAQ.

Voor bescherming tegen 'random corruptie' (onderweg, bitflips op de download server, of op jouw compu) is elk van de genoemde hashes voldoende.

Er staan vaak meerdere hashes zodat de kans groot is dat je tenminste één ervan makkelijk kunt controleren.
Niet iedereen heeft zin/tijd/mogelijkheid om weer een tooltje te zoeken voor "de enige en beste" hash die ergens zou kunnen staan.

Je hoeft ze zeker niet allemaal te controleren .
MD5 is niet geweldig meer - maar het construeren van een bestand met dezelfde MD5 hash als een gegeven bestand is nog steeds niet mogelijk.
En MD5 controleren is heel veel beter dan _niets_ controleren omdat je geen sha512 tool (of skein tool, sha-3 tool, of whirlpool tool) bij de hand hebt .

Wel is het te makkelijk om twee verschillende bestanden te maken met dezelfde MD5 hash. (dat heet een collision attack).
Bedenk dat in het scenario van "download programma" dit betekent dat iemand zowel het 'origineel' als het 'aangepaste origineel' moet maken om eenzelfde MD5 hash te hebben. Oftewel - alleen iemand die de bron bestanden van de auteur kan aanpassen kan dat.


Voor de verschillende eisen aan cryptografische hash functies lees :

https://en.wikipedia.org/wiki/Collision_attack
https://en.wikipedia.org/wiki/Preimage_attack
https://en.wikipedia.org/wiki/Cryptographic_hash_function

En de stand van zaken mbt tot MD5

https://en.wikipedia.org/wiki/MD5

Als je een checksum hebt bijv "ledenlijst-tennisclub.docx 326d11a08e4e6174aec36c0dee716c02" wat een md5 hash is dan kun je vast ook via bruteforcing deze lijst opnieuw bouwen. Als deze langer dan 7 chars is dan ben je wel een miljard jaar bezig maar misschien brengt de quantum computing wereld ons een doorbraak.

md5 is ouder en niet per se sneller met eerder kans op false positives, maar dat moet je dan maar op de koop toe nemen.

Nee het idee van het vermelden van meerdere digests is juist dat je NIET alle tooltjes geinstalleerd hoeft te hebben maar
alleen maar 1 ervan (die je dan checked) en de anderen hoef je niet te checken. Stond er maar 1 digest dan was je
verplicht om precies dat tooltje erbij te zoeken.
Tevens is het dan geschikt voor zelfs de meest paranoide persoon want die kan ze alle 5 checken.
(en reken maar dat die er zijn, gezien alleen al dat mensen schrijven "Tegenwoordig wordt MD5 niet meer voldoende geacht")

Behalve een hash wordt vaak ook nog genoemd het aantal bytes waaruit het bestand bestaat.
Hash en aantal bytes dienen als verificatiemiddel of het gekozen bestand volledig en zonder fouten en problemen is gedownload. Je kan de hashes bewaren, zodat je ook later nog kan controleren of er sprake is van corruptie of besmetting
terwijl het op je opslagmedium stond.

Er zijn verschillende hashes omdat ze zich in de loop van de tijd hebben ontwikkeld en niet alle hashes even sterk zijn.

Een hash is sterker naar mate het langer duurt om een ander bestand te creëren met precies dezelfde hash.
Daarom is md5 afdoende om te detecteren of er bij het communiceren of na opslag 1 of enkele bits zijn omgevallen.
Maar niet om te detecteren dat jij zonder dat het je opviel via http een kwaadaardig bestand van een Man in the Middle of gehackte downloadservice hebt gedownload, met exact dezelfde md5 hash en aantal bytes, maar met een hele andere inhoud.

Daarom dus voor alle zekerheid met een hele sterke hash of met meerdere hashes verifiëren als je via http download.
Echter als de hele website http is, dan is het nog maar de vraag of die hashes op jouw scherm wel kloppen,
en ook een gehackte website (http of https) met aangepaste bestanden én kloppende bijbehorende hashes helpt je niet!
Dus wel blijven relativeren al naar gelang de situatie die van toepassing is: een hashcontrole is geen viruscheck.

Tot slot: zoveel mensen zoveel wensen: de één vind het al snel genoeg, de ander wil nog zekerder weten of het okee is.
Verder staat niet op ieders systeem al een tool geïnstalleerd die alle hashes die er op de wereld bestaan aankan.
Door meerdere hashes aan te geven op de website kan men zelf kiezen wat men nodig vind en wat het systeem aankan.

MD5 is maar 128 bits lang en bevat dus niet meer dan 128 bits = 16 bytes aan informatie over een file. Als je een wachtwoord waarvan je weet dat die maximaal 16 bytes lang is met MD5 hasht, dan kun je die (met genoeg CPU tijd) brute forcen. Als ik je de MD5 sum van een bestand geef en ik zeg je dat het bestand 1024 bytes lang is, dan zijn er miljarden mogelijke bestanden die aan deze beschrijving voldoen (256^1008), dus het bestand brute-forcen is onmogelijk.

Wat ooit goed genoeg was is met de huidige stand van de techniek te compromitteren; wat nu goed genoeg is kan in de toekomst wellicht gecompromitteerd worden. Alleen al die ontwikkelingen maken dat wat een goede keuze is aan verandering onderhevig is.

En je weet nu niet wat duidelijk superieur is, je weet van een aantal hashalgoritmes dat die op dit moment, voor zover bekend, niet gekraakt zijn. Het is goed dat er meerdere opties beschikbaar zijn, zodat als er een omvalt er alternatieven beschikbaar zijn. Dat betekent niet dat op dit moment bekend is welk alternatief ooit onderuit zal gaan, en dus zijn er meerdere alternatieven die op dit moment goed zijn, en dus zullen verschillende mensen die nou eenmal iets moeten kiezen niet altijd dezelfde keuze maken.

Als je het breder beschouwt dan deze toepassing dan kunnen hash-algoritmes die op zich sterk zijn daarnaast eigenschappen hebben die voor verschillende toepassingen andere voorkeuren opleveren. Als je in een enorme verzameling bestanden hashes wilt gebruiken om duplicaten te vinden dan is het verdomd handig als die hashes heel snel te berekenen zijn. Als je echter een brute-force-aanval op een wachtwoorddatabase moeilijker wilt maken dan wil je juist dat het berekenen van een hash traag is. Er bestaan daarom speciale hashfuncties voor wachtwoorden.

Om op te reflecteren heb ik nog dit punt. Het is opvallend hoe vaak bij IT-gerelateerde zaken mensen denken dat er één superieure keuze zou moeten zijn. Jij hebt dit met hashalgoritmes, een ander stoort zich aan het grote aantal Linux-distributies, of snapt niet dat niet iedereen het naar hun mening duidelijk superieure programma X gebruikt voor een bepaalde toepassing. Jij zou je bijvoorbeeld kunnen afvragen waarom er überhaupt alternatieven bestaan voor Kodi.

Tegelijk hoor ik nooit iemand zich afvragen waarom niet iedereen in dezelfde auto rijdt, zijn huis exact hetzelfde inricht, precies dezelfde kleren draagt. Die hang naar eenvormigheid is in het IT-domein over het algemeen veel sterker dan daarbuiten.

Voor zover ik kan beoordelen komt dit vaak voort uit het idee dat het inefficiënt is om het wiel opnieuw uit te vinden (waarom zou je een kant en klare component nog moeten maken als hij al bestaat), en efficiënt om incompatibiliteiten te vermijden door allemaal hetzelfde te gebruiken. En de keuzestress die voortkomt uit diversiteit van dingen die zo complex zijn dat ze moeilijk goed te beoordelen zijn is er natuurlijk ook. Dat zijn legitieme punten, maar daar staat tegenover dat eenvormigheid kwetsbaarheden oplevert.

Bij hashalgoritmes is het risico dat als de hash die iedereen gebruikt gekraakt wordt iedereen voortaan zonder sterk hashalgoritme verder moet, als er geen alternatieven zijn. Als dat ene OS of die ene applicatie die iedereen gebruikt een vernietigend zero-day-lek heeft dan is een gebrek aan alternatieven en diversiteit in de toepassing ervan opeens een serieus probleem. Buiten de IT zie je momenteel dat de monocultuur in de bananenteelt die hele industrie bedreigt omdat er een ziekte is die ze niet weten te bestrijden.

En als de bron van die ene variant die iedereen gebruikt een commerciële reus is levert dat monopolie het risico op dat er weinig energie in de verdere verbetering van het produkt wordt gestoken en/of meer aandacht wordt besteed aan het uitmelken van klanten of gebruikers. Microsoft heeft op de desktop en met IE6 in die positie gezeten; over Oracle hoor je op IT-forums de nodige horrorverhalen; in de mainframewereld kocht CA ooit al zijn concurrenten op om vervolgens de ontwikkeling van die produkten op een laag pitje te zetten en tegelijk de licentiekosten te verdubbelen; Facebook en Google exploiteren persoonsgegevens van een groot deel van de wereldbevolking; er zijn voorbeelden in overvloed.

Eenvormigheid lijkt het leven makkelijk te maken maar op de langere termijn kan het juist grote nadelen hebben. Best iets om bij stil te staan als je je weer eens afvraagt of er niet één superieure oplossing is voor iets en waarom niet iedereen die gebruikt.

Meestal krijgt men verschillende hashing algoritmes aan te bieden om compatibiliteit van de site met verschillende gebruikers te vergroten.

md5/sha1 behoren overigens als het om veiligheid gaat bij real time on demand connecties niet meer toegepast te worden, de meningen verschillen hierover maar pas vanaf whirlpool, sha256 en hoger etc mag ik nog wat real time on demand functie te zien krijgen.

moeilijkheden bij hashing zijn MitM (zeer realistisch, veel vaker toegepast dan velen te vermoeden krijgen) waarbij men dus DENKT op de zogenaamd BETROUWBARE siteserver te zitten maar in feite verbindingen om gerouteerd worden naar een andere server. groene/grijze slotjes in adresveld etc ZELFS tot en MET exact dezelfde certificaat fingerprints gemakkelijk en realistisch haalbaar, en ook zonder MitM, hoe 'betrouwbaar' is die server en dus de checksums die daar gepubliceerd staan?

De reden dat het gebruik van MD5 en SHA-1 wordt afgeraden is dat collision attacks daarop mogelijk zijn, en omdat het lastig is om te overzien in welke scenario's daar misbruik van kan worden gemaakt (naast dat er nieuwe scenario's kunnen worden bedacht).

Het probleem is dat een kwaadwillende twee verschillende bestanden kan maken, of een bestaand bestand op twee verschillende manieren kan wijzigen, zodanig dat de twee resulterende bestanden dezelfde hash opleveren (ofwel MD5, ofwel SHA-1).

Die kwaadwillende kan de programmeur zelf zijn, bijv. omdat hij weet dat zijn software direct na uitbrengen grondig onderzocht zal worden; dan kan hij later de kwaadaardige variant distribueren. Een softwareontwikkelaar kan ook door een geheime dienst of fout regime worden gedwongen om dit te doen, zodat die dienst/dat regime de kwaadaardige versie aan dissidenten etc. kan verstrekken zodra ze deze downloaden. Daarnaast zijn er downloadservers die software met reclame/adware wrappers "omhullen". Ook zij kunnen daarmee twee verschillende versies met ofwel dezelfde MD5 hash, ofwel dezelfde SHA-1 hash, maken.

Met name voor digitale certificaten zijn hashes, waar collissions voor kunnen worden berekend, een doodsteek - als de certificaataanvrager kan orkestreren wat de waarde van de hash in de digitale handtekening (gezet door de certificaatuitgever) zal zijn.

Kortom, bij geen enkel hash-algoritme heb je de zekerheid dat er niet een afwijkend bestand zal bestaan met dezelde hash - de kans daarop is echter verwaarloosbaar bij als betrouwbaar bekend staande hashes. Bij SHA-1, MD5 en ouder/zwakker is echter aangetoond dat je met weinig moeite twee bestanden (desgewenst met relatief kleine verschillen) kunt maken, die dezelfde hash opleveren. Als je zoveel mogelijk risico's uit wilt sluiten, moet je die hashes daarom niet gebruiken om te checken of het bestand in jouw bezit identiek is aan een referentiebestand elders.

Dat is allemaal grootspraak, extrapolatie van bepaalde zaken die gelukt zijn naar wat er "in theorie allemaal zo kunnen".

Het gaat jou niet lukken om het typische download bestand, een gecomprimeerd archief zoals bijvoorbeeld .tar.gz of .zip
of iets dergelijks, dan wel een "package" zoals .msi .deb of .rpm op een zodanige manier te wijzigen dat de MD5 of SHA1
hash EN de structuur van de file nog intact is (zodat het uitpak/installatie tool nog werkt ) EN het nieuwe exemplaar een
door jou gewenst ander gedrag vertoont.

Precies deze reden is tevens waarom MD5 en SHA-1 nog wel geschikt zijn voor hashing (en controle) van bestanden. Je moet alleen zorgen dat je de hashmethode niet gebruikt voor opslag van wachtwoorden. Dan kun je beter voor SHA-2 of SHA-3 kiezen. Maar SHA-2 is nog wel voldoende.

Ik denk persoonlijk dat het voornamelijk zit in de snelheid van hashen. MD5 is (veel) sneller dan SHA-2 (SHA-256 bijvoorbeeld). In dat licht zou je zelfs kunnen kiezen om SHA-1 te gebruiken, want die is nét ff sneller dan MD5.

Ik schrijf nergens dat ik (of iemand anders) dit normaal gesproken kan. Ik probeer alleen maar uit te leggen wat de risico's zijn van het gebruik van MD5 en SHA-1 voor het controleren of een bestand identiek is aan een rederentieexemplaar dat je niet in je bezit hebt.

En zo'n aanval is niet theoretisch, google maar naar generate hash collision .
Of lees https://shattered.io/ (met name de secties over git en svn).

Twee keer fout, voor bestanden zie mijn reactie hierboven.

Voor de opslag van wachtwoord-afgeleiden is MD5 is net zo geschikt als de sterkste hash die je maar kunt bedenken, in zoverre dat hoe trager de hash, hoe veiliger. Het probleem met wachtwoordhashes zijn niet collisions of second preimage resistance, maar preimage resistance (hoe moelijk is het om een willekeurige input te vinden die een gegeven hash oplevert). Op dat aspect zijn MD5 en SHA-1 nog niet dusdanig gekraakt dat je aanzienlijk sneller dan met brute force zo'n input kunt vinden. En bij een 128bit lange hash zijn dat gemiddeld gigantisch veel pogingen.

Weer fout.

Nu kom je in de buurt.

Hashes worden ontworpen om snel te zijn. Een van de problemen met wachtwoorden is dat mensen voorspelbare karakterreeksen kiezen. Dus kunnen aanvallers rainbow tables maken. Je maakt het aanvallers ietsje moeilijker door een tragere hash te gebruiken, maar dat zet geen zoden aan de dijk. Als de kans bestaat dat wachwoordafgeleiden in verkeerde handen vallen, is het enige dat helpt bij zwakke wachtwoorden, (in combinatie met unieke salts natuurlijk) een bewust extreem traag gemaakt algoritme, zoals Argon2 (zie https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md#leverage-an-adaptive-one-way-function).

Als je cryptografisch random gegenereerde wachtwoorden van zeg 16 karakters of meer gebruikt, is de kans dat een MD5 hash daarvan "gereversed" kan worden naar datzelfde of een ander wachtwoord (een collision dus, die ook werkt als je het wachtwoord elders hebt hergebruikt en de betreffende andere partij hasht wachtwoorden op dezelfde manier) absoluut verwaarloosbaar. Vandaar het advies om een wachtwoordmanager te gebruiken, die je voor elke site een uniek random wachtwoord laat genereren (zodat zelfs bij -onverhoopte- opslag van plain text wachtwoorden de ellende beperkt blijft tot de gehackte site).

Functionaliteit en security gaan boven snelheid.
MD5 is prima om te detecteren of er bij de communicatie of opslag wel of niet een bitje is omgevallen in het downloadbestand.
Maar als je wilt nagaan of je echt het bedoelde bestand hebt binnengeladen en geen kwaadaardig door een MITM geïnjecteerd bestand (dat is aangepast om dezelfde md5-hash te genereren bij dezelfde grootte van het bestand),
dan heb je helemaal niks aan snel testen met MD5.