MD5 opnieuw onder vuur na publicatie 'collision'-code

De publicatie van een nieuwe en snelle methode om zogenaamde 'collisions' te vinden vormt het definitieve bewijs dat het hash-algoritme MD5 niet langer sterk genoeg is om toe passen op plaatsen waar veiligheid van cruciaal belang is. Hoewel er al geruime tijd gewaarschuwd wordt dat MD5 zijn beste tijd gehad heeft, waren serieuze aanvallen in de praktijk nog niet echt haalbaar. De wetenschappers die de zwakte hebben blootgelegd hadden namelijk geen code vrijgegeven, en meldden bovendien dat ze gemiddeld een uur tijd op een supercomputer nodig hadden om hun berekeningen te voltooien. Het nu aangekondigde programma is echter niet alleen veel sneller (gemiddeld drie kwartier op een verouderde 1,6GHz Pentium 4), maar ook nog eens vrij te downloaden voor iedereen die interesse heeft.

Wat het algoritme doet is het zoeken naar een 'collision', oftewel een invoertekst die exact dezelfde hash oplevert als het origineel. Collisions zijn per definitie mogelijk in ieder hash-algoritme, omdat de uitvoer een beperkt aantal combinaties heeft (128 bits in het geval van MD5), terwijl er wel oneindig veel mogelijkheden voor de invoer bestaan. Hieruit volgt dus dat er ook oneindig veel data is die dezelfde hash oplevert. De kunst van het bouwen van een goed hash-algoritme is om het vinden van een collision praktisch onmogelijk te maken, maar in het geval van MD5 blijkt het nu dus juist heel snel te kunnen. Als een bericht of bestand overeenkomt met de bijbehorende MD5-hash is dat straks dus geen garantie meer dat er ondertussen niet mee geknoeid is, wat afhankelijk van de toepassing een veiligheidsrisico kan vormen.

Wat op dit moment (nog) niet kan is het zoeken van een invoerstring die een bepaalde hash oplevert, waardoor het hashen van wachtwoorden - een van de populaire toepassingen van MD5 - voorlopig nog veilig blijft. Toch dringen beveiligingsexperts er op aan om MD5 zo snel mogelijk uit te faseren en te vervangen voor iets sterkers, zoals SHA-256. Microsoft liet in september al weten hiermee bezig te zijn. Ook de Amerikaanse overheid (in de vorm van het NIST) maakt zich hier sterk voor.

Reacties (55)

[Pther]

Over het algemeen heeft een hash 3 belangrijke eigenschappen:

1. Preimage resistant: bij gegeven h is het niet mogelijk om een m te vinden zodat hash(m) = h; Dit is van toepassing op het terugvinden van een wachtwoord als je de hash hebt.

2. Second preimage resistant: Gegeven een m1 is het niet mogelijk om een m2 te vinden zodat hash(m1)=hash(m2); Dit is bijvoorbeeld van toepassing om te bewijzen dat er geen wijzigingen in een tekst zijn aangebracht.

3. Collision-resistant: Het is niet mogelijk een m1 en een m2 te vinden zodat hash(m1)=hash(m2); erg algemeen en voornamelijk theoretisch interessant.

Alleen de derde eigenschap is gekraakt: het algoritme wat wordt beschreven levert twee willekeurige sets data die toevallig dezelfde hash opleveren. Dus feitelijk zijn alle toepassingen die boven genoemd worden nog volstrekt veilig.

Maar het breken van de derde eigenschap is meestal een teken dat de andere twee het ook niet lang meer volhouden, zodat het nu al afgeraden wordt om MD5 te gebruiken.

[Anoniem: 106923]

1. Preimage resistant: bij gegeven h is het niet mogelijk om een m te vinden zodat hash(m) = h; Dit is van toepassing op het terugvinden van een wachtwoord als je de hash hebt.

rainbowtables anyone? en eventueel bruteforce. MD5 is maar 128 bits...

2. Second preimage resistant: Gegeven een m1 is het niet mogelijk om een m2 te vinden zodat hash(m1)=hash(m2); Dit is bijvoorbeeld van toepassing om te bewijzen dat er geen wijzigingen in een tekst zijn aangebracht.

Dit is dus door het artikel aangegeven dat het dus WEL mogelijk is. Zelfs binnen 1 uurtje... --> quote uit het bericht: "Wat het algoritme doet is het zoeken naar een 'collision', oftewel een invoertekst die exact dezelfde hash oplevert als het origineel."

