Amerika wil SHA-1-algoritme vanaf 2010 verbannen

Het National Institute of Standards and Technology heeft aangekondigd het SHA-1-hashalgoritme in 2010 te laten vallen. Concrete plannen zijn echter nog niet gemaakt. NIST is verantwoordelijk voor het opstellen van de standaarden voor de Amerikaanse overheid en daarmee een belangrijke factor in beslissingen van bedrijven omtrent de toepassing van technologische standaarden. Afgelopen jaar toonde een onderzoeksteam aan dat het algoritme minder veilig bleek te zijn dan gedacht. Met voldoende rekenkracht kan een aanvaller een SHA-1-hash, dat uniek zou moeten zijn voor de tekenreeks waarover het is berekend, namaken met een andere tekenreeks als bron. Hoewel de kwetsbaarheid op dit moment nog erg theoretisch is en er nog weinig praktische toepassingen beschikbaar zijn, verwacht NIST dat naarmate computers sneller en krachtiger worden, het een kwestie van tijd is voordat de eerste aanval een feit is.

Hashalgoritmen worden voornamelijk gebruikt binnen de beveiliging en authenticatie van systemen. Documenten kunnen gesigneerd en geëncodeerd worden door middel van hashes. Deze zouden uniek moeten zijn voor de tekenreeks waaruit de hash is berekend. Als er een gedeelte van die reeks wordt veranderd, geeft het algoritme een compleet ander resultaat. Hierdoor kan worden gecontroleerd of het document, bestand of datastroom niet gemodificeerd is. Omdat er toch situaties blijken te zijn waarin twee verschillende tekenreeksen toch dezelfde hashes genereren, kan deze aanname niet meer worden gedaan. Om ervoor te zorgen dat de veiligheid gewaarborgd wordt, kan NIST nu twee kanten op: het bedrijf kan een nieuw algoritme gaan adopteren als standaard of het kan het huidige algoritme versterken door langere hashes te gebruiken. De eerste oplossing heeft als nadeel dat het nieuwe algoritme eerst uitgebreid getest moet worden. De laatste oplossing heeft als probleem dat het goed mogelijk is dat het binnen afzienbare tijd ook gekraakt wordt en er weer een betere variant moet komen.

Volgens Steven Bellovin, professor Computer Sciences, zal het al met al nog wel even duren voordat de wijziging volledig wordt doorgevoerd. Oudere bestanden moeten nog steeds kunnen worden geopend en gebruikers die nog niet zijn overgestapt op het nieuwe algoritme moeten nog gewoon contact kunnen hebben met de mensen die al wel up-to-date zijn. Zeer waarschijnlijk zal het een geleidelijke overgang zijn, waarbij de nieuwe applicaties backwards compatible zijn met de oude.

Reacties (48)

[Verwijderd]

Misschien denk ik te makkelijk hoor, maar een hash bevat over het algemeen minder informatie (in bits) dan het brondbestand waarvan het gemaakt is.
Is het dan niet logisch dat meerdere verschillende brondbestanden dezelfde hash kunnen genereren?
Ik denk dat ze iets anders bedoelen dan dat.

[Twixie]

Neen, ze bedoelen niet iets anders.

Digitaal handtekenen gebruikt sleutelparen. Mijn sleutelpaar bestaat dus uit een privé sleutel die alleen ikzelf heb, en een publieke sleutel die iedereen heeft. Daar kan je dus bvb mee gaan encrypteren. Als je mij iets vertrouwelijk wil sturen, versleutel je je bericht gewoon met mijn publieke sleutel (in de praktijk is het wel nog iets complexer dmv een symmetrische sessie-sleutel) en ik ben dus de enige die het bericht kan decrypteren.

Bij handtekenen echter worden de sleutels net andersom gebruikt. Ik kan een document encrypteren met mijn privé-sleutel. Iedereen kan die vervolgens decrypteren met mijn publieke sleutel en daardoor weet ook iedereen dat het document van mij kwam (anders ging de decryptie niet lukken). Het is echter nogal onpraktisch om telkens de hele boodschap te gaan encrypteren en decrypteren, plus dat de originele boodschap niet eens leesbaar meer is. Daarom wordt een kleine bit-array geproduceerd die representatief is voor het originele bericht: de hash. Deze hash wordt dan vervolgens versleuteld. Het voordeel is dat de encryptie/decryptie vervolgens zeer snel is, en dat je het originele document behoudt (je moet dan echter wel een handvol extra bytes bijleveren als 'handtekening'). Deze hash is dus ahw een 'vingerafdruk' of DNA van het document.

