'Ook gesigneerde Windows-bestanden gevoelig voor md5-collision'

Een beveiligingsonderzoeker is erin geslaagd om executables te genereren die dezelfde handtekening hebben als officiële Windows-executables. De zwakke plek in de beveiliging is het al eerder kwetsbaar gebleken md5-algoritme.

Onderzoeker Didier Stevens analyseerde Authenticode, het mechanisme dat Microsoft ontwikkelde om systeembestanden en programma's van een digitale handtekening te voorzien. Hoewel Authenticode normaal gesproken het nog veilig geachte sha1-algoritme gebruikt, heeft Microsoft ook het gebruik van md5-handtekening mogelijk gemaakt.

Met behulp van de md5-collisiontool Goodevil wist Stevens relatief eenvoudig twee executables te bouwen die dezelfde Authenticode-hash hebben. Daarmee is het dus ook voor kwaadwillenden mogelijk om malware te voorzien van een hash die overeenkomt met die van betrouwbare executables of driverbestanden. Virusscanners die een whitelist met Authenticode-handtekeningen gebruiken, zouden zulke malware als veilig kunnen kwalificeren.

De aanvalsmethode van Stevens staat niet op zichzelf. Het is al langer bekend dat md5 structureel als onveilig moet worden beschouwd; in december werd nog met succes een methode geopenbaard om met behulp van md5-collisions geldige certificaten voor websites te genereren.

Reacties (63)

Heeft iemand van jullie het artikel eigenlijk wel gelezen?

Het gaat hier om een oud idee - je kunt twee files maken met dezelfde MD5 hash en een iets andere inhoud. Er is namelijk een bekende collision, en die kun je daarvoor gebruiken, want MD5 heeft de eigenschap dat als MD5(x1) == MD5(x2) dan is MD5(x1 + y) == MD5(x2 + y). Als je in "y" je programmaatje stopt met ergens een "if" statement die van het verschil tussen "x1" en "x2" afhangt, kun je zo'n goodevil dingetje in elkaar sleutelen.
Nieuw is dat de auteur nu deze eigenschap gebruikt om zijn executable ook te signen. Niet bijzonder schokkend.

En als er maar een enkele bekende SHA1 (of welk ander algoritme dan ook) collision gevonden wordt, dan kun je dezelfde truuk toepassen voor SHA1, zonder meer moeite te moeten doen dan voor MD5.

Wat het artikel pertinent niet doet is, wat hier gesuggereerd wordt, executables maken die dezelfde hash hebben als een andere. Dus geen gefakete gesignde explorer.exe. Zowel de "slechte" als "goede" executable komen van dezelfde auteur.

Uitrekenen van een MD5 collision - dus zoeken naar een y zodat MD5(y)==MD5(x) terwijl x!=y is nog steeds een berg werk, waar je een clustertje voor zult moeten inzetten. Dat lukt overigens wel met een berg hardware en een paar dagen tijd. Maar dan moet je ook nog zorgen dat de files even groot zijn en dat de "fake" versie ook nog je "nuttige" payload bevat.

[Reactie gewijzigd door cdwave op 20 januari 2009 12:18]

Samengevat: Het vervalsen van eigen werk is nog wel te doen, maar het vervalsen van andermans werk (voorlopig nog) niet. Zeker als de ander geen MD5 gebruikt maar SHA1.

Het verder genoemde "clustertje" moet ook wel heel erg groot zijn en de "dagen" heel erg lang als je "x" of "y" niet zelf kan kiezen. Het op die manier kraken is nog niet vertoond.

Dit is een correcte samenvatting.

Voor wat het ZDNet artikel insinueert heb je een "choosen-hash attack" nodig. Ik ken geen (publiek) algoritme om dit te doen, behalve brute-force. En brute-force van een 60K executable mag je vergeten.

Wat je zegt is niet helemaal waar. Er is een methode ontwikkelt die twee totaal verschillende executables zo aan te passen dat ze dezelfde MD5 hash bevatten. Ik heb de link verder in het artikel al geplaatst, maar voor de volledigheid:
http://www.win.tue.nl/hashclash/SoftIntCodeSign/

[edit: Ook hier geld, ik heb niet goed gelezen . We zijn het eens. Je kan twee files laten colliden, maar om jouw bestand dezelfde hash te laten hebben als de hash van een ander bestand kan niet. Tenzij je uiteraard over beide bestanden beschikt.]