3. Collision-resistant: Het is niet mogelijk een m1 en een m2 te vinden zodat hash(m1)=hash(m2); erg algemeen en voornamelijk theoretisch interessant.

Theoretisch totaal niet interresant. Een wiskundige zou zeggen: aantal mogelijkheden voor m1 of m2 = oneindig aantal mogelijkheden voor hash(x) = 2^128.

2 ^ 128 < oneindig dus er is een m1,m2 waar hash(m1)=hash(m2)

[Pther]

rainbowtables anyone? en eventueel bruteforce. MD5 is maar 128 bits...
Bruteforce wordt niet als een veiligheidsprobleem gezien omdat dat bij iedere denkbare hash mogelijk blijft. Daarnaast duurt het gewoon veel te lang: mijn P4 kan een miljoen hashes per seconde berekenen en zou dus 10^24 jaar nodig hebben voor een bruteforce.
Rainbowtables zijn niets anders dan een versnelling van bruteforce door het feit mee te nemen dat mensen slechte wachtwoorden kiezen.

Dit is dus door het artikel aangegeven dat het dus WEL mogelijk is.
Dat staat hier inderdaad, maar dat is dus niet waar. Het bewijs daarvan vind je eenvoudig door het originele artikel en/of de broncode door te lezen.

Theoretisch totaal niet interresant. Een wiskundige zou zeggen:
Een wiskundige zou het met mij eens zijn. Ik ben een wiskundige en vrijwel dagelijks met dit soort dingen (collissions enzo) bezig. Ik weet waar ik het over heb

[wizzkizz]

sterker nog (zoals ook al in het artikel staat btw), aangezien de mogelijkheden voor de invoer oneindig zijn en MD5 een beperkte lengte heeft, is het aantal mogelijke collisons oneindig groot.

Je moet ze alleen ff wete te vinden

[Mithrandir]

Wat het algoritme doet is het zoeken naar 'collisions', oftewel twee invoerteksten die exact dezelfde hash opleveren.

en

Wat op dit moment (nog) niet kan is het zoeken van een invoerstring die een bepaalde hash oplevert

Eh, wat kan er nu wel en wat kan er niet? Eerst staat er dat er wél twee dezelfde gevonden kunnen worden, maar vervolgens kan dat toch niet?

Dus er kunnen wel twee random teksten gemaakt worden die de zelfde hash maken, maar niet van een hash weer een tekst gemaakt worden?

Dat maakt dus niet uit voor de veiligheid van je wachtwoord zou je denken, omdat ze niet een wachtwoord kunnen genereren vanuit de hash. Of zie ik nu iets over het hoofd?

[Wouter Tinus]

Je kunt bij een tekst een andere tekst zoeken die dezelfde hash oplevert, maar als je alleen een hash hebt kun je verder niets.

Dat maakt dus niet uit voor de veiligheid van je wachtwoord zou je denken, omdat ze niet een wachtwoord kunnen genereren vanuit de hash.

Dat staat ook in de post.

[Anoniem: 2185]

Meestal is een ww erg kort dus daar de hash van spoofen word een beetje lastig. Echter op grotere bestanden is het nu redelijk eenvoudig om de data zo te veranderen dat de hash hetzelfde is. Als voorbeeld een .exe van 2mb die dan vervangen word door een .exe van 1.7mb en .3 mb garbage om de hash goed te krijgen.

[RobT]

Je kunt bij een tekst een andere tekst zoeken die dezelfde hash oplevert, maar als je alleen een hash hebt kun je verder niets.

Volgens mij ligt het net even anders: je kunt 2 files genereren die een duidelijk verschillende inhoud hebben, maar die toch dezelfde lengte en md5 hash hebben.

Dit betekent dus voor bv Linux rpms die doorgaans met md5 op authenticiteit gesigned worden, en voor hashing van p2p files, er niet zoveel aan de hand is - daarbij heeft men immers geen toegang tot het origineel, men zou daar een 2e file moeten kunnen maken met de gewenste hash, en dat gaat (nog) niet.

Zeg het maar als ik er naast zit - voor zover ik begrijp ligt het in elk geval zo.

[Anoniem: 399]

Nee, andersom: als je de uitvoer hash weet van Film A (Hollywood blockbuster) kun je Filmpje B (oma met hond bij de vijver) plus een berg losse bytes tot één bestand vormen en door de losse bytes op de juiste manier te gebruiken (de juste garbage erin te gooien) een file produceren die exact de grootte en hash heeft van het origineel ZONDER het origineel te kennen.

Daarom kun je ook geen hash gebruiken om het password te vinden: andersom gaat dit niet. Je kan aan de hash niet zien wat het wás toen je de hash maakte. Dat is precies de reden dat je hash van Film A kan "neppen" met de hash van "Film B + rotzooi" maar je kan van de hash niet "Film A" herleiden, omdat je maar een beperkt e hoeveelheid data in de hash opslaat (bijvoorbeeld 256 bits, bij 256 bits encryptie)

[Anoniem: 93545]

Dat maakt dus niet uit voor de veiligheid van je wachtwoord zou je denken, omdat ze niet een wachtwoord kunnen genereren vanuit de hash.

Als je een MD5 hash hebt is het een kwestie van tijd om achter het bijbehorende password te komen. (seconden,minuten,uren,dagen,weken afhankelijk van de lengte en complexiteit van het wachtwoord)

[Anoniem: 39126]

Klopt, maar dan ben je bezig met een brute force attack. Er is dan geen sprake van een 'lek' in het algoritme.

[martijnvanegdom]

Er word ook niet gesproken over een lek in het algorithme..
Gebleken is gewoon dat de rekenkracht md5 heeft ingehaald.. Tja kan gebeuren..

Even een encryptie voorbeeld.. RSA 4 bit dat ragt elke pc binnen enkele seconden naar de eeuwige jachtvelden.. RSA 1024 bit.. daar hoef je niet eens aan te beginnen, laat staan aan RSA 2048 bit..

Dat RSA 4 bit zo snel weg is, ligt gewoon niet aan het algorithme, maar gewoon aan de rekenkracht die er tegen over kan zetten, en het dus kunt brute force.

Om even bij RSA te blijven.. RSA is gekraakt als er een snelle manier komt om een product van 2 priems te ontbinden in diezelfde priems. (dus je weet het product maar je wilt de priems weten) dat lijkt op dit moment nog erg lastig, maar als er een vinding komt maar mee dat wel kan.. dan is RSA gekraakt

[.oisyn]

Er word ook niet gesproken over een lek in het algorithme..
Gebleken is gewoon dat de rekenkracht md5 heeft ingehaald.. Tja kan gebeuren..

Uhuh, en die oude 1.6 GHz pentium is natuurlijk sneller als die supercomputer van een paar maanden geleden

Het is wel degelijk een lek in het algoritme; als ze een tekst hebben, dan kunnen ze die tekst zo aanpassen (dmv padding) dat de hash ervan hetzelfde blijft. Op deze manier kun je dus bijvoorbeeld malafide data aan een bestand toevoegen, terwijl de gebruiker niet weet dat er wat is veranders omdat de hash hetzelfde is gebleven.

[TheOneLLama]

Wat er staat is dat je niet de data kan achterhalen waarmee de hash is gegenereerd.

Dat (nog) mogen ze wel weglaten, wat het is dan ook niet mogelijk, behalve door het te raden. En dan nog weet je nooit zeker of dat de data was of iets anders.

Maar het heeft wel degelijk nut voor sommige mensen. Als ze bv een gehashed password onderscheppen, kan men een nieuw password generen wat mogelijk ook werkt.

Een andere mogelijkheden is files op filesharing netwerken corrupten, die MD5 gebruiken om te kijken of de gedownloade data correct is. Probleem is dat men daarbij wel data van dezelfde (bekende) lengte moet generen als het orgineel.

[DieterVDW]

Wat er staat is dat je niet de data kan achterhalen waarmee de hash is gegenereerd.

Dat kan je sowieso nooit. De hashfunctie beeldt immers een oneindig aantal inputstrings af op elke hashwaarde, dus er bestaat geen inverse functie...

[Twixie]

Misschien begrijp je het beter als ik je de 'birthday paradox' uitleg. Het is immers gemakkelijk te berekenen dat in een groep van slechts 23 personen de kans al 50% is dat twee personen eenzelfde verjaardag hebben. Dat wil echter helemaal niet zeggen dat de kans dat iemand verjaardag X heeft ook 50% is. Die kans is immers veel kleiner (ongeveer 5%).
In het tweede geval is misbruik heel reëel. Ik geef je een digitaal ondertekend contract, en jij kunt beginnen zoeken naar een andere tekst voor het contract (bvb lagere kostprijs) die dezelfde MD5 oplevert. Maw mijn digitale handtekening zal nog steeds kloppen alhoewel jij de tekst opgesteld hebt en niet ik.
Maar ook het eerste geval is eigenlijk al problematisch. Want dan kan ik beginnen met 2 contracten te zoeken die dezelfde hash opleveren (bvb door een deel van het contract variabel te maken adhv niets-zeggende referentiecodes). Ik geef je het ene contract ter ondertekening aan jou, en achteraf zeg ik dan dat je het andere contract ondertekend hebt.

PS: meer realistisch voorbeeld van misbruik MD5 is natuurlijk gesignede executables omdat je daar nog veel gemakkelijker willekeurige rommel in kwijt kunt om de MD5 te doen matchen.

[martijnvanegdom]

"MD5 niet langer sterk genoeg is om toe passen op plaatsen waar veiligheid van cruciaal belang is."

Iedereen die snapt wat security is, zal zeker niet voor MD5 kiezen op de plaatsen waar dat van cruciaal belang is. Daarvoor is md5 gewoon te weak.

Als je echt iets strongs moet hebben dan gebruik je een RSA -achtige techniek.

Ik gebruik md5 nog vrij veel. Vooral om passwords te storen in een database. Maar ik denk na het horen van dit bericht dat ik inderdaad een andere variant ga zoeken.

[Sjonny]

md5 is hashing, rsa is encryptie .. totally different.

[martijnvanegdom]

Niet compleet different.

Hashing (MD5) is een 'one-way-encryption'
RSA is een 'two-way-encryption'

Beiede vormen ene vorm van encryptie.. Immers encryptie is simpelweg data-manupilatie om er voor te zorgen dat gegevens inprincipe onleesbaar zijn. In het geval van md5 is dat dus ook het geval. RSA kun je ook weer decoderen.

[Snake]

Ik probeer het programmatje aan de gang te krijgen, maar ik zie nergens een handleiding ofzo?

Ben er eigelijk beetje van verschrokken!

Mijn paswoorden staan in md5 in mijn DB, en die is gewoon via bruteforce te kraken ( gewoon 100000000 keren uitproberen op de loginpagina ), en als ze dan een collision berekenen op mijn PW's, dan kunnen ze ook mijn website binnen ( nu dit kon eigelijk ook via bruteforce )

* 786562 snake903

[burne]

NOFI, maar als jij 100.000.000 pogingen niet doorhebt verdien je het volledig. Ik gok dat die logfile van 100Gbyte je eerste hint zal zijn.

[martijnvanegdom]

sha1() kun je eventueel gebruiken.. maar misschien dat ik zelf maar wat ga schrijven in cgi..

[Shift]

Wat is nou veiliger md5 of sha1 ?

[Anoniem: 58827]

Wat is nou veiliger md5 of sha1 ?

Je hebt ook nog het redelijk onbekende FQDN 2 maar daar weet ik voor de rest ook weinig over.

[ebx]

sha256, ook gewoonweg in php te gebruiken.
enige nadeel neemt iets meer ruimte in de databse.

wel een stuk veiliger

[wica]

Dit heef toch niets met MD5 te maken. Het al sinds dat er login pagina's bestaan, mogelijk om door middel van vaak genoeg raden. Binnen te komen, tenzij ze lees toegang hebben tot de database met de md5 strings van je password.

Was te verwachten dat dit ooit gekraakt zou worden. Maar agh. Dus gaan we weer naar de volgende sha1 bv. tot dat deze wer gekraakt kan worden.

[YaPP]

Mijn paswoorden staan in md5 in mijn DB, en die is gewoon via bruteforce te kraken ( gewoon 100000000 keren uitproberen op de loginpagina ),

en daarom hoor je ook altijd een "seed" ofwel geheim ingredient bij je md5/hashing invoer te gebruiken, zodat de originele string niet te achterhalen is met de hash.

en heb je er nooit over nagedacht om na bijvoorbeeld 5 pogingen een aantal minuten/uur lang geen invoer te accepteren

[siepeltjuh]

Dit 'probleem' is deels prima op te lossen, door iets als dit:

<?php
$Pass = 'geheim';
$md5_Pass = md5($Pass.'Geheim2');
?>

En het dan pas in de database zetten. De persoon die inlogt, heeft geen controle over de uiteindelijke hash, omdat er altijd een stukje tekst aan toe word gevoegt.

Nadeel is, mocht de hacker bij je database kunnen komen, om aan de hashes te komen, dan kan hij zeer waarschijnlijk ook aan je php code komen om die veradneringen te zien.

[Anoniem: 137466]

en toch is salten met SHA veiliger

sha(md5($var).$var.'SALT');

[martijnvanegdom]

dit md5 heeft daar weinig nut meer..

Want je krijgt puur een andere var terug ...

gewoon er uit gooien scheetlt preformance

[psyBSD]

Hij mag die verandering best zien.

[Anoniem: 106923]

Ligt eraan in welk opzicht. Als je je wilt beschermen tegen rainbowtable attack (iig de alpha-numeric-symbol14 tables) dan werkt salten heel goed. Door te salten krijg je een input die niet in de bovenstaande tabel zit, en dus geen hit op zal leveren. Als de salt bekend is, kan redelijk 'eenvoudig' een tabel gegenereerd worden die rekening houdt met de extra toegevoegde karakters van de salt (of 'all' gebruiken als charset). Daarom wil je deze graag geheim houden.

Maar als je eenmaal de hash hebt, en je wilt gewoon binnen zonder het password te hoeven weten maakt het niet uit. Binnen een uur heeft hij een collision gevonden, en kan er gewoon ingelogd worden met de string die de collision oplevert.

[Anoniem: 54761]

Als iemand aan/bij je database kan komen is er zowieso iets mis.

Een redelijke methode bij het inloggen is de 'challenge/response' methode. Dit zorgt ervoor dat je geen een keer de hash van je password verstuurd.

De 'hacker' heeft niet de hash van jouw wachtwoord en die hash veranderd iedere keer als je inlogt.
linkje: [php] md5 password onderscheppen.

[KMK]

Siepeltjuh heeft gelijk
dit heet SALTEN
Zorg dat je het salt opslaat in de database zodat je weet wat een deel van het antwoord moet zijn.

HMAC MD5 is ook een leuke techniek dan moet je er een password string doorheen gooien.

Conclusie: Puur MD5 is niet meer zo slim gebruik dan SHA-1 voor passwords storen.
Als je het goed wilt doen 'SALT' je de beole en doe je een HMAC over een ander bekend iets.

[daft_dutch]

Lezen is ook een vak
JE KAN geen code terug krijgen van md5
MD5 maakt er een hass van dus als iemand je code weet kan hij een andere code die de zelfde hash heeft maken.
Dus je moet altijd de code weten.

Dit heeft consequenties voor software producenten

debian linux voorbeeld
als je je systeem update wordt van een site packages gedownload. deze worden gecontroleerd met een HASH.

als een cracker daar inbreekt en malofide software plaats klopt de hash niet meer. Nu kan hij doormiddel van dit algoritme. informatie aan zijn zooi toe voegen zodat de HASH het zelfde is.

met alle gevolgen van dien.
heb je na je update een stel wormen op je pc zonder dat iemand dat snel door heeft.

edit opmerking
die hashes worden telkens gecontroleerd of die nog het zelfde zijn zodat je geen nieuw hash kan plaatsen

[Anoniem: 30141]

Ik zie hier dus een probleem voor de torrent gebruikers, blijkbaar kan je, wat eerder ontkend werd, wel blokken data maken met dezelfde hashcode, waardoor corrupte data niet opgemerkt word.

Dusuh, kunnen enkele users je downloads wel degelijk corrupt maken.

[Twixie]

Neen, klopt niet wat je zegt. Want de collision die nu gevonden is, betekent dat je 2 datasets kunt vinden die dezelfde hash hebben. Dat betekent nog niet dat je gegeven 1 dataset (een valid P2P file) er gemakkelijk een andere (een fake P2P file) kunt vinden die dezelfde hash heeft. Dit is een veel moeilijker probleem (zie birthday paradox hierboven).
Zie overigens ook : http://en.wikipedia.org/wiki/Birthday_paradox

[Anoniem: 84969]

MD5 is ook niet bedoeld voor beveiliging, maar voor hashing. Voor beveiling moet je cryptografie gebruiken. Natuurlijk is er nog wel een security risk omdat je packages kan veranderen terwijl ze dezelfde hash hebben, maar voor beveiliging is het nooit goed geweest (net zoals een bijzettafel gebruiken om op te zitten, hij is niet gemaakt voor dat gewicht en zal een keer breken).

[halfgaar]

hashing is een intergraal onderdeel van encryptie, namelijk het "signen" van je keys enzo. GPG gebruikt SHA1 standaard, maar ik heb nog geen SHA256 gezien daarbij.

Wat op dit moment (nog) niet kan is het zoeken van een invoerstring die een bepaalde hash oplevert, waardoor het hashen van wachtwoorden - een van de populaire toepassingen van MD5 - voorlopig nog veilig blijft.

Dat lijkt me onzin. Als het password in de DB staat als een hash, en jij vult een vervangende invoertekst in die dezelfde hash oplevert, dan wordt het goedgekeurd. Je hoeft het _echte_ password niet te weten daarvoor.

Wat je moet doen als je echt veilig wilt zijn trouwens, is het password in twee hashes op slaan, MD5 en SHA1 bijvoorbeeld. Dan ook nog salted. Knappe kerel als je een invoertekst kan verzinnen die met beide algoritmen dezelfde hash oplevert...

[Munters]

Knappe kerel als je een invoertekst kan verzinnen die met beide algoritmen dezelfde hash oplevert...

Tuurlijk valt dat niet mee, maar het is van dezelfde orde van moeilijkheid als wanneer je de hashcode twee maal zo lang gemaakt had. Daar hoef je echt geen twee verschillende algoritmes voor te gebruiken.

Waarom je 2 algoritmes zou kunnen gebruiken is om je in te dekken tegen een plotselinge ontdekking dat een algoritme kraakbaar blijkt.

[KoalaBear84]

Vraagje:

Nu doen er veel dus md5(password) voor in de database.

Zou md5(md5(paswoord)) een stuk veiliger zijn?
En het gebruiken van salt en md5?

Voor Rainbow Cracking volgens mij wel toch?

nieuws: 'Rainbow'-database helpt bij achterhalen passwords

[martijnvanegdom]

Nee dat maakt niet veel uit zoals ik al eerder postte:

Een MD5 hashing van een MD5 hashing maakt het niet veiliger. Je blijft binnen dezelfde dimensie

Stel : strings kunnen maximaal 96 tekens bevatten. en we noemen deze verzameling S

Password (tekens 8 ) -> md5 hash
S8 -> S32
hier word dus inprincipe informatie toegevoegd.

bestanden(tekens 1000) -> md5 hash
S1000 -> S32
Hier word dus informatie geweggooid, meerdere bestanden kunnen dezelfde hash worden

md5 -> md5
S32 -> S32
Geen informatie toegevoegd , geen informatie weggegooid


Wat wel te verwachten is, is dat er in die database waarschijnlijk minder md5 hashes van md5 hashes waarmee het lastiger word om een match te vinden, maar het is geen concequente oplossing, voorgesteldde salts e en is een stuk beter

[Anoniem: 137466]

je kunt volgens mij,
dit niet snel terug rekenen

kijk

var -> hash1 -> hash2

als je een collision van hash2 hebt, kan dit vanalles zijn, maar komt dit waarschijnlijk NIET overeen met hash1

stel je voor 'abcd' is de collision om hash2 te krijgen,
dan kun je geen collision voor hash1 berekenen dmv dit algoritme; je weet niet wat hash1 is, en dus ook de collision (die gelijk moet zijn aan var, bij de input) niet

[Durandal]

Maar waar je gaat zoeken is dit:

andere_var -> hash2

Je slaat de eerste has stap dus gewoon over. En dat is net zo makkelijk als elke andere enkele hash.

[Faust]

Iedereen moet het boek "digital fortress" lezen!

Zeer interessant leesvoer en het schept een interessant scenario.

[ILUsion]

"Digital Fortress" ofwel "Het Juvenalismysterie" van Dan Brown is volgens mij niets waard. Het verhaal, tot daar aan toe; maar hij schrijft het boek in zo'n stijl dat je gaat geloven dat alles wat hij schrijft redelijk klinkt. En dat is het in geen geval. Iedereen die ook maar een greintje wiskundig verstand en inzicht in cryptologie heeft, doorziet zo de grove fouten die hij neerschrijft. Ik wil mezelf niet vooruit schuiven als expert-cryptoloog, maar ik ken toch enkele simpele dingetjes die gebruikt worden. Als ik, niet echt belezen in het onderwerp, er zo in zie dat het vol slordige fouten staat (Brown begreep duidelijk het concept bitlengte van een sleutel niet, een code van bv. lengte 64 werd in de halve tijd van een 128-bit gekraakt, volgens hem, terwijl het een factor 2^64 zou moeten zijn). Op internet zijn er evengoed genoeg sites te vinden die hierop ingaan: hier en hier bijvoorbeeld, maar er zijn er nog veel meer.

En kom nu niet af met dat het verhaal toch goed bedacht was; ik heb drie boeken van hem gelezen en ze gaan alledrie op eenzelfde manier voort. Er zit weinig verrassing in zijn werk, als ik eerlijk mag zijn. En vermits Digital Fortress over wiskunde/cryptologie gaat, kunnen we op zijn minst toch wel verwachten dat Dan Brown een beetje onderzoek had gedaan? Hij zegt dat hij twee NSA-medewerkers gecontacteerd had, in ieder geval heeft hij ze dan toch niets gevraagd over cryptologie.

In dat opzicht kun je misschien meer met het verhaal over Sloot aanvangen omdat je daarvan toch weet dat het uit iemands duim gezogen is.

[flossed]

Als je MD5 gebruikt als HASH, waar het voor bedoelt is, dan kan je met je hash aantonen dat er met de tekst niet geknoeid is. Hoewel je oneindig veel teksten kan genereren die eenzelfde has opleveren als de originele tekst, lijkt het me hoogst onwaarschijnlijk dat je een zinnige tekst kan generen die even betekenisvol is al het origineel. In dit geval is MD5 mijns inziens nog goed te gebruiken.
Ander verhaal wordt al je chuncks van een te versturen bin gaat hashen met MD5, kwaadwilligen die de binary defect willen maken, kunnen dit gemakkelijk doen door random chunk te genereren. Hoewel je na het samenstellen snel door heb dat er iets niet klopt, zal je tijdens transport dit niet kunnen bedenken.

MD5 als encyptie van van passwords ->? niet voor bedoelt
niet doen. niet zozeer dat het niet veilig zou zijn maar je kunt nooit iemand zijn originele password teruggeven. De gebruiker moet dus altijd met een nieuw password komen.

MD5 is dus nog best goed te gebruiken als een sterke vorm van CRC.

[wizzkizz]

MD5 als encyptie van van passwords ->? niet voor bedoelt
niet doen. niet zozeer dat het niet veilig zou zijn maar je kunt nooit iemand zijn originele password teruggeven. De gebruiker moet dus altijd met een nieuw password komen.

Dat is _juist_ de reden dat MD5 hiervoor wordt gebruikt. Maak je gebruik van een algoritme dat je in staat stelt om de versleutelde tekst (encrypted password zegmaar) gemakkelijk weer te decoderen, dan heeft dat niet zoveel zin. Public-private-keys gebruiken is hiervoor niet zinvol en complete overkill. One way hashing is hier dus perfect voor geknipt. En in de meeste applicaties kan de gebruiker het wachtwoord ook weer wijzigen naar iets wat ie zelf wil, dus dat is ook geen probleem.

[jmk]

Dus ik denk daarom dat de film/muziek industrie hier heel snel op in zal spelen. Public torrent-trackers worden met de dag onveiliger.
Ze zitten al soms fakes tussen waar spyware inzit, maar dit maakt het vrij makkelijk om in het begin goede .BIN voor bijna niemand bruikbaar te maken. Dit kan helemaal automatisch met een aangepaste torrent-client voorspel ik.
Private tracker kunnen op deze manier net zo goed worden aangepakt.

Ik denk dat Bittorrent snel met een andere Hash techniek op de proppen komt.

Grappig is trouwens: In Kazaa had je dit probleem bij grote bestanden heel vaak. (niet moedwillig) Als je een .BIN(in dit geval een installatie CD) 2 keer downloade, kon je tijdens de installatie telkens van CD wissellen bij een read error. Dat wordt leuk films kijken straks!