Digitaal tekenen staat of valt met de gebruikte hash. Zoals je zelf al aanhaalt zijn er oneindig veel documenten die allemaal eenzelfde hash hebben. De essentie is echter dat het onrealistisch moeilijk moet zijn om twee dergelijke documenten te vinden. Als dat niet zo is, dan heb je een serieus probleem, want dan kan ik jou iets laten digitaal handtekenen (bvb een contract met een vastgestelde prijs) en achteraf claimen dat je een ánder document ondertekend hebt (dat natuurlijk in mijn voordeel is).

[Verwijderd]

SHA-1 gebruikt geen public/private key-paren, beide zijden moeten dezelfde key gebruiken. Vandaar dat het meestal in combinatie met IKE gebruikt wordt, dat automatisch, veilig en op regelmatige tijdstippen beide partijen van nieuw sleutelmateriaal voorziet.
Het grote voordeel van SHA-1 is net dat het geen private key algoritme is, alle private key schema's gebruiken grootte ordes meer aan rekenkracht dan symmetrische algoritmen en zijn eigenlijk (nog) niet geschikt voor bulk transfers.
Een typisch gebruik van SHA-1 is om elk pakket te handtekenen dat tussen 2 partijen uitgewisseld wordt.
De public/private key exchanges gaan meestal slechts eenmaal hieraan vooraf om met grotere zekerheid de identiteit van de andere partij vast te leggen (RSA, DSS, certificaten en andere off topics)

[KoKro]

Zoals Twixie al aangeeft, is SHA-1 het hash algoritme. Voor een elektronische handtekening wordt de hash van een document asymmetrisch versleuteld met een privé-sleutel, zodat iedereen die de bijbehorende publieke sleutel heeft (doorgaans via een X.509 certificaat) de handtekening kan controleren (Volgens zelfde algoritme ook de hash berekenen en vergelijken met de ontsleutelde hash uit de handtekening).

SHA en andere cryptografische hashalgoritmes zijn net als versleutelalgoritmes (symmetrisch en asymmetrisch) rekenintensief. In PKI omgevingen worden de diverse algoritmes zo efficiënt mogelijk ingezet en zodaing dat het bijvoorbeeld mogelijk is om met meerdere mensen te ondertekenen of voor meerdere ontvangers te versleutelen.

[Frank-L]

Als dat niet zo is, dan heb je een serieus probleem, want dan kan ik jou iets laten digitaal handtekenen (bvb een contract met een vastgestelde prijs) en achteraf claimen dat je een ánder document ondertekend hebt (dat natuurlijk in mijn voordeel is).

Nou, valt nog wel mee zolang die alias een betekenisloze reeks tekens is. Het wordt niet plotseling een heel ander contract of zo (dat zou extreem toevallig zijn).

[Verwijderd]

Als het maar enkele minuten duurt om een andere tekenreeks te vinden die exact dezelfde hash oplevert (zoals hierboven geoppert), kan je er wel enkele uren/dagen/weken tijd instoppen zodat je tig tekenreeksen vind die dezelfde hash opleveren.

Het toeval (wet van de grote getallen) bepaalt dat je uiteindelijk wel een tekenreeks vindt, dat een contract is waarin de voorwaarden zéér gunstig zijn voor jou.

[Verwijderd]

De combinatie plaintext+key levert inderdaad maar een relatief unieke hash op. Doordat enkel de twee partijen die over de sleutel beschikken 'makkelijk' tot die hash waarde kunnen komen, vertrouwen ze elkaar als die ontvangen hash dezelfde is als degene die berekend wordt.
Nu blijkt echter dat het eenvoudiger geworden is om te zorgen dat je zonder de key te kennen toch tot dezelfde hash kan komen, en dus kan je een van de 2 partijen laten denken dat de andere die boodschap verstuurd heeft.
Het wordt echter interessant als je voor meerdere boodschappen kan zorgen dat je dergelijke collisions genereert. Dan wordt het 'eenvoudiger' om de originele key terug te vinden, en dan kan begonnen worden om iemands identiteit over te nemen.

[The Collector]

Zover ik het hierboven lees willen ze het doen omdat twee verschillende tekenreeksen dezelfde hash genereren, dit is bijna altijd waar als tekenreeks langer is dan hash.

Is het probleem niet dat je met de hash een andere tekenreeks kunt vinden en zo het originele vervalsen? (wat dus bij MD4,MD5 ookal kan als je maar rekenkracht hebt)

[Verwijderd]

dit is bijna altijd waar als tekenreeks langer is dan hash.

Sterker nog, dit is altijd waar wanneer de hash kleiner is als de tekenreeks die gehashed wordt.

Het probleem is echter dat het algoritme in zo'n stadium gekraakt is dat er met niet al teveel rekenkracht (iets realistisch dus) een nieuwe tekenreeks met eenzelfde hash gemaakt kan worden.

Zoals eerder al gepost: MD4 en MD5 gaat het om minutenwerk met een gemiddelde PC, een netwerkje van PC's kunnen het binnen enkele seconde.

Het doel van een hash algoritme is het erg moeilijk te maken om met een realistische rekenkracht een collision te vinden. Wanneer dit korter duurt als theoretisch berekend is het algoritme gekraakt en moet je een nieuwe verzinnen.

Doordat de rekenkracht blijft groeien zul je toch iedere 5 jaar ongeveer over moeten stappen op een nieuw algoritme.

[_JGC_]

Waarom niet dit soort algoritmes combineren? Als ik de echtheid van een bestand wil waarborgen, gooi ik daar 3 dingen in:
- de md5sum van dat bestand
- de sha1sum van het bestand
- de grootte van het bestand

knappe kop die een bestand met dezelfde grootte, dezelfde md5sum en dezelfde sha1sum kan genereren

[Verwijderd]

@Thorchar,

waar haal jij dat uit dat MD5 in een paar minuten gekraakt kan worden met een gemiddelde computer?

Als ik jou de volgende md5sum geef, kan jij er dan een bijpassende string voor verzinnen?

7c0236ede04fea3f0c577de7eea51ae8

[flossed]

Tja de hash is daar om wijzingen in een document te kunnen onderkennen. Ik denk niet dat je ver komt als je bijvoorbeeld een bedrag wilt veranderen op een electronische overschrijvingsformulier op zo een wijze dat je of het bankrekeningnummer veranderd of het bedrag of de combinatie daarvan, en dat ook nog eens doen om een manier dat er dezelfde hash uitkomt.

Zelfs de MD5 is dus goed bruikbaar, de kans dat een gewijzigd document een bruikbaar document is en een zelfde hash oplevert.

[Verwijderd]

De laatste oplossing heeft als probleem dat het goed mogelijk is dat binnen afzienbare tijd ook gekraakt wordt en er weer een betere variant moet komen.

Bijkomend nadeel is waarschijnlijk dat het controleren en hashen van een bestand langer gaat duren en meer kracht nodig heeft. Dit heeft invloed op bijvoorbeeld het openen van zo'n document op een PDA.

[Madcat]

Het hele idee van hashing en encryptie is dat het encrypten snel gaat en het decrypten langzaam gaat.
Het maakt voor een PDA echt niet zo veel uit hoeveel bits De encryptie is, dit zal slechts om een fractie van een seconde gaan.

En trouwens PDA's zijn tegenwoordig ook bijna even snel als de pc's van een paar jaar terug, mijn pda heeft een cpu van 500Mhz en dat is meer dan genoeg hoor.

[Verwijderd]

De PDA RISC CPU van 500 mhz kun je natuurlijk geensinds vergelijken met een 500 mhz x86 P3...

Mhz alleen zeggen helemaal niets.

Daarnaast gaat het om hashen, niet encrypten en decrypten. Hashen gaat maar 1 kant uit. Vanuit de input naar een hash.