[Reactie gewijzigd door flijten op 20 januari 2009 14:49]

Dat klopt, maar het algoritme laat je niet toe om de waarde van de hash te kiezen. Je kan niet vooropstellen dat je hash 1234 moest zijn. Je zal je tevreden moeten stellen met de hash waarde die Hashclash je geeft, dus verschillend van 1234.

En je hash kiezen heb je nu net nodig om een MD5 Authenticode signature van een software-maker over te nemen voor je eigen executable. Als die signature bv. voor hash 1234 is, dan moet jij een executable kunnen maken met hash 1234.
Nogmaals, dat kan je niet met Hashclash.

MD5 heeft de eigenschap dat als MD5(x1) == MD5(x2) dan is MD5(x1 + y) == MD5(x2 + y).

Pertinent onwaar. Dat geldt alleen als x1 = x2 (duh), en verder met een kans van 2¹²⁸ op 1 als x1 ≠ x2.
.edit: excuus, ik las md5(x1+y1) = md5(x2+y2) als md5(x1) = md5(x2). Als ook geldt dat y1 = y2 klopt het natuurlijk wel.

Het signen van een file gebeurt door een hash te berekenen over de file, en die hash vervolgens te encrypten middels public key encryption, met je eigen privésleutel die niemand anders weet. Jouw publieke sleutel is bekend, dus iedereen kan je signature decrypten, en dat vergelijken met de door hunzelf berekende hash van de file. Zijn die identiek, dan is het de bedoeling dat er aangenomen kan worden dat de file niet gewijzigd is, en dat die file van jou afkomstig is. Want als de file wijzigt, dan wijzigt (doorgaans) ook de hash, en aangezien anderen jouw privésleutel niet hebben kan de nieuwe hash niet opnieuw gesigned worden.

Maar wat is er nu aan de hand? Er bestaat mogelijkheden om bij MD5 een collision te genereren. Oftewel, om een file zo aan te passen, dat de hash na de aanpassing identiek is aan de originele hash. Op die manier heb je de privésleutel van iemand niet nodig, omdat de hash identiek is, waardoor de al geencrypte originele hash als signature gebruikt kan worden. Er zijn meerdere van dit soort mogelijkheden. Er werd ontdekt dat, door een 128 byte blok in het bestand op een bepaalde manier aan te passen, het mogelijk is om de hash identiek te laten zijn.

Om dan terug te komen op jouw eigen opmerking:

Wat het artikel pertinent niet doet is, wat hier gesuggereerd wordt, executables maken die dezelfde hash hebben als een andere. Dus geen gefakete gesignde explorer.exe.

Dat kan dus wél! Alleen het enige wat de onderzoeker gedaan heeft is uitgaan van een bestaande applicatie en zijn collision counterpart (good.exe en evil.exe dus), waarbij hij good.exe via de officiele manier gesigned heeft, en voor evil.exe de signature simpelweg heeft gekopiëerd. Evil.exe is dus niet via de officiele manier gesigned, en kan dus net zo goed door een kwaadwillende zijn geproduceerd, door minimale aanpassingen op good.exe uit te voeren.

Natuurlijk, het blijft een vrij lastig probleem om een applicatie met minimale aanpassingen iets anders te laten doen. Maar je hoeft 'm natuurlijk maar zo aan te passen dat exploits van buitenaf mogelijk worden. Als er ook maar 1 bit in de code wijzigt dan kunnen de rapen al gaar zijn. Op zichzelf dan natuurlijk nog geen explorer.exe met een virus, maar dus wel een met exploit mogelijkheden

[Reactie gewijzigd door .oisyn op 20 januari 2009 16:05]

Toch wel "fijn" dat er nu eens regelmatig bewijs komt voor deze zwakte van md5, dat zal bedrijven toch eens moeten aansporen om over te stappen op betere encryptie.

MD5 is geen encryptie. Het is een hash algoritme. Dat bovendien voor sommige doeleinden nog prima voldoet (zoals het hashen van wachtwoorden).

Oftewel, het probleem bij MD5 is momenteel dat, gegeven md5(x), het mogelijk is om een y te vinden zodat md5(x) = md5(y). Echter blijft het nog altijd knap lastig om de originele x te vinden, met name als die lang genoeg is.

[Reactie gewijzigd door .oisyn op 20 januari 2009 11:27]

Als je nu een implementatie moet maken voor het hashen van wachtwoorden dat is het wellicht toch verstandig MD5 NIET te gebruiken. MD5 wordt nu snel beter begrepen en zwakheden snel gevonden.

Zondermeer is een wachtwoorden algoritme waar de hash van het wachtwoord publiek is een stuk minder sterk tegen dictionary attacks.

1: Als password hashes bekend zijn moet je altijd de password veranderen. Zie: rainbow table attack
2: Geen enkele hashing agloritme is bestand tegen een dictionary attack, een dictionary attack is niks anders dan een selectieve brute-force.
3: Met seeding is MD5 nog steeds veilig voor password hashes (mits de seed ook geheim blijft). Note: het is altijd slim op passwords te seeden.
4: En natuurlijk ga je nu niet meer MD5 gebruiken, net zoals je SHA-0 en SHA-1 links laat liggen (SHA-2 is wat je minimaal gaat gebruiken). De houdbaarheid van SHA-1 is namelijk al verlopen. Whirlpool of Tiger zijn misschien betere keuzes (zo lang er nog geen SHA-3 is).

Wat ook vaak wordt gedaan om het bruteforce (en genereren van rainbowtables) veel duurder te maken, is het recursief hashen.

HashFunction(Password) = Hash

wordt vervangen door

HashFunction(HashFunction(HashFunction(Password))) = Hash

maar met een veel grotere recursie-diepte, bv. 1000 maal.

Dus 3des, maar dan over hashes? Dat is dezelfde discussie die gaande is tussen bijvoorbeeld banken (3des) en cryptografen (RSA, blowfish etc) over beveiligen.

En dan kun je nog steeds een hash vinden die matched ondanks dat je 1000x een hashfunctie uitvoert. Het gaat bij hashing niet om de uitgangswaarde ( de input), maar om het resultaat ( de output ) van de functie. 1000x een functieuitvoeren geeft met dezelfde input nog steeds hetzelfde antwoord (wat handig is bij vergelijken ), maar het behoudt dezelfde zwakte.

[Reactie gewijzigd door dirkmay op 20 januari 2009 13:36]

Als je 1000 maal kiest, wordt een dictionary of brute-force attack 1000 maal duurder. Met dezelfde hardware dus 1000 maal trager.

Stel dat een gemiddelde dictionary attack 1 dag duurt. Dan zal het met recursief hashen gemiddeld 1000 dagen duren.

Niet tevreden met 1000? Neem dan 10000, 100000, 123456, ...

Het blijft een zwakte, maar niet dezelfde.

Nee, je hebt gelijk. Net als dat 3des net zo veilig is als rsa.

Gebruik gewoon sha2, de grootte van deze hash bied meer veiligheid dan het beschreven md5 (of het aantal malen uitvoeren van dezelfde functie ).

[Reactie gewijzigd door dirkmay op 20 januari 2009 14:11]

Het is veel makkelijker om gewoon een salt bij de wachtwoorden erbij te gooien
Dat maakt de aanval van rainbowtables op de hashes al direct waardeloos

Je moet dan ook niet enkel md5(wachtwoord) nemen, en sha1(wachtwoord) is in dat opzicht precies zo onveilig. Je wilt ten eerste een salt gebruiken die lang genoeg is en uniek voor jouw database, zodat standaard rainbowtables al niet meer voldoen. Verder wil je per user een aparte salt gebruiken, zodat het ook niet interessant wordt om een rainbowtable voor jouw database te genereren op het moment dat de hashes op straat liggen.

En het feit dat MD5 collisions nu makkelijk mogelijk zijn betekent niet ineens dat SHA nu ook voor dit soort doeleinden veiliger is.

dit gaat dus niet op als de hashes niet public zijn, dan is het prima te doen.

Daarom moet je ook altijd een salt gebruiken voor je hash, waarmee ik overigens niet wil beweren dat je voor nieuwe implementaties nog steeds MD5 zou moeten (willen) gebruiken. Maar SHA1 is precies even gevoelig voor dictionairy attacks en rainbowtables als MD5, dus daar helpt overstappen sowieso niet tegen.

[Reactie gewijzigd door ATS op 20 januari 2009 12:39]

Oftewel, het probleem bij MD5 is momenteel dat, gegeven md5(x), het mogelijk is om een y te vinden zodat md5(x) = md5(y). Echter blijft het nog altijd knap lastig om de originele x te vinden, met name als die lang genoeg is.

Zolang de hash korter is dan de originele input die je erin stopt, zullen er volgens het duiventil-principe uit de discrete wiskunde, altijd meerdere inputs zijn die dezelfde hash genereren.

Is niet echt een probleem van MD5, maar hashes in het algemeen. De originele x vinden is, zoals je aangeeft, wel een uitdaging.

Een hash is daarom prima te gebruiken als checksum tegen corrupte downloads bijvoorbeeld, maar eventueel minder geschikt tegen moedwillig kwaadwillige acties.

[Reactie gewijzigd door 19339 op 20 januari 2009 12:31]

Zolang de hash korter is dan de originele input die je erin stopt, zullen er volgens het duiventil-principe uit de discrete wiskunde, altijd meerdere inputs zijn die dezelfde hash genereren.

Klopt, maar voor wachtwoorden gaat het pigeonhole principe nou juist meestal niet op. MD5 is een 128 bits hash, en derhalve zijn er dus 2¹²⁸ verschillende outputs (en laten we even aannemen dat die uniform verdeeld zijn). Wachtwoorden bestaal meestal uit hoofd- en kleinletters, en cijfers. Andere tekens komen natuurlijk ook wel voor, maar worden door de meeste mensen niet gebruikt en zijn daarom voor de potentiele hacker niet interessant om mee te nemen. 62 verschillende tekens dus.

Dat betekent dat een wachtwoord minstens 128 / ²log 62 =~ 22 tekens lang moet zijn om aan het pigeonholeprincipe te voldoen. Niemand gebruikt zo'n lang wachtwoord. Sterker nog, ik maak zelf door gebrek aan vertrouwen altijd gebruik van uniek gegenereerde wachtwoorden voor sites waar ik een account aan moet maken, die 16 tekens zijn, en veel sites hebben zelfs een limiet dat lager is dan dat (vaak 12 of 14 tekens, weet je ook meteen dat ze niet gehashed worden anders had dat natuurlijk niet geboeid ).

Dus, als er een algoritme bestond om, gegeven een md5(x) (of md5(salt1 + x + salt2) en gegeven salt1 en salt2), alle mogelijke x'en te berekenen van een bepaalde lengte, dan heb je in het geval van wachtwoorden vrijwel altijd de originele x terug. Gelukkig is dat algoritme (nog) niet bekend

Vroeger (in Unix) waren wachtwoorden altijd 8 tekens, gehashed of niet. Je kon natuurlijk langer invullen maar alles na de eerste acht tekens werd weggegooid. M.a.w. je kon na de eerste acht tekens een foutje maken in je wachtwoord en dat werd je vergeven.

Is dat niet meer zo?

Gelukkig wordt er standaard SHA1 gebruikt (je moet echt handmatig voor MD5 kiezen). Er zijn nagenoeg geen authenticode signatures in omloop die MD5 gebruiken zodat de impact van dit probleem zeer klein is.

Het blijft echter zeer raadzaam om voor security zaken geen MD5 meer te gebruiken.

[Reactie gewijzigd door tigger op 20 januari 2009 11:04]

Het gaat erom dat het mogelijk is om met MD5 te signeren en dat deze handtekening geaccepteerd word door het OS! Dat ik de mogelijkheid heb om mijn executable te signen met SHA1 en dat de meeste executables zo gesigneerd zijn doet niets af aan dit probleem! Ik hoef immers maar 1 geaccepteerde MD5 gesigneerde executable te vinden om hier misbruik van te kunnen maken...

[Reactie gewijzigd door albert_gerritsen op 20 januari 2009 11:16]

Het punt van het hele artikel (en ook mij reactie) is dat je iets kunt maken met -dezelfde- MD5 hash als een ander certificaat. Software die puur naar de hash kijken (zoals virusscanners) kunnen hiermee misleidt worden. Dat staat ook in bovenstaand artikel.

Daarnaast het is zo dat het OS ook gewoon bestanden accepteert die helemaal geen authenticode handtekening hebben.

Didier Stevens:

This demonstrates that MD5 is also broken for Authenticode code signing, and that you shouldn’t use it. But that’s not a real problem, because Authenticode uses SHA1 by default (I had to use the signtool in wizard mode and explicitly select MD5 hashing). In command-line mode (for batching or makefiles), the signtool provides no option to select the hashing algorithm, it’s always SHA1.

[Reactie gewijzigd door tigger op 20 januari 2009 12:02]

Er zijn anders vrijwel geen anti-virus pakketten (meer) die alleen naar hash kijken.

Het probleem hier is niet dat MD5 de 'standaard' is of dat het veel gebruikt wordt maar meer dat het nogsteeds wordt geaccepteerd. Daardoor kunnen dingen onterecht als veilig kan worden gezien . Het moraal van dit verhaal is dat je zo snel mogelijk support voor MD5 uit je software moet slopen.

Bij MD5 moet de software dezelfde waarchuwing geven als bij een helemaal unsigned document. Anders creer je een gevoel van veiligheid terwijl je het juist ondergraafd. Je kan immers van een gebruiker niet verwachten dat hij weet wat MD5 is en wat de wel en wee ervan is.

[Reactie gewijzigd door SuperNull op 20 januari 2009 11:29]

Waarom niet dubbel of driedubbel signeren? Dus zowel MD5 als SHA1 als SHA512 oid?

Lijkt een goed idee, maar dan met twee veilig geachte algoritmes.
In principe voegt het aan de orde van beveiliging niets toe (veilig + veilig blijft veilig), maar het geeft tijd voor het geval er een zwakte in een van de algoritmes gevonden wordt, om over te schakelen op een nieuw tweede algoritme.
Helemaal veilig krijg je het toch nooit. Het algoritme vertelt iets over het bestand, en niet over de totale bestand + sleutel combinatie. Als het maar veilig genoeg is.

Dat biedt (bijna) geen extra veiligheid ten opzichte van de sterkste techniek. Alleen overhead.

Dat is dus juist onveiliger dan een enkele sterke methode gebruiken zoals bijv. SHA256 of Whirlpool. Als je ze gaat combineren dan beperk je de input voor je hashfunctie tot de mogelijke uitkomsten van je eerste hashfunctie.

Is er een mogelijkheid om via één of andere registry aanpassing dan driver/executable signing via md5 automatisch uit te schakelen ?

[Reactie gewijzigd door denivan op 20 januari 2009 12:44]

Nee, en dat helpt ook niet. De handtekeningen worden geproduceerd door degene die de software maakt, niet door de computer waarop ze draaien. Wat je bedoelt is een optie waarmee het OS Authenticode-handtekeningen die van MD5 gebruik maken niet meer als geldig moet beschouwen. Zoiets bestaat bij mijn weten ook (nog) niet.

Kritisch is dit niet omdat je zoals al vermeld speciaal moeite moet doen om MD5 te gebruiken, wat dus niemand doet. De mensen die dat toch doen moeten daar mee ophouden. Microsoft zelf gebruikt het bij mijn weten niet, dus signatures van Microsoft misbruiken op deze manier gaat niet.

Ik denk dat Microsoft ActiveX componenten getekend heeft met MD5 Authenticode voor Internet Explrorer versies ouder dan versie 4. Vermoedelijk ondersteunen deze SHA1 niet.

Maar de certificaten gebruikt voor het signen zullen nu al vervallen zijn.

Zeer ernstig dit, hoewel het (zoals hierboven staat beschreven) dus niet perse een probleem hoeft te zijn voor het OS, leidt het in ieder geval virusscanners om de tuin. En dat zal vast eenvoudig op te lossen zijn.... voor een tweaker... maar dus niet voor de gemiddelde consument waardoor je een piek kan verwachten in botnets of andere vervelende zaken (al deze software die daarvoor nodig is kan hiermee door het systeem komen toch?).

Virusscanners om de tuin leiden heeft niks met Authenticode te maken. Ik mag hopen dat er geen scanner zo dom is om alle ondertekende bestanden automatisch als "veilig" te bestempelen -- daar is Authenticode niet voor.

Een scanner heeft zijn eigen signatures. Als die daarvoor MD5 gebruikt is het op dezelfde manier kwetsbaar als Authenticode, maar dat is een probleem van de scanner (en ook niet nieuw). De meeste scanners gebruiken naast of in plaats van hashes signatures waarin fragmenten van verdachte bestanden in opgenomen zijn om te herkennen. Die laten zich door MD5-gegoochel niet voor de gek houden, omdat ze puur zoeken op de signature van virus.exe, en niet gaan kijken of explorer.exe wel explorer.exe is.

Edit: Vroegâh was het trouwens wel zo dat virusscanners een optie hadden om van alle huidige bestanden hashes te trekken, zodat ze konden zien wanneer een bestand veranderd was (en er dus mogelijk met een virus aan geknoeid was). Maar echte virussen (die bestanden infecteren) zijn tegenwoordig zeldzaam, het zijn allemaal wormen, dus de "vertrouwde bestanden controleren op verandering" aanpak is bijna nutteloos geworden. Daarbij komt nog dat systeembestanden tegenwoordig vrij regelmatig veranderen, als gevolg van updates, dus daar zou dan ook nog rekening mee gehouden moeten worden.

[Reactie gewijzigd door MneoreJ op 20 januari 2009 13:19]

Een beveiligingsonderzoeker is erin geslaagd om executables te genereren die dezelfde handtekening hebben als officiële Windows-executables.

Dit is toch niet waar? Verderop in het stuk staat toch dat Microsoft normaal altijd SHA1 gebruikt? Dus dan zijn er toch geen officiële Windows-executables die hierdoor geraakt worden?

"Hoewel Authenticode normaal gesproken het nog veilig geachte sha1-algoritme gebruikt, heeft Microsoft ook het gebruik van md5-handtekening mogelijk gemaakt.
"

Of niet dus, beetje beter lezen....

Maar er staat dat ze dezelfde handtekening als Windows executables krijgen, terwijl die met SHA1 gesigned zijn.

MD5 signatures worden wel geaccepteerd, maar die hebben dan nog niet dezelfde handtekening.

[Reactie gewijzigd door Edmond Dantes op 20 januari 2009 11:21]

Daar staat dat Authenticode zowel SHA1 als MD5 kan gebruiken, maar er staat ook dat normaal gesproken SHA1 gebruikt wordt. Dat interpreteer ik dus als dat de officiële Windows-executables allemaal SHA1 gebruiken.

Volgens mij kijkt een user nooit na via welk algoritme een executable gesigned is hoor... Als ze een geldige signature hebben en windows meld "Signed by microsoft.com" gaat niemand verder kijken en "zal het allemaal wel goed zijn".
Ze kunnen dus wel executables signen alsof ze van microsoft komen, dus ook als ze als "officieel" moeten doorgaan.

Meer zou je ook niet hoeven te verwachten van een consument, MS brengt het signen als een veiligheidsmaatregel waardoor je vertrouwen krijgt en dit soort zaken niet ziet.

Bestandsgrootte biedt geen enkele bescherming. Bestaande collision attacks werken zelfs door 128 bytes ergens te vervangen, m.a.w. je krijgt een bestand dat precies even groot is. Je hebt maar een paar bytes nodig voor code die onbeperkte schade aan kan richten (een ander bestand downloaden en uitvoeren is genoeg, en beide functies zijn ingebouwd in Windows).

Edit: reactie op frickY.

[Reactie gewijzigd door MneoreJ op 20 januari 2009 16:37]

Inderdaad, dit is weer een beetje een storm in een glas water, het enige wat gedaan word is 128 bytes omgooien, hiermee kun je niet zomaar even een dll/exe fuctioneel aanpassen

wel waar. Er is ruimte genoeg in de header om een aantal bytes toe te voegen (zeg 128) die ervoor zorgen dat er een gelijke hashwaarde uitkomt. Blijft een redelijk karwei om uit te rekenen, maar is niet onmogelijk.

Over welk collision algoritme heb je het hier?

maakt niet uit. Het gaat om de mogelijkheid om in een executable waarden toe te voegen die ervoor zorgen dat er een gelijke uitkomst gegenereerd wordt met een willekeurig hashing algoritme.

Dus wat jij zegt is:

MD5(exe-a) = 1234

MD5(exe-b) = 1234

En er bestaat een algoritme om exe-b zo te genereren door 128 bytes van exe-a aan te passen, dat MD5(exe-b) = 1234? Ik ken alleen brute-force om dit te doen. En dat is niet realistisch.

http://www.win.tue.nl/hashclash/SoftIntCodeSign/

Inderdaad, dat kan.

[edit: Het is althans mogelijk om twee executables die wezenlijk verschillen zo aan te passen dat ze dezelfde hash genereren]

[Reactie gewijzigd door flijten op 20 januari 2009 14:40]

Nee, wat Hashclash je geeft is:

MD5(exe-a) = H

MD5(exe-b) = H

De hash is dezelfde (H), maar je kan de hash zelf niet kiezen! Je kan dus niet als voorwaarde opgeven dat H = 1234.

(Ik heb Hashclash ook zelf gebruikt).

En je hash kunnen kiezen (choosen-hash attack) is nodig om een signature te kunnen hergebruiken op je eigen executable.

Ah, I stand corrected. Ik heb de post niet goed gelezen! Mijn bedoeling was duidelijk maken dat het wel degelijk mogelijk was om twee executables dezelfde hash te laten hebben. Dat is echter niet wat de poster waarop ik reageerde tegensprak.

Dank

[edit: Ik zei dat al in de edit van de post waarop je reageert, maar dat was eerlijk gezegd meer toeval. Moet .... beter .... lezen .... ]

[Reactie gewijzigd door flijten op 20 januari 2009 14:47]

Geen probleem. Er is dan ook veel onduidelijkheid rond die MD5 collisions, veel wordt verkeerd geïnterpreteerd.

In mijn blogpost heb ik bv. nooit beweerd dat ik de signature van een executable van een andere software-maker kon overnemen. Maar zo is het wel verkeerdelijk door ZDNet geïnterpreteerd.

Dit kan dan toch eenvoudig op te lossen zijn door MD5 volledig uit te schakelen en dan alleen verder gaan met SHA1? Dit bijvoorbeeld in een update.

Of denk ik nu verkeerd?

Iets in men zegt me dat je dan wat issues kan gaan krijgen met back-wards compatiblity en dergelijke. An sich is MD5 niet slecht algoritme, maar niet een gepaste oplossing voor deze toepassing.

[...]maar niet een gepaste oplossing voor deze toepassing.

niet meer nee, ik denk niet dat ze zich een goede voorstelling van de tegenwoordige computerkracht konden doen toen het MD5 algoritme uitgevonden werdt in 1992, toen de eeste Pentiums nog verschijnen moesten.

Vanuit 1992 gerekend is de Wet van Moore aan het afzwakken. We zitten al heel lang tussen de 2Ghz en 4Ghz. In 1992 had men op basis van de Wet van Moore verwacht dat we nu in 2009 al 10Ghz+ processoren zouden hebben.

Evengoed makt dat weinig uit. MD5 heeft een paar wiskundige zwaktes, maar het is nog steeds bruikbaar. Dat wil zeggen: het kraken van MD5 is niet gratis. Een cracker gaat geen MD5 signature breken als dat verliesgevend is. Dus MD5 blijft bruikbaar voor simpele beveiliging (OV chip bijvoorbeeld, zoveel kost een kaartje ook weer niet)

Moore gaat niet over het aantal Ghz-en. Het gaat ook niet over de snelheid of transistoren in een computer of processor. Het geeft alleen het aantal processoren per virekante cm aan. Volgens mij volgen we de wet van Moore nog steeds heel goed.

Het geeft alleen het aantal processoren per virekante cm aan.

Maak daar maar transistors van

Ach, een quadcore 3 GHz is ook een 10GHz+ eigenlijk. Snelheid is nog steeds flink omhoog aan het gaan, alleen niet door de kloksnelheid omhoog te gooien. Dat stijgende aantal transistors volgens de wet van Moore wordt nu gebruikt om meerdere cores mee te bouwen (en pipelines, cache etc, in ieder geval, het stijgt nog steeds, en het wordt nog steeds sneller)

Vector processors (die waarschijnlijk ideaal zijn voor dit kraak-werk) halen tegenwoordig vaak het equivalent van meerdere tientallen GHz.

De wet van Moore is misschien nog niet zo slecht, maar wel niet helemaal correct geformuleerd (uit onwetendheid over toekomstige evoluties).