Amerikaanse overheid kiest algoritme voor sha-3-hashes
Het Amerikaanse National Institute of Standards and Technology heeft uit 64 voorgestelde algoritmes de opvolger van het sha-2-algoritme gekozen. Cryptografische hashes worden onder andere gebruikt in het webprotocol https.
Het NIST heeft een algoritme met de naam Keccak gekozen als opvolger van het sha-2-algoritme. Het algoritme is mede ontwikkeld door Joan Daemen, die ook achter de encryptiestandaard AES zat, en liet 63 concurrerende algoritmes achter zich. Vanaf nu zal Keccak ook onder de naam 'sha-3' door het leven gaan.
Sha-3 is het eerste sha-algoritme dat niet min of meer gebaseerd is op een voorganger. De zoektocht naar een nieuw algoritme begon in 2006, toen men vreesde dat het sha-2-algoritme het niet lang meer zou uithouden. De voorgangers van het algoritme waren toen immers al onveilig bevonden en sha-2 vertoonde grote gelijkenissen met zijn voorgangers, waaronder sha-0 en md5. Het nieuw gekozen algoritme is gebaseerd op een sponsconstructie.
Dat er nu een opvolger voor sha-2 is, wil niet zeggen dat het 'oude' algoritme aan de kant geschoven wordt. "Het NIST beschouwt sha-2 als veilig en geschikt voor gebruik in de praktijk", schrijft het instituut. Sha-3 is meer een soort 'verzekeringspolis' voor als sha-2 niet meer voldoet.
Cryptografische hashfuncties worden gebruikt om de validiteit van gegevens te verifiëren. Op basis van de gegevens wordt een string gegenereerd, de hash. Die hash hoort vrijwel uniek te zijn en als er ook maar één bit van een bestand of andere verzameling gegevens wordt gewijzigd, moet er een andere hash uitkomen. Op die manier kan bijvoorbeeld worden gecontroleerd of een gedownload bestand wel goed is overgekomen, maar hashing wordt ook gebruikt in ssl en pgp om te bekijken of er niet met de data is geknoeid. Ook het ondertekenen van code, zodat kan worden gecontroleerd waar deze van afkomstig is, leunt op hashing, evenals de opslag van wachtwoorden.
De aangetroffen kwetsbaarheden in sha-0, sha-1 en md5 maakten het bijvoorbeeld mogelijk om te forceren dat een bepaalde verzameling gegevens dezelfde hash heeft als een andere gegevensverzameling. Hoewel het altijd kan voorkomen dat verschillende bestanden dezelfde hash hebben, is het onwenselijk dat dit te forceren is. Dan kunnen kwaadwillenden bijvoorbeeld malware als bonafide software doen overkomen, zoals bij het Flame-virus gebeurde.
Het winnende Keccak-algoritme heeft volgens het NIST een 'elegant ontwerp'. Ook is het, als het algoritme in hardware wordt geïmplementeerd, sneller dan de vijf andere algoritmes die de finale haalden, waaronder een algoritme van beveiligingsexpert Bruce Schneier. Ook is het in hardware-implementaties sneller dan sha-2. Als Keccak in software wordt geïmplementeerd, zijn 13 cpu-cycles per verwerkte byte nodig.
Reacties (86)
Het is mooi dat de ontwikkeling op dit gebeid ook niet stilstaat.
Is het trouwens mogelijk dat de andere methode toch door bedrijven worden overgenomen om extra veilig te zijn. Ik kan me namelijk voorstellen dat de standaard een hoop meer hackpogingen te verduren krijgt en dus een grotere kans heeft om gekraakt te worden dan een onbekende maar vrijwel even goede hashtechniek. Bijvoorbeeld een (eigen) modificatie van TrueCrypt, die vast ook binnenkort met sha-3 overweg zal kunnen gaan.
Is het trouwens mogelijk dat de andere methode toch door bedrijven worden overgenomen om extra veilig te zijn. Ik kan me namelijk voorstellen dat de standaard een hoop meer hackpogingen te verduren krijgt en dus een grotere kans heeft om gekraakt te worden dan een onbekende maar vrijwel even goede hashtechniek. Bijvoorbeeld een (eigen) modificatie van TrueCrypt, die vast ook binnenkort met sha-3 overweg zal kunnen gaan.
nee is niet veiliger, heeft een stuk minder duplicates en veel meer mogelijkheden.
md5 is met een mooie rainbow table zo te achterhalen.
md5 is met een mooie rainbow table zo te achterhalen.
MD5 is toch nog steeds 128 bits.
Om een rainbow table daarvoor te maken heb je dus meer dan alle hardeschijven van de wereld nodig.
Wel zijn er manieren om collisions te vinden voor MD5.
Wanneer je voor MD5 of SHA of welk ander algoritme een rainbow table maakt zijn alle algoritmes net zo makkelijk te 'kraken', maar zodra er een salt bij zit is de mogelijkheid voor een rainbow table weg.
Om een rainbow table daarvoor te maken heb je dus meer dan alle hardeschijven van de wereld nodig.
Wel zijn er manieren om collisions te vinden voor MD5.
Wanneer je voor MD5 of SHA of welk ander algoritme een rainbow table maakt zijn alle algoritmes net zo makkelijk te 'kraken', maar zodra er een salt bij zit is de mogelijkheid voor een rainbow table weg.
grappig want er zijn zat rainbowtables waar ik bijna alle md5hashes terug kan vinden.
Natuurlijk is het wel veiliger, MD5 is 128-bits, SHA-1 is 160 bits of langer. Niet veilig, maar wel veiliger.
En SHA-2 (224 bits of langer) bevat niet alle zwakheden die SHA-1 wel bevat, daarvan kun je dus zeggen dat het significant veiliger is dan MD5; zowel qua algorithme (gebaseerd op, doch niet hetzelfde) als qua bitlengte. Maar implementatie-fouten bij crypto is schering & inslag
En SHA-2 (224 bits of langer) bevat niet alle zwakheden die SHA-1 wel bevat, daarvan kun je dus zeggen dat het significant veiliger is dan MD5; zowel qua algorithme (gebaseerd op, doch niet hetzelfde) als qua bitlengte. Maar implementatie-fouten bij crypto is schering & inslag
U snapt er niets van.SHA is niet veiliger dan MD5.
Het is wel een stuk SNELLER.
Van MD5 zijn in de praktijk al collisions te genereren. Kunt u één SHA-1 collision noemen?
Collisions zijn eigenlijk alleen gevaarlijk voor logins/wachtwoorden, als jij een md5 hash mee stuurt om data te valideren heb je niks aan die collisions...
Dat is juist DE manier om een document te vervalsen.
Je verandert iets aan de code, en gaat in een onbelangrijk deel net zo lang wijzigen tot er de zelfde hash uitkomt als bij het origineel.
Je verandert iets aan de code, en gaat in een onbelangrijk deel net zo lang wijzigen tot er de zelfde hash uitkomt als bij het origineel.
Ik dacht dat er van MD5 nog niet een specifieke hash geforceerd kan worden maar enkel een collision van 2 of meer documenten die aangepast worden.
Dus
document -> hash1
document + toevoeging1 -> hash2
document + toevoeging2 -> hash2
Dus
document -> hash1
document + toevoeging1 -> hash2
document + toevoeging2 -> hash2
Jawel; er bestaan allang tooltjes in met b.v. slechts een 'code-gap' van < 100 bytes een collection van 'hash1' te forceren, zodat: document + toevoeging1 = document + toevoeging2 + x --> hash1.
Wellicht heb je het over de toepassing van collisions in PKI en publiekelijk bekent, maar als je die limitatie even breder trekt, dan is het al tal-malen aangetoont dat ook SHA-1 collisions kent. Het is simpelwel lastiger dan voor MD5, maar niet onmogelijk.
Uiteraard kent SHA-1 collisions, dat geldt per definitie voor ieder hash algoritme.
SHA-1 wordt niet meer als duurzaam veilig beschouwd (de verwachting is dat in de nabije toekomst de benodigde rekentijd om collisions te forceren significant zal afnemen), en dus zou je altijd voor SHA-2 of 3 moeten kiezen.
Maar er zijn tot op heden nul SHA-1 collisions bekend, laat staan dat je ze al in de praktijk kunt forceren, dus in die zin is het wel degelijk veiliger (of liever gezegd minder onveilig) dan MD5.
SHA-1 wordt niet meer als duurzaam veilig beschouwd (de verwachting is dat in de nabije toekomst de benodigde rekentijd om collisions te forceren significant zal afnemen), en dus zou je altijd voor SHA-2 of 3 moeten kiezen.
Maar er zijn tot op heden nul SHA-1 collisions bekend, laat staan dat je ze al in de praktijk kunt forceren, dus in die zin is het wel degelijk veiliger (of liever gezegd minder onveilig) dan MD5.
[Reactie gewijzigd door kumquat op vrijdag 5 oktober 2012 13:29]
Hoeveel ben je bereid ervoor te betalen?
De md5 collissions zijn ook al sinds de introductie van het algoritme gegenereerd en pas afgelopen jaren publiek gemaakt.
Ondertussen hebben we wel factor 1000+ meer computational power terwijl effectief SHA natuurlijk het computational veel eenvoudiger maakt door aan het einde van het algoritme alle blokken te combineren. Per saldo heeft het niet zoveel protectiebits hoor.
Dus je kunt zelf gewoon kiezen uit de blokken en dan zelfs een 1e jaars student kan met een genetisch algoritme van 10 regels proberen die blokken zo te combineren dat er een error uit voorvloeit (error ==> een kwalijke collission - een collission hoeft nog geen probleem te betekenen namelijk).
Hiervoor hoef je geen cryptograaf te zijn!
De md5 collissions zijn ook al sinds de introductie van het algoritme gegenereerd en pas afgelopen jaren publiek gemaakt.
Ondertussen hebben we wel factor 1000+ meer computational power terwijl effectief SHA natuurlijk het computational veel eenvoudiger maakt door aan het einde van het algoritme alle blokken te combineren. Per saldo heeft het niet zoveel protectiebits hoor.
Dus je kunt zelf gewoon kiezen uit de blokken en dan zelfs een 1e jaars student kan met een genetisch algoritme van 10 regels proberen die blokken zo te combineren dat er een error uit voorvloeit (error ==> een kwalijke collission - een collission hoeft nog geen probleem te betekenen namelijk).
Hiervoor hoef je geen cryptograaf te zijn!
Die vlieger gaat voor de nieuwere algoritmes dus niet op.Hoeveel ben je bereid ervoor te betalen?
Je zult geen SHA-2 of SHA-3 collision vinden, ongeacht hoeveel je betaalt.
[Reactie gewijzigd door kumquat op vrijdag 5 oktober 2012 13:31]
Lees je eens in wat een hash doet, dat levert per definitie collisions op. Het is enkel maar de vraag wanneer en onder welke omstandigheden.[...]
Je zult geen SHA-2 of SHA-3 collision vinden, ongeacht hoeveel je betaalt.
Dat noemde ik hierboven zelf ook al, dat is niet het punt. Uiteraard bestaan collisions, de vraag is of je ze in de praktijk kunt vinden of zelfs kunt genereren.Lees je eens in wat een hash doet, dat levert per definitie collisions op.
Precies, en de "wanneer" vraag is bij SHA-2 en SHA-3 eenvoudig te beantwoorden: zelfs met alle rekenkracht ter wereld gaat dat nog veel en VEEL (als in, vele triljoenen malen) langer dan dat het universum tot nu toe bestaat.Het is enkel maar de vraag wanneer en onder welke omstandigheden.
Dus vandaar dat ik zei: je zult ze niet vinden, ongeacht hoeveel je betaalt.
Los van dat SHA-X wel veiliger is dan MD5 wegens de langere hashlengte is MD5 ook razend snel.SHA is niet veiliger dan MD5.
Het is wel een stuk SNELLER.
Aan het einde van de meeste SHA algoritmes wordt snel eventjes van elk blok de zaak bij elkaar geknikkerd.
Dus dat maakt het niet VEILIG.
Maar het is wel lekker snel!
Terwijl md5 erg TRAAG is.
Bij een dergelijk algoritme is het juist niet handig als ze snel zijn? Des te makkelijker is brute-forcen.
Daar zijn de sha-hashes ook niet voor bedoeld. Dan kom je eerder uit bij bcrypt.
Volgens mij (tm) is het bij hashing juist wel een voordeel, er valt niet veel te brute forcen aan een hash.
Jawel. (Gestructureerd) Een stuk van de keyspace aflopen is ook bruteforce. Als de functie dan snel is, dan kan je sneller een gedeelte van de keyspace testen.
Vandaar dat zo'n hash een zwak wachtwoord nog steeds niet echt beveiligd, die is immers zo gevonden.
Vandaar dat zo'n hash een zwak wachtwoord nog steeds niet echt beveiligd, die is immers zo gevonden.
Bijvoorbeeld als je een ander blok data wil genereren dat dezelfde hash oplevert.
Maakt niet zo heel veel uit. Tegenwoordig kan je redelijk goedkoop rekenkracht inhuren (Amazon EC2, Azure, etc) zodat je alsnog een bruteforce aanval kan doen, zelfs als het algoritme een factor 100 trager zou zijn.
Bovendien, het sterkste algoritme kan nog steeds niet een zwak wachtwoord beveiligen. "123456" blijft onveilig, daar verandert SHA-3 niks aan.
Bovendien, het sterkste algoritme kan nog steeds niet een zwak wachtwoord beveiligen. "123456" blijft onveilig, daar verandert SHA-3 niks aan.
Toch zal het inhuren van een factor 100 meer cpu-power weer meer mensen boven het budget gaan.
Maar we zijn 256 bit keys gaan gebruiken toen 128 bit te onveilig werd, 512 toen 256 te onveilig bleek, etc. Hoe sneller je algoritme, hoe groter de key die je nodig gaat hebben.
Maar we zijn 256 bit keys gaan gebruiken toen 128 bit te onveilig werd, 512 toen 256 te onveilig bleek, etc. Hoe sneller je algoritme, hoe groter de key die je nodig gaat hebben.
Toch ben je dan een factor 100 langer bezig. Goed, dan nog is het niet echt heel erg van belang wat de kosten zijn van één keer hashen, als je het dan duurder wil maken dan hash je gewoon vaker.
Hoezo maakt dat niet uit? Je zegt nu een aantal dingen wat erg verwarrend kan zijn voor mensen.
Snel, niet snel.. ach dat maakt allemaal niet uit voor een bruteforce want dat is zinloos. Huur jij fijn maar rekenkracht, want zelfs sha-2 is in feite onmogelijk voor ons om nu te bruteforcen.
Een sneller algoritme is wenselijk voor het gebruik ervan. Als je een "traag" algoritme wilt gebruiken omdat het dan langer duurt te bruteforcen is simpelweg dom. De kracht van een algoritme moet juist op andere punten uitblinken om niet "bruteforce-baar" te zijn..
Denk dus aan collisions, state grootte, en de output grootte..
Vervolgens kan een algoritme zoals sha-3 nog steeds perfect een wachtwoord beveiligen zoals "123456". Niet slechter of beter dan een ander wachtwoord. De sterkte van het algoritme blijft hier intact, alleen de manier waarop je nu een wachtwoord kunt "kraken" is veranderd.
In feite kun je dit vergelijken met een anti inbraak deur, waarbij je de sleutel er in laat. De deur blijft even sterk, alleen de methode en de zwakte is veranderd, en dat staat 100% los van de deur (of dus het algoritme).
Een algoritme word gekraakt op zwakheden, "bugs" en ontwerpfouten. Gevolgd door nieuwe technologieën wat eventueel nieuwe zwakheden aan het licht kan brengen.
Snel, niet snel.. ach dat maakt allemaal niet uit voor een bruteforce want dat is zinloos. Huur jij fijn maar rekenkracht, want zelfs sha-2 is in feite onmogelijk voor ons om nu te bruteforcen.
Een sneller algoritme is wenselijk voor het gebruik ervan. Als je een "traag" algoritme wilt gebruiken omdat het dan langer duurt te bruteforcen is simpelweg dom. De kracht van een algoritme moet juist op andere punten uitblinken om niet "bruteforce-baar" te zijn..
Denk dus aan collisions, state grootte, en de output grootte..
Vervolgens kan een algoritme zoals sha-3 nog steeds perfect een wachtwoord beveiligen zoals "123456". Niet slechter of beter dan een ander wachtwoord. De sterkte van het algoritme blijft hier intact, alleen de manier waarop je nu een wachtwoord kunt "kraken" is veranderd.
In feite kun je dit vergelijken met een anti inbraak deur, waarbij je de sleutel er in laat. De deur blijft even sterk, alleen de methode en de zwakte is veranderd, en dat staat 100% los van de deur (of dus het algoritme).
Een algoritme word gekraakt op zwakheden, "bugs" en ontwerpfouten. Gevolgd door nieuwe technologieën wat eventueel nieuwe zwakheden aan het licht kan brengen.
hoezo? als je als kuthacker een keer een paar duizend euro overhebt ga naar Azure en je hebt zo een maand lang 60 x 8 x 1.6ghz. Kost zo'n 35euro per uur. nounou dat haal je er zo uit hoor 
De grote jongens die zich met dit bezig houden hebben het geld hier wel voor over.
De grote jongens die zich met dit bezig houden hebben het geld hier wel voor over.
Ik denk dat je je vergist in hoe bizar veel rekenkracht het bruteforcen van één SHA-2 hash kost.
Met alle rekenkracht op aarde zou dat héél erg veel langer duren dan het universum tot nu toe bestaat. Zelfs voor een 256-bit hash al. Laat staan een 512-bit hash.
Een factor honderd, of een factor duizend, of een factor miljard, is hierin werkelijk totaal onbetekenende peanuts.
Met alle rekenkracht op aarde zou dat héél erg veel langer duren dan het universum tot nu toe bestaat. Zelfs voor een 256-bit hash al. Laat staan een 512-bit hash.
Een factor honderd, of een factor duizend, of een factor miljard, is hierin werkelijk totaal onbetekenende peanuts.
Daarom zijn er dus rainbowtables.
En daarom gebruik je MD5, SHA-x niet 'rauw' als manier om passwords te hashen. Voeg een salt toe en, mits de aanvaller die niet weet, is zo'n rainbow table in één keer overbodig. Als je in je applicatie dezelfde salt gebruikt voor alle passwords, zal een aanvaller eenmalig een volledig nieuwe rainbow table aan moeten maken (voor alle passwords tussen de 4 en 20 karakters lang, ik noem maar wat). Als je in je applicatie een unieke salt gebruikt voor elke gebruiker (bijvoorbeeld iets eenvoudigs als een username) zul je voor elke gebruiker de rainbow table moeten maken, dwz alles moeten bruteforcen.
En daarnaast kun je nog bcrypt gebruiken, een encryptietechnologie die een X hoeveelheid tijd kost per iteratie; dan mag je nog zo'n snelle CPU hebben (of cluster), de totale tijd zal nog altijd belachelijk groot zijn (en de kosten belachelijk hoog; als het gaat om accounts, die zijn in de meeste gevallen geen investering van $10,000 waard, om maar een willekeurig getal te roepen).
En daarnaast kun je nog bcrypt gebruiken, een encryptietechnologie die een X hoeveelheid tijd kost per iteratie; dan mag je nog zo'n snelle CPU hebben (of cluster), de totale tijd zal nog altijd belachelijk groot zijn (en de kosten belachelijk hoog; als het gaat om accounts, die zijn in de meeste gevallen geen investering van $10,000 waard, om maar een willekeurig getal te roepen).
En daarom gebruik ik keepass, die kan random passworden genereren van elke lengte.
Als ik dus simpel alleen kleine letters gebruik en 30 tekens lang kies zijn dat 26^30 mogelijke passworden, als elke rainbowtable locatie maar 1 byte zou kosten zou dat 2558589495751899375371632258626 TeraByte kosten.
Noway dat er rainbowtables zijn van zo groot.
Als ik dus simpel alleen kleine letters gebruik en 30 tekens lang kies zijn dat 26^30 mogelijke passworden, als elke rainbowtable locatie maar 1 byte zou kosten zou dat 2558589495751899375371632258626 TeraByte kosten.
Noway dat er rainbowtables zijn van zo groot.
Als je een paar keer met je hoofd op je toetsenbord slaat heb je ook een compleet willekeurig paswoord. Heb je Keepass echt niet voor nodig.
Voor de rest zou ik zeggen "correct horse battery staple". Maar maak het jezelf vooral zo moeilijk als je zelf wilt.
Voor de rest zou ik zeggen "correct horse battery staple". Maar maak het jezelf vooral zo moeilijk als je zelf wilt.
Ik vind Keepass veel makkelijker dan correct horse battery staple of random toetsaanslagen.Als je een paar keer met je hoofd op je toetsenbord slaat heb je ook een compleet willekeurig paswoord. Heb je Keepass echt niet voor nodig.
Voor de rest zou ik zeggen "correct horse battery staple". Maar maak het jezelf vooral zo moeilijk als je zelf wilt.
Want absoluut 100% veilige passwords en ik hoef er zelf niets voor te onthouden.
Voor rainbow tables maakt het totaal niet uit hoe random je passwoord is of hoeveel verschillende tekens gebruikt.
Jouw passwoord van 30.000 verschillende tekens met speciale karakters geeft een hash die even lang en even complex is als passwoord "123456".
26^30 of 3 mogelijke passwoorden, het doet er niet toe. Het aantal mogelijke hashes (en dus de langte van jouw hash) is het enige dat er toe doet.
Als jouw passwoord wordt opgeslagen met een hash van lengte 1 en enkel kleine letters, dan heb ik een rainbow table nodig van 25 lijnen om jouw account te kraken.
En dan maakt het niet uit hoe complex jouw passwoord wel is.
De truk is namelijk dat me niet jouw passwoord gebruikt maar een ander passwoord dat dezelfde hash genereerd.
Zij loggen niet aan met jouw complex passwoord maar met een ander passwoord dat dezelfde hash genereerd. Aangezien elk passwoord, hoe complex ook, een gelijkaardige hash (dezelfde symbolen en dezelfde lengte) genereerd maakt het dan ook geen ruk uit hoe complex jouw passwoord is.
Jouw passwoord van 30.000 verschillende tekens met speciale karakters geeft een hash die even lang en even complex is als passwoord "123456".
26^30 of 3 mogelijke passwoorden, het doet er niet toe. Het aantal mogelijke hashes (en dus de langte van jouw hash) is het enige dat er toe doet.
Als jouw passwoord wordt opgeslagen met een hash van lengte 1 en enkel kleine letters, dan heb ik een rainbow table nodig van 25 lijnen om jouw account te kraken.
En dan maakt het niet uit hoe complex jouw passwoord wel is.
De truk is namelijk dat me niet jouw passwoord gebruikt maar een ander passwoord dat dezelfde hash genereerd.
Zij loggen niet aan met jouw complex passwoord maar met een ander passwoord dat dezelfde hash genereerd. Aangezien elk passwoord, hoe complex ook, een gelijkaardige hash (dezelfde symbolen en dezelfde lengte) genereerd maakt het dan ook geen ruk uit hoe complex jouw passwoord is.
Dat klopt, maar om even sha-256 als voorbeeld te nemen: de output daarvan is 64 karakters, met 16 mogelijkheden per karakter = 79.228.162.514.264.337.593.543.950.336 verschillende hashes. Ongecomprimeerd heeft dit 2.251.799.813.685.248 PetaBytes aan opslag nodig.
Dat ga je dus niet halen, dus in de praktijk bevatten rainbow tables hashes van de meest gebruikte wachtwoorden. De kans dat een 30 karakter random string uit KeePass daar tussen zit is nihil, de kans dat 123456 daar tussen zit is levensgroot. Dus is bij een rainbow attack een 30 karakter string uit KeePass een stuk veiliger dan een wachtwoord als 123456. Tenzij het wachtwoord natuurlijk gehasht is met een mooie random string, dan moet de aanvaller alsnog met wachtwoordlijsten aan de gang.
Dat ga je dus niet halen, dus in de praktijk bevatten rainbow tables hashes van de meest gebruikte wachtwoorden. De kans dat een 30 karakter random string uit KeePass daar tussen zit is nihil, de kans dat 123456 daar tussen zit is levensgroot. Dus is bij een rainbow attack een 30 karakter string uit KeePass een stuk veiliger dan een wachtwoord als 123456. Tenzij het wachtwoord natuurlijk gehasht is met een mooie random string, dan moet de aanvaller alsnog met wachtwoordlijsten aan de gang.
Of als jouw 30 karakter random string simpelweg dezelfde hash oplevert als 123456 dan zijn ze gelijkwaardig.Dat ga je dus niet halen, dus in de praktijk bevatten rainbow tables hashes van de meest gebruikte wachtwoorden. De kans dat een 30 karakter random string uit KeePass daar tussen zit is nihil, de kans dat 123456 daar tussen zit is levensgroot. Dus is bij een rainbow attack een 30 karakter string uit KeePass een stuk veiliger dan een wachtwoord als 123456.
Ja, en die kans is dus ongeveer even klein (en "klein" is nog een gigantisch understatement) als de kans dat iemand gewoon per toeval mijn password raadt.Of als jouw 30 karakter random string simpelweg dezelfde hash oplevert als 123456 dan zijn ze gelijkwaardig.
No way dude, rainbowtables helpen echt geen zak tegen fatsoenlijke passwords (zoals die van Keepass).
Volgens mij weet je niet helemaal hoe rainbowtables werken.Voor rainbow tables maakt het totaal niet uit hoe random je passwoord is of hoeveel verschillende tekens gebruikt.
Jouw passwoord van 30.000 verschillende tekens met speciale karakters geeft een hash die even lang en even complex is als passwoord "123456".
Die bevatten een aantal hashes (van veelvoorkomende passwords), niet alle hashes.
Alleen voor MD5 al (wat "slechts" 128 bit is) is het natuurlijk totaal onmogelijk om alles op te slaan. Alleen de meest voorkomende paar miljard misschien, wat een totaal verwaarloosbare miniscule fractie is van het geheel.
Dus als je password "12345" is kun je er vanuit gaan dat de hash daarvan in een rainbowtable staat. En als je password "eS2y8VJ.Hy%Pmr4eH7-Cf3g" is kun je er 100% zeker van zijn dat de hash daarvan er niet in staat.
Ik wens ze veel succes met het genereren van een willekeurig ander password dat als hash d142d7e3db64a191169939e88ab0c56d62a335be heeft. Ik hoop dat ze een paar miljard jaar de tijd hebben.Zij loggen niet aan met jouw complex passwoord maar met een ander passwoord dat dezelfde hash genereerd.
Nee die zijn er voor mensen die bekende passwords nemen (en geen salt gebruiken).Daarom zijn er dus rainbowtables.
Dan maakt het niet wat voor hash je neemt, de veiligheidsbottleneck zit dan sowieso al niet bij je hash algoritme.
Geen enkele hash kan het wachtwoord "123456" beveiligen omdat dit 1 van de eerste wachtwoorden is die je wilt testen terwijl je denkt zo dom zullen ze toch niet zijn dat ze 123456 als wachtwoord gebruikt
Nee wat, de hash geeft dan aan "error invalid input 123456 " ?
Dit, zoals ik dus in mijn verhaaltje hierboven vertelde staat dus los van de hash.
Dit, zoals ik dus in mijn verhaaltje hierboven vertelde staat dus los van de hash.
Je wilt snel kunnen encoden en decoden. Hierdoor blijft server load lager en moet de gebruiker minder lang wachten (als we uitgaan van internetapplicaties). Om bruteforcen te voorkomen moet je ervoor zorgen dat het aantal mogelijkheden quasi oneindig is, ipv het by design traag te maken.
Is zoals standaard de handrem opzetten in autos om te vermijden dat mensen te rap rijden: Nadelig voor 99% van de gebruikers om enkele mensen het moeilijker te maken.
Is zoals standaard de handrem opzetten in autos om te vermijden dat mensen te rap rijden: Nadelig voor 99% van de gebruikers om enkele mensen het moeilijker te maken.
Encoden en decoden? 
Het gaat hier over hashen, niet over encryptie.
Het gaat hier over hashen, niet over encryptie.
Volgens mij het hij het niet specifiek over hashes maar over dit soort technieken in het algemeen. Hashes zijn misschien geen encryptie, maar je moet ze nog steeds berekenen. Een snellere berekening maakt webapps sneller.
Meer nog: er zijn twee redenen om hashes te gebruiken:
1) (belangrijkste) een hash heeft geen informatie over het oorspronkelijke wachtwoord en je kan dan ook nooit een hash kraken zodat je het originele passwoord met zekerheid hebt. Deze informatie zit er namelijk gewoon niet in (het is unidirectioneel). Dit tegenover encryptie dat wel in twee richtingen werkt en dus theoretisch gekraakt kan worden tot het originele wachtwoord/boodschap.
2) Binnen een zelfde graad van veiligheid is hashing zo goed als altijd sneller dan een gelijkwaardige encryptietechniek. Maw: als je hasing kan gebruiken gebruik je dit beter dan encryptie aangezien het sneller te berekenen is en je applicatie dus sneller en toch even veilig maakt (om wille van punt 1 vaak zelfs veiliger).
1) (belangrijkste) een hash heeft geen informatie over het oorspronkelijke wachtwoord en je kan dan ook nooit een hash kraken zodat je het originele passwoord met zekerheid hebt. Deze informatie zit er namelijk gewoon niet in (het is unidirectioneel). Dit tegenover encryptie dat wel in twee richtingen werkt en dus theoretisch gekraakt kan worden tot het originele wachtwoord/boodschap.
2) Binnen een zelfde graad van veiligheid is hashing zo goed als altijd sneller dan een gelijkwaardige encryptietechniek. Maw: als je hasing kan gebruiken gebruik je dit beter dan encryptie aangezien het sneller te berekenen is en je applicatie dus sneller en toch even veilig maakt (om wille van punt 1 vaak zelfs veiliger).
Server load moet nooit meespelen bij zoiets. Het is juist de bedoeling dat je je als doel stelt dat het hashen bijvoorbeeld per gebruiker een seconde duurt. Naarmate hardware verbeterd moet je dan ook het aantal iteraties ophogen. Hier zijn dingen als bcrypt en scrypt handig voor.
Aan potentiële developers:
Ga alstjeblieft niet opnieuw het wiel uitvinden. Lees online even een implementatie van PBKDF2 , bcrypt of scrypt door en je bent al een stuk veiliger dan hash($pass) , en dan begrijp je gelijk waarom je per-user-salts wilt, een work factor belangrijk is en meer van dat soort grappen.
http://www.reddit.com/r/p...ak_wins_sha3_competition/
Aan potentiële developers:
Ga alstjeblieft niet opnieuw het wiel uitvinden. Lees online even een implementatie van PBKDF2 , bcrypt of scrypt door en je bent al een stuk veiliger dan hash($pass) , en dan begrijp je gelijk waarom je per-user-salts wilt, een work factor belangrijk is en meer van dat soort grappen.
http://www.reddit.com/r/p...ak_wins_sha3_competition/
Nee, je wil (bij encryptie) wel snel kunnen encoderen, maar maar traag kunnen decoden. Hoe groter dat verschil, hoe beter de encrypty tegen brute-forcen bestand is.
Bij het berekenen van een hash valt er niets te decoderen, dus dat wil je gewoon traag hebben.
Eigenlijk is het heel simpel: er moest een nieuw algorithme komen omdat de rekenkracht dusdanig is toegenomen dat de oude methoden zwak gaan worden. Het aantal mogelijkheden is immers beperkt door de grootte van je hash-key. Zelfs bij het ideale algoritme heb je een hash-hit in gemiddeld de helft van het aantal mogelijke hashes aan pogingen. Nou is de helft van 2^256 pogingen nogal veel (2^255 om precies te zijn), maar hoe sneller je ze kunt doen, hoe eerder je je hit hebt, oftewel, hoe groter je hash zal moeten zijn.
Bij het berekenen van een hash valt er niets te decoderen, dus dat wil je gewoon traag hebben.
Eigenlijk is het heel simpel: er moest een nieuw algorithme komen omdat de rekenkracht dusdanig is toegenomen dat de oude methoden zwak gaan worden. Het aantal mogelijkheden is immers beperkt door de grootte van je hash-key. Zelfs bij het ideale algoritme heb je een hash-hit in gemiddeld de helft van het aantal mogelijke hashes aan pogingen. Nou is de helft van 2^256 pogingen nogal veel (2^255 om precies te zijn), maar hoe sneller je ze kunt doen, hoe eerder je je hit hebt, oftewel, hoe groter je hash zal moeten zijn.
Nee, je wilt nooit traag moeten decoden. Het systeem heeft nog meer te doen dan alleen maar data ombouwen tot een ander formaat. Tegen brute force-aanvallen verdedigen zijn betere methodes voor dan het expres traag maken van je algoritme. Simpelweg 1 bit toevoegen geeft je al 2x zoveel mogelijkheden om te bruteforcen, maar maakt het decoden niet 2x zo traag.
Toch heeft Roland684 wel een punt; Het maakt natuurlijk niet uit of je die bit toevoegd aan de keylengte of aan het aantal CPU cycles dat nodig is om 1 key te hashen.
2^256 x 16 CPU cycles = 2^255 * 32 CPU cycles.
Of, in andere woorden: door het algoritme 2x zo 'complex' te maken, hoeft de keylengte 1 bit minder groot te zijn voor dezelfde mate van veiligheid (tegen bruteforcing).
Een minder complex algoritme met een langere keylength is echter altijd verkiesbaar, want deze is bij dezelfde effectieve veiligheid een stuk makkelijker te implementeren in goedkope hardware (rfid, chip-card readers, etc.), waardoor deze dus een stuk goedkoper kan blijven, terwijl tegelijkertijd het risico op implementatie-fouten wordt geminimaliseerd.
2^256 x 16 CPU cycles = 2^255 * 32 CPU cycles.
Of, in andere woorden: door het algoritme 2x zo 'complex' te maken, hoeft de keylengte 1 bit minder groot te zijn voor dezelfde mate van veiligheid (tegen bruteforcing).
Een minder complex algoritme met een langere keylength is echter altijd verkiesbaar, want deze is bij dezelfde effectieve veiligheid een stuk makkelijker te implementeren in goedkope hardware (rfid, chip-card readers, etc.), waardoor deze dus een stuk goedkoper kan blijven, terwijl tegelijkertijd het risico op implementatie-fouten wordt geminimaliseerd.
[Reactie gewijzigd door tofus op vrijdag 5 oktober 2012 08:45]
Het is juist wel handig dat ze snel zijn. Ze moeten by-design praktisch niet te brute-forcen zijn.
Snel betekent niet alleen in tijd, het heeft ook een directe impact op power consumption. In embedded systemen maakt dit wel degelijk een flink verschil. SHA-3 werd uitgezocht op performance op een 64-bit CPU. Hoewel dit ondertussen de norm in desktop-computing is geworden, is dit zeer zeker niet het geval bij alle embedded systemen die er bestaan. Denk aan een TV, een set-top box, een mobieltje, een smart meter, etc etc. Vooral op mobiele apparaten is performance en ook energieverbruik een enorm belangrijk issue. SHA-3 performt hier wezenlijk slechter omdat het voor 64-bit CPUs bedoeld is. Als je dat op een 32-bit CPU, een 16-bit CPU of een 8-bit CPU laat lopen, duurt dat eeuwig. Omgekeerd gaat het schalen veel makkelijker. Een desktop-PC heeft echt geen moeite met een 32-bit-geoptimeerde applicatie, en ook al kost het wat performance, het gaat nog steeds enorm snel.
Snel betekent niet alleen in tijd, het heeft ook een directe impact op power consumption. In embedded systemen maakt dit wel degelijk een flink verschil. SHA-3 werd uitgezocht op performance op een 64-bit CPU. Hoewel dit ondertussen de norm in desktop-computing is geworden, is dit zeer zeker niet het geval bij alle embedded systemen die er bestaan. Denk aan een TV, een set-top box, een mobieltje, een smart meter, etc etc. Vooral op mobiele apparaten is performance en ook energieverbruik een enorm belangrijk issue. SHA-3 performt hier wezenlijk slechter omdat het voor 64-bit CPUs bedoeld is. Als je dat op een 32-bit CPU, een 16-bit CPU of een 8-bit CPU laat lopen, duurt dat eeuwig. Omgekeerd gaat het schalen veel makkelijker. Een desktop-PC heeft echt geen moeite met een 32-bit-geoptimeerde applicatie, en ook al kost het wat performance, het gaat nog steeds enorm snel.
Smartphones hebben ondertussen ook 64bit cpu's hoor. En legacy apparaten kun je prima sha-2 voor gebruiken. Er is tenslotte nog geen dringende noodzaak sha-2 massaal te gaan vervangen.
Oh ja? ARM (by far het meest gebruikte platform) is nog steeds 32-bits. Noem maar eens een voorbeeld! 
SHA-3 is ook voor de toekomst bedoeld. Als je dan nu nog een algoritme kiest dat geoptimaliseerd is voor 32-bit ben je verkeerd bezig. SHA-2 volstaat voorlopig nog, ze wilden alleen het onveilig worden voor zijn. Een prima zet, lijkt me.
Deze Sha-3 standaard kan overigens, net als Sha-2, hashes van verschillende bitlengtes produceren: naar keuze 224, 256, 384, of 512 bits.
En ben je extreem paranoia, dan gebruik je een gecombineerde hash van Sha-2, de vijf laatste Sha-3 kandidaten (waaronder Skein van Bruce Schneier), en Whirlpool, die je door elkaar XORt. Dan ben je zelfs nog veilig wanneer AL deze algoritmes afzonderlijk gekraakt zouden worden (wat binnen afzienbare tijd uitgesloten is).
(gekraakt als in: binnen werkbare tijdspanne een blok data kunnen genereren met een gewenste hash)
En ben je extreem paranoia, dan gebruik je een gecombineerde hash van Sha-2, de vijf laatste Sha-3 kandidaten (waaronder Skein van Bruce Schneier), en Whirlpool, die je door elkaar XORt. Dan ben je zelfs nog veilig wanneer AL deze algoritmes afzonderlijk gekraakt zouden worden (wat binnen afzienbare tijd uitgesloten is).
(gekraakt als in: binnen werkbare tijdspanne een blok data kunnen genereren met een gewenste hash)
[Reactie gewijzigd door kumquat op donderdag 4 oktober 2012 15:46]
Alleen gaat inloggen dan zolang duren .
.Welnee, het duurt dan 0.07 microseconde om een hash te berekenen in plaats van 0.01, daar merkt niemand iets van
[Reactie gewijzigd door kumquat op donderdag 4 oktober 2012 15:54]
Een groter probleem dan die paar milliseconden om een hash te berekenen is het feit dat je zelf beveiligings software aan het schrijven bent. Iets waar je waarschijnlijk niet zo goed in bent, maar in ieder geval lang niet zo goed als de teams die libraries maken voor dit soort taken. Een library als openssl wordt door vele mensen gebruikt en dus getest en wordt als veilig beschouwd, en jouw eigen in elkaar geprakte hobbie-sha zitten misschien meer bugs in dan windows 95.
Ja, je gebruikt dan de libraries die al bestaan en gebruikt ze achter elkaar.
Dat kun je in veel programmeer en scripttalen op een regel stoppen, en zal er letterlijk geen ruimte zijn voor foutjes en bugs
Echter biedt het een verwaarloosbaar niveau aan extra beveiliging. Dus inderdaad alleen voor paranoïde personen weggelegd
Dat kun je in veel programmeer en scripttalen op een regel stoppen, en zal er letterlijk geen ruimte zijn voor foutjes en bugs
Echter biedt het een verwaarloosbaar niveau aan extra beveiliging. Dus inderdaad alleen voor paranoïde personen weggelegd
gozer waar haal jij die onzin vandaan dat md5 beter is als sha2?
md5 heeft een serieus probleem, de collisions.
sha2 heeft dit vrijwel niet aangezien de kans 2^128 kleiner.
md5 heeft een serieus probleem, de collisions.
sha2 heeft dit vrijwel niet aangezien de kans 2^128 kleiner.
[Reactie gewijzigd door batjes op donderdag 4 oktober 2012 16:51]
Moest je nu zelfs maar één bron vermelden waar je je wilde theorieën op baseert, had dit een interessante bijdrage kunnen zijn. Nu blijft het echter steken op het niveau van cafépraat. Jammer.
Heb hierboven ook al geantwoord, sorry maar je hebt echt geen flauw benul waar je het over hebt.
Is combineren beter? Prove it.
Ga snel je mond spoelen, dit is je (minstens) 3e post in dit topic met 'onzin' (sorry, maar je info is gewoon echt feitelijk onjuist) en bewijst duidelijk dat je geen kennis van crypto-principes hebt. Misschien is er namelijk wel een reden dat 'het meest basaal simpele [...] nooit gedaan wordt' ... 
Daarnaast wordt XOR in vrijwel elk block-cipher toegepast en kwadratische sommaties ook in CRC berekeningen.
Daarnaast wordt XOR in vrijwel elk block-cipher toegepast en kwadratische sommaties ook in CRC berekeningen.
2x een 64 algoritme is niet net zo veilig als 1x een 128 bit algoritme.
In jouw voorbeeld kan je bv. 2 bytes verwisselen en toch dezelfde hash krijgen.
In jouw voorbeeld kan je bv. 2 bytes verwisselen en toch dezelfde hash krijgen.
Definieer H(x) als N hashes door elkaar heen geXORd, bijvoorbeeld: Sha2(x) XOR Keccek(x) XOR Skein(x) (dus hier N=3).Is combineren beter? Prove it.
Waarom is H(x) nu veiliger dan ieder van die N hash methoden afzonderlijk?
Veiliger wil zeggen: kan niet 'gekraakt' worden, als in dat men niet binnen afzienbare tijd data kan creëren of manipuleren zodanig dat het een bepaalde gewenste hash heeft.
Als N-1 van bovenstaande N gekraakt zouden zijn (die kans is al aanmerkelijk kleiner dan dat er één gekraakt is) is H(x) nog steeds volkomen veilig, want het geheel is nog steeds 100% onmanipuleerbaar door de ongekraakte hash die er doorheen zit.
En zelfs als ze alle N gekraakt zouden zijn (waarmee ieder van die hashes afzonderlijk dus sowieso al niet meer veilig zijn) dan is dat nog steeds absoluut geen garantie dat je ook data kunt creëren of manipuleren zodat hun combinatie (geXORd) ook een bepaalde hash oplevert. De falsificatiemethode is zeer waarschijnlijk voor iedere hash verschillend, dus heb je voor de combinatie nog steeds geen methode.
QED
Iemand een idee hoeveel cpu cycles er nodig zijn voor bv md5 of sha-2 per byte?Als Keccak in software wordt geïmplementeerd, zijn 13 cpu-cycles per verwerkte byte nodig.
Voor het vergelijken wel handig...
Volgens http://www.cryptopp.com/benchmarks.html
MD5: 6.8 cycles/byte
Voor SHA-512 (SHA-2 met 512 bits hash): 17.7 cycles/byte.
Grappig dat SHA-3 sneller is.
MD5: 6.8 cycles/byte
Voor SHA-512 (SHA-2 met 512 bits hash): 17.7 cycles/byte.
Grappig dat SHA-3 sneller is.
maar er zit variatie in de hash-lengte. Het is logisch dat hoe langer de hashlengte: hoe duurder het is.Nee joh, SHA is VEEL SNELLER dan md5.
Vreemd genoeg laten mijn eigen snelle tests een raar beeld zien. MD5 (kort dus) duurt maar 0,02 seconden, maar SHA-256 0,071 seconden. SHA-512 echter, is weer sneller dan SHA-256, met 0,052 seconden.
( de test string was 'test' )
[Reactie gewijzigd door arjankoole op donderdag 4 oktober 2012 16:19]
160 bits SHA-1 kost ~5.3 CPU cycles, 128 bits MD5 kost ~6.8 CPU cycles. SHA-1 is dus sneller dan MD5 ondanks dat het 32 bits 'langer' is.
Dat SHA-256 (en langer) trager zijn dan MD-5 lijkt me nogal logisch; dat is als de brandveiligheid van een kartonnen doos vergelijken met die van een bankkluis !
Dat SHA-256 (en langer) trager zijn dan MD-5 lijkt me nogal logisch; dat is als de brandveiligheid van een kartonnen doos vergelijken met die van een bankkluis !
Dat hangt natuurlijk van het platform af, bij obscure architecturen hoeven het er niet 13 te zijn. (Daarom is een Ghz vergelijking tussen processoren niet altijd volledig). Zie hiervoor bijv: http://cr.yp.to/talks/2008.06.05/slides.pdf
Volgens mij is het 12.5 per cpu-cycle zoals ik ergens las maar goed:
SHA-512 17.7
SHA-256 15.8
MD5 6.8
http://www.cryptopp.com/benchmarks.html
SHA-512 17.7
SHA-256 15.8
MD5 6.8
http://www.cryptopp.com/benchmarks.html
Leuk om te zien dat het weer mensen uit onze kleine lage landen zijn die de absolute top vormen op gebied van encryption/hashing. Het algoritme voor AES was toch ook door een Belg bedacht, als ik mij niet vergis (de Rijndael cipher).
[Reactie gewijzigd door Spatlap op donderdag 4 oktober 2012 15:57]
Nog straffer, door 2 Belgen zelfs (Joan Daemen en Vincent Rijmen) waarvan 1 dus ook aan deze nieuwe standaard heeft geholpen. Staat ook in het stuk hierboven vermeld trouwens.
Er staat trouwens een link in het artiekel hierboven naar een interessant interview met beide (klik op de AES).
Bron
Er staat trouwens een link in het artiekel hierboven naar een interessant interview met beide (klik op de AES).
Bron
[Reactie gewijzigd door bollewolle op donderdag 4 oktober 2012 15:58]
Uit het artikel:
Ja, een Belg inderdaad.
Joan DaemenHet algoritme is mede ontwikkeld door Joan Daemen, die ook achter de encryptiestandaard AES zat
Ja, een Belg inderdaad.
Wat ik nou jammer vind is dat er straks zo goed als niets met de verliezende finalisten gedaan zal worden, terwijl er wel veel (overheids)geld en onderzoek tegenaan is gegooid.
Zou het niet beter zijn als de andere finalisten (of hun verbeterde revisies) worden aangemerkt als SHA-4, SHA-5, SHA-6 etc etc?
Zou het niet beter zijn als de andere finalisten (of hun verbeterde revisies) worden aangemerkt als SHA-4, SHA-5, SHA-6 etc etc?
Ik denk dat de volgende versies (SHA-4, enz...) pas binnen enkele jaren pas kunnen komen, nadat er zwakheden zijn ontdekt met de huidige versie (momenteel SHA-3).
Aangezien ik vermoed dat de andere algorithmes ook publiek domein zijn, zover ik weet, kunnen er wel nieuwe ideeën gemaakt worden uit de andere inzendingen.
Stiekem wil ik ook weten hoeveel van de niet gehaalde algoritmes al gekraakt zijn, of zwakke punten hebben waar men weet heeft dat ze vroeg of laat gekraakt zullen worden
Aangezien ik vermoed dat de andere algorithmes ook publiek domein zijn, zover ik weet, kunnen er wel nieuwe ideeën gemaakt worden uit de andere inzendingen.
Stiekem wil ik ook weten hoeveel van de niet gehaalde algoritmes al gekraakt zijn, of zwakke punten hebben waar men weet heeft dat ze vroeg of laat gekraakt zullen worden
Ja, laten we dat ook met voorgestelde html standaarden doen. HTML 5a 5b 5c... lekker handig/
Een niet-mainstream algorithme kan je soms nog wel terug zien in diverse tooltjes, zoals TrueCrypt bijvoorbeeld. De extra obscure keuzes zijn dan wel weer leuk en wellicht handig. Zoek maar eens naar "Adler hash"
NIST wil juist een standaard definieren die wijdverbreid ondersteunt gaat worden. Als je alle andere mogelijke varianten ook standaard gaat noemen, houd je uiteindelijk geen standaard meer over, maar domweg alle mogelijkheden.
Door te kiezen voor één duidelijke standaard kunnen software en hardware ontwikkelaars deze beter ondersteunen. Denk maar aan de snelheidswinst van het AES algoritme door de AES-NI instructieset in moderne processoren. Ook trekt je hierdoor meer onderzoekers aan die op zoek gaan naar zwakheden in het algoritme.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