Wat een reader moet doen om een hash te controleren is zelf een nieuwe hash met het gebruikte algoritme te genereren. Wanneer zo'n algoritme zwaarder is zul je dat op een PDA zeker gaan merken.

[Olaf van der Spek]

Natuurlijk, een RISC zal altijd meer mips halen als een CPU zoals de Pentium 3.

Maar de implementatie van een hash algoritme zal bij een Pentium 3 veel minder instructies nodig hebben als een RISC cpu.

Beide statements zijn niet waar.

Daarnaast heb je flink wat bandbreedte en een snelle IO nodig, iets wat op een PDA ook niet aanwezig is.

Hoeveel gbyte wil je op een PDA hashen?

[Madcat]

Natuurlijk, een RISC zal altijd meer mips halen als een CPU zoals de Pentium 3.

Maar de implementatie van een hash algoritme zal bij een Pentium 3 veel minder instructies nodig hebben als een RISC cpu.

haha..Heb je enig idee wat RISC inhoud Reduced Instuction Set Computer misschien?

Daaruit blijkt dus dat als er een SHA instructie aanwezig is in de cpu, dat dat deze tig keer sneller gaat als voor de CISC p3 processor.
Voor de duidelijkheid de p3/p4/amd hebben een hele serie aan instructies, die allemaal lomp groot zijn, gemiddeld 5-7 cycles per instructie zit je al snel aan.
een arm processor heeft gemiddeld 1 a 2 cycles per instructie nodig, dat is de kracht van risc!

de vraag is meer, heeft de pda deze functie,Wat zeer waarschijnlijk niet het geval is maar dan nog.. de pda is snel genoeg om een hash uit te rekenen (niet veel meer dan een serie getallen bij elkaar optellen en vervolgens vergelijken)

Waar jij het over hebt is decoderen van een hash of het encoderen van films.. dat kan een pda niet, en daar heb je toch echt serieusere machienes voor nodig.

edit @ Thorohar:
Het encrypten is zoals ik hier al boven zei niet meer dan een paar getallen optellen en vergelijken, iets waar RISC processoren erg goed in zijn.
CISC processoren zijn gemaakt om een heleboel universele te geven, hiervan wordt 90% niet tot amper gebruikt maar dat daaraan toe.
CISC is goed als je een serie van berekeningen vaak achter elkaar uitvoerd

Bijvoorbeeld 3*3 is typisch iets wat je in een cisc processor anders uit kan rekenenen als bij een risc processor. een cisc zou dit als 1 functie uitvoeren en met het resultaat 9 komen. een risc zou dit uitrekenen als 3+3+3=9
wat voor kleine getallen misschien wel sneller is, echter voor 1237*12354 is het bij een cisc processor waarschijnlijk sneller als bij een risc, echter zal dit minder voorkomen dan 1*2 en 3*3 waarin risc weer sneller in is dan cisc.

het ene is niet altijd beter/sneller dan het andere.. het is vaak een balans waarin aannames zijn genomen om het te optimaliseren

[zytec]

Jouw RISC CPU van 500 mhz kun je natuurlijk geensinds vergelijken met een 500 mhz x86 P3...

Inderdaad, zoek 't maar even op (qua mipsen of specint benchmarks), ik ben benieuwd. Grootte kans dat je RISC van 500 MHz wint !

[Verwijderd]

Natuurlijk, een RISC zal altijd meer mips halen als een CPU zoals de Pentium 3.

Maar de implementatie van een hash algoritme zal bij een Pentium 3 veel minder instructies nodig hebben als een RISC cpu.

Ook mipsen zeggen bagger weinig over echte performance.

Het is gewoon appels met peren vergelijken.

Je kan trouwens vrij lang zoeken, er zijn namelijk geen vergelijkende benchmarks tussen een XScale CPU en een Pentium 3 mbt hash algoritmes. Daarnaast heb je flink wat bandbreedte en een snelle IO nodig, iets wat op een PDA ook niet aanwezig is.

[Verwijderd]

@Olaf:

Bedankt voor je geweldige argumentatie.

In verhouding zal een RISC systeem altijd meer MIPS (miljoen instructies per sec) halen als een CISC systeem omdat de CISC instructies veel complexer zijn. De handigheid van een RISC systeem is juist dat alle instructies erg eenvoudig zijn en dus snel uitgevoerd kunnen worden.

Je kunt een RISC en een CISC systeem bijna niet vergelijken wanneer het gaat om performance.

Ik heb het niet over gigabytes, maar datasheets van wapensystemen zijn vaak een paar honderd MB groot (inclusief 3D CAT tekeningen etc). Je wil dan wel checken of de gegevens wel kloppen en een spion niet toevallig een dodelijke bug erin heeft gezet.

De vraag is natuurlijk wie zoiets op een PDA wil doen, maar het punt blijft dat het uitbreiden van het huidige algoritme ervoor zal zorgen dat het zwaarder wordt. Gezien we tegenwoordig alles mobiel willen hebben is dat wel iets waar je rekening mee moet houden.

(Over off-topic gesproken)

@Madcat:

Een CPU zoals de Pentium 3 is een CISC processor, oftewel Complex Instruction Set Computer. Dit betekent dat er bizar ingewikkelde maar enorm snelle instructies in zitten. Bijvoorbeeld voor het berekenen van vectoren en floating point getallen.

Een RISC processor aan de andere kant bevat alleen de basis instructies, zoals optellen, aftrekken, tellen en geheugen shift registers. Het voordeel is dat deze instructies wel doordat ze simpel zijn extreem snel uitgevoerd kunnen worden.

Om een algoritme te implementeren zal dus op een CISC systeem minder instructies nodig zijn, in een extreem geval is er zelfs maar 1 instructie nodig. Het nadeel hierbij is dat zo'n instructie vrij lang duurt.

Om hetzelfde algoritme te implementeren op een RISC systeem zijn veel meer instructies nodig, het voordeel is dat al die instructies erg snel worden uitgevoerd.

Om een hash te berekenen zul je toch het hele brondocument moeten inlezen en op die data een complex algoritme los moeten laten. Iets wat je in een RISC omgeving alleen kunt doen met heel veel instructies. Om SHA-1 te reduceren tot "een serie getallen bij elkaar optellen en vervolgens vergelijken" gaat denk ik iets te ver...

[Olaf van der Spek]

Bedankt voor je geweldige argumentatie.

Dank u.
Maar ik blijf bij mijn standpunt.
Het belangrijkste verschil tussen x86 en veel RISC ISAs is dat RISC aparte instructies heeft voor load/store en de rest van de instructies alleen op registers kunnen werken.
Bij CISC kunnen veel instructies ook direct op memory werken.
Verder is x86 two-way (a += 5) terwijl RISC vaak three-way is (a = b + 5).

[Verwijderd]

Wel behoorlijk offtopic maar goed...

Als je gaat bekijken (relatief gezien, de ene CPU is nu eenmaal sneller als de ander) hoeveel instructies per sec (binnen de CPU's eigen instructieset, of dat nu x86, ARM of C51 is) de CPU kan uitvoeren dan zal dit bij een RISC CPU hoger zijn.

Dit omdat bij een RISC CPU de instructies veel simpeler zijn en dus ook veel sneller worden uitgevoerd als de gemiddelde CISC instructie. Hierdoor heeft een RISC CPU dus een hoger aantal MIPS als een CISC CPU dat zou hebben. (Natuurlijk weer relatief gezien).

Daarnaast is het zo omdat de instructies simpeler zijn per definitie op een RISC CPU voor het hash algoritme meer instructies nodig als op een CISC CPU. Je zou een CISC CPU kunnen ontwerpen met een speciale MD5 instructie en een speciale SHA1 instructie. Het aantal instructies voor het algoritme is dan precies 1, op een RISC CPU ben al minstens 1 instructie kwijt voor het inladen van de data en dus heb je altijd per definitie meer instructies nodig.

Het is dus makkelijk te zeggen "Beide statements zijn niet waar" maar komt ook eens met een argumentatie wat de statements weerlegt.

[Verwijderd]

Maar de meeste PDA's hebben geen hardwarematige floating point, dus het is weer appels en peren. Zowiezo, omdat een ARM processor niet te vergelijken is met een x86.

Ik neem hier even zonder enige echte kennis van zaken en zonder verder onderzoek (Google) dat bij het encrypten/decrypten floating point instructies gebruikt worden.

[Olaf van der Spek]

Maar de meeste PDA's hebben geen hardwarematige floating point, dus het is weer appels en peren.

MD, SHA en RSA gebruiken geen floating point operaties, dus dat is in deze context niet relevant.

[Verwijderd]

Als de te coderen strings langer zijn dan de hash zijn er altijd verschillende strings die resulteren in dezelfde hash ongeacht het algoritme. Er is pas een probleem als er een string kan worden geconstrueert die resulteert in een vooraf bepaalde hash.

[Verwijderd]

Een wat meer technische achtergrond bij dit verhaal is te vinden in de blogs van Bruce Schneier:
http://www.schneier.com/b...5/02/cryptanalysis_o.html
Wat SHA-1 doet is plaintext+key=>Hash, waarbij die hash 160 bits lang is. Nu hoef je blijkbaar niet langer alle mogelijkheden uit te proberen om met andere plaintext+key dezelfde hash te bekomen. In praktijk moet je dus niet de sleutel kennen.

Hoewel er nog altijd veel rekenwerk nodig is, verwacht men blijkbaar wel dat mits wat extra theoretisch studiewerk, die hoeveelheid rekenwerk nog sterk kan worden teruggebracht, tot op een niveau dat het 'makkelijk' kraakbaar wordt.

[Verwijderd]

@mwvlee: Dit is wel wat ze bedoelen. Het gaat er alleen om dat een hash gekraakt wordt beschouwt, op het moment dat de tijd om een collision te vinden. Vele maal kleiner is dan de tijd om deze hash te bruteforcen(alles gewoon proberen).

En tuurlijk zijn er altijd collisions op een hash, anders zouden we een mooi jan sloot compressie algorithme hebben

[Freee!!]

Elke beveiliging die door mensen bedacht kan worden, kan uiteindelijk ook door mensen gekraakt worden.

[Madcat]

beetje een loze opmerking.
Encryptie zorgt ervoor dat je een hoop rekenkracht en een hoop tijd nodig hebt om het te decoderen.

Maar SHA1 is een redelijk kleine key (160-256 bits) en daarom redelijk onveilig
Echter een asynchrone encryptie met een sleutel van 4K bit is gewoon veilig
Als het decoderen 100 jaar duurt, dan kan je het als "veilig" beschouwen omdat de data dan niet meer van belang is. En ja dat kan zelfs met de huidige machienes en met de internet bots die je tegenwoordig ziet. Heb je enig idee hoe lang dat "koetjes project" wel niet duurde.. en dat was een kleine key!! van maar 64bits

[sid3windr]

Beetje een loze opmerking - bits hebben enkel binnen hetzelfde algoritme een betekenis.

[Olaf van der Spek]

Elke beveiliging die door mensen bedacht kan worden, kan uiteindelijk ook door mensen gekraakt worden.

Dat is niet waar, zoek eens naar "one time pad".

[Korben]

Als je een beetje goed zoekt, dan lees je dat het nadeel van een one-time pad of vernam cipher is dat het niet 'onbreekbaar' te implementeren is. In theorie is het onbreekbaar, ja. Maar om in de praktijk ten eerste al een probleem een goede 100% random generator te vinden en ten tweede om de key veilig uit te wisselen.

[Olaf van der Spek]

Documenten kunnen gesigneerd en geëncodeerd worden door middel van hashes.

Geëncodeerd?
Waarschijnlijk wordt encryptie bedoeld, maar dat is niet mogelijk met hashing.

[Verwijderd]

Volgends "mij" coderen ze het dmv hash+sleutel. Maar dat zou ik moeten nazoeken. crypt(data,filecontents_hash+sleutel) ofzo

Op de zelfde manier is MD5 onveilig, dat kan je met veel kracht nou al omzeilen.

[Verwijderd]

@Kingofdos:

MD5 kan een gemiddelde PC binnen 3 minuten ongeveer kraken. Das niet wat je noemt veel kracht.

Zie bijvoorbeeld: http://it.slashdot.org/ar...52&tid=172&tid=93&tid=218

[Gerco]

Onzin.

Die pagina gaat over een heel specifieke attack op een speciaal stukje geprepareerde data. Het is nog steeds niet mogelijk om snel een file te genereren met dezelfde hash als een andere file en tegelijk je gegenereerde file iets zinnigs te laten bevatten.

De attack bewijst dat het theoretisch mogelijk is, het is echter nog steeds niet in de buurt van makkelijk, snel of praktisch bruikbaar.

Als het echt zo makkelijk is, bewijs dat dan door een string te posten die deze hash heeft: 279a62be99783fc6fd953d48d0d5a918

Die hash heb ik zojuist gegenereerd uit een 19 karakters lange nederlandse string (om het makkelijker te maken).

[Verwijderd]

Dat artikel verwijst naar meerdere andere artikelen waarin precies wordt uitgelegd hoe je een MD5 hash kunt gebruiken om een collision te vinden.

Het wordt al iets lastiger hier ook betekenisvolle gegevens in te zetten, maar zoals daar wordt uitgelegd is dat zeker niet onmogelijk en ook niet altijd nodig.

Stel je heet MPAA en je wil een P2P netwerk om zeep helpen welke een MD5 hash gebruiken om packages te controleren?

Wat je dan doet is clients in het netwerk zetten welke complete bullshit genereren met de juiste MD5 hash, op die manier krijgen de downloaders corrupte bestanden en stoppen ze met het netwerk te gebruiken.

Daarnaast heb ik op het moment andere dingen te doen als jouw MD5 hash te hacken.
Daarnaast ben ik 1 persoon welke geen verstand heeft van het implementeren van zoiets. Een grote organisatie als de MPAA bijvoorbeeld hebben daar tijd en geld genoeg voor. Je kan er dus donder op zeggen dat zulke bedrijven zoiets wel kunnen (en voor zo ver ik weet heeft de MPAA zoiets zelfs gedaan bij KaZaa, welke geen MD5 hash gebruikte maar een iets simpelere variant)

Lees hier maar eens bijvoorbeeld:
http://www.codeproject.com/dotnet/HackingMd5.asp

Daar staan genoeg voorbeelden en links, ook van betekenisvolle gegevens welke dezelfde md5 hash hebben.

[Rey Nemaattori]

@gerco, als jij geld opzij zet om een ff een supercomputer te huren

[Gerco]

Wat je dan doet is clients in het netwerk zetten welke complete bullshit genereren met de juiste MD5 hash, op die manier krijgen de downloaders corrupte bestanden en stoppen ze met het netwerk te gebruiken.

Ik begrijp uit die pagina en de links naar de artikelen dat dat nu juist NIET mogelijk is. Het is wel mogelijk om twee files te genereren met dezelfde hash, maar uit een bestaande file + hash een nieuwe file met dezelfde hash genereren is nog steeds erg veel werk (wel minder dan vroeger overigens!).

[zeroxcool]

Hashing wordt vooral gebruikt om digitale handtekeningen uit te delen.

Wat voorkennis over RSA kun je op deze review van t.net terecht.

Stel ik wil beveiligd communiceren met 'Bob' door middel van een digitale handtekening en RSA oid. Dan hash ik mijn bericht met behulp van een hash techniek, MD5, SHA, etc. etc. Deze decrypt ik door middel van mijn privé sleutel. En mijn plain bericht plus de _gedecrypte_ hash encrypt ik met de publieke sleutel van Bob. Dat stuur ik naar Bob.

Bob decrypt het bericht met zijn privé sleutel en hasht eveneens het bericht. Nu wordt de digitale handtekening geëncrypt volgens mijn publieke sleutel en nu kijk je of deze hash en de hiervoor gegenereerde hash overeenkomt. Is dat het geval dan weet Bob zeker dat het bericht van mij afkwam, is het niet het geval dan weet Bob dat het bericht niet te vertrouwen is.

Het is dus behoorlijk gevaarlijk als je hashes zo kunt maken dat ze bij een andere tekst overeenkomen.

bomb iraq, hash=0xabc
bomb holland, hash=0xabc

Ik wil het niet meemaken :D!

[YaPP]

Dan hash ik mijn bericht met behulp van een hash techniek, MD5, SHA, etc. etc. Deze decrypt ik door middel van mijn privé sleutel.

...en daar sla je dan toch de plank mis...

SHA1 is namelijk een one-way encrypte algoritme. Je kunt het alleen gebruiken om dingen te coderen, zoals berichten of wachtwoorden. Je kunt het bericht niet decoderen, en dat is juist de kracht van SHA1.

Om daarna te controleren of een tweede bericht/wachtwoord inderdaad hetzelfde is, codeer je dat bericht met SHA1. Het resultaat gelijk zijn aan de originele SHA1 hash.

Om een bericht te versleutelen kan je bijvoorbeeld het bericht met een extra geheim stuk tekst coderen. Iedereen die ook deze tekst kent kan deze SHA1 hash ook genereren. Zo kun je voorkomen dat iemand zomaar de hash van een bericht kan nabouwen, alleen de persoon met de sleutel weet hoe de hash opgebouwd wordt.

[Twixie]

Je maakt het wel wat nodeloos complex. Je uitleg slaat immers op een gehandtekend én geëncrypteerd bericht, vandaar dat in jouw uitleg de sleutelparen van zowel Bob als jezelf nodig zijn.
Bovendien maak je het wat verwarrend door eerst te zeggen dat de hash gedecrypteerd wordt door je privé sleutel en daarna geëncrypteerd met je publieke sleutel. Dit moet natuurlijk zijn: geëncrypteerd met je privé sleutel en gedecrypteerd met de publieke sleutel (je kan niet iets decrypteren dat zelf nog niet geëncrypteerd is).
Het is niet omdat het met je privé sleutel gebeurt dat je het ineens 'decrypteren' moet noemen. Bij sleutelparen kan je dus idd met beide sleutels encrypteren. Als je met iemands publieke sleutel encrypteert dient dat voor confidentialiteit (dus wat de meesten verstaan onder encrypteren), als het met je eigen privé sleutel is, dient het voor authenticiteit (dus handtekening).

Pure handtekening is gewoonweg een hash nemen van je document en deze hash encrypteren met je privé sleutel. Eender wie kan valideren dat het bericht van jou kwam : hij decrypteert de hash terug met je publieke sleutel en berekent zelf ook de hash. Als beide hashes gelijk zijn, dan is het document authentiek.

BTW, in de praktijk heb je ook nog certificaten nodig zodat je zeker bent dat je wel met de publieke sleutel van een bepaalde persoon aan het werken bent. Een certificaat is eigenlijk niets anders dan een publieke sleutel met info over de eigenaar van die publieke sleutel, die dan digitaal getekend is door een 'autoriteit'. Als ik die autoriteit dan vertrouw weet ik zeker dat ik jouw publieke sleutel heb, zelfs al heb ik jou nog nooit ontmoet.

[Twixie]

Hij slaat de bal niet helemaal mis in de zin dat hij het had over digitale handtekeningen. En daar komt wel degelijk encryptie aan te pas.

[darkfader]

Ook wel handig dat certificaten een geldigheidsdatum hebben. 2010 lijkt me niet verkeerd want ze hebben nog maar een versnelling van 131072 keer geboekt. (publiek bekend, kan intussen meer zijn).
Ik zelf wil een SHA1 collision vinden van datablok van 20+20+20+4 bytes dat zelf ook drie hashes bevat. Hoe lang zou dit ongeveer duren? Heeft iemand toevallig sourcecode van een cracktooltje?

[Korben]

Nou heb jij het nog fout, want je geeft je publieke sleutel aan iemand anders zodat diegene dingen bestemd voor jou kan encrypten, en jij gebruikt de private key om hem daadwerkelijk te decrypten, en daarin zit hem de kracht: omdat mensen alleen aan jouw publieke key kunnen komen kunnen ze niks anders dan berichten encrypten. Zolang je jouw private key niet uitgeeft (wat ook nergens voor nodig is) ben jij de enige die kan decrypten. Daarom is voor tweeweg communicatie ook een uitwisseling van sleutels van beide kanten nodig.

[Verwijderd]

Hash moet je roken

[SuperDre]

Met voldoende rekenkracht is elke beveiliging te kraken..