Tijdens de Crypto 2006-bijeenkomst hebben een aantal cryptografische experts een aanval op het SHA-1-algoritme gedemonstreerd. Voor hun demonstratie gebruikten ze een aangepaste versie van het algoritme, die in 64 stappen werkte, maar met enkele aanpassingen zou de techniek ook bruikbaar zijn voor de standaard 80-stapsvariant, aldus de experts. Eerder al hadden onderzoekers als de Chinees Xiaoyun Wang aangetoond dat het mogelijk is een volledig willekeurige tekenreeks te genereren die dezelfde SHA-1-hash opleverde als de originele tekst. Met de technologie van Chrisian Rechberger en Christophe De Cannière kan echter een kwart van de tekst vrij bepaald worden. Verdere optimalisaties zouden het bovendien mogelijk maken nog meer tekst te achterhalen. De aanvallen op het SHA-1-algoritme hebben hiermee hetzelfde niveau bereikt als die tegen het MD5-algoritme. Hoewel er nog aan een versie voor het, overigens meestgebruikte, algoritme met tachtig stappen gewerkt moet worden, is het volgens experts tijd om aan de implementatie van een opvolger te gaan denken.
'SHA-1 vatbaar voor krakers'
Lees meer
/i/1244721938.png?f=fpa)
Succesvolle collisionaanval SHA-1 in zicht
Nieuws van 6 oktober 2012
:strip_exif()/i/1349353521.gif?f=fpa)
Amerikaanse overheid kiest algoritme voor sha-3-hashes
Nieuws van 4 oktober 2012
/i/1247638629.png?f=fpa)
Kraak met 200 PS3's versterkt vertrouwen in elliptische-kromme-cryptografie
Nieuws van 15 juli 2009
Aanval op SHA-1 eenvoudiger gemaakt
Nieuws van 11 juni 2009
/i/1239890909.png?f=fpa)
Beveiligingsonderzoekers leggen gaten in routing-protocollen bloot
Nieuws van 16 april 2009
MD5 opnieuw onder vuur na publicatie 'collision'-code
Nieuws van 16 november 2005
'Rainbow'-database helpt bij achterhalen passwords
Nieuws van 11 november 2005
Amerika wil SHA-1-algoritme vanaf 2010 verbannen
Nieuws van 3 november 2005
Onderzoekers verbeteren SHA-1-aanval
Nieuws van 20 augustus 2005
SHA-1 gedeeltelijk gekraakt door Chinese onderzoekers
Nieuws van 17 februari 2005
Reacties (58)
Mag dit nog wel? Volgens allerlij wetjes (DMCA bv) is het toch verboden beveiligingen te proberen te omzeilen? Hoe gevaarlijk ben je bezig als je een demonstratie houdt over het proberen te kraken van een versleutelingsalgoritme?
hoe gevaarlijk ben je bezig als je het publiek en dus ook de programmeurs niet inlicht over een te kraken versleuteling
Doordat men dit weet kan men het met die kennis in het achterhoofd toepassen en kiest men bij echt belangrijke data misschien wel voor een andere manier van versleutelen.
Doordat men dit weet kan men het met die kennis in het achterhoofd toepassen en kiest men bij echt belangrijke data misschien wel voor een andere manier van versleutelen.
:strip_icc():strip_exif()/u/49396/icoon.jpg?f=community){kind=small}
En wat als het je eigen beveiliging is?
Dat moet je hopen dat je niet jezelf aanklaagt.
/u/45193/voodooless_small.png?f=community){kind=small}
Waar leven we 
Toch niet in de US..
Toch niet in de US..
:strip_exif()/u/2172/crop57acf4ac04e70.gif?f=community){kind=small}
Nee we leven niet in de US. Maar mischien wil je er wel eens op vakantie ofzo en dan kun je alsnog aangeklaagd worden voor iets wat je gedaan hebt, ook al heb je het kraken van de beveiliging niet eens op US-grondgebied gedaan.
/u/770/crop56562769ce1b9_cropped.png?f=community){kind=small}
Een versleuteling hoeft niet per se een beveiliging te zijn. Alsof je gewoon een los slot openbreekt ter demonstratie. ik denk dat men het zo ziet.
/u/4739/logo-clean-icon.png?f=community){kind=icon}
De DMCA en dat soort wetten zijn dan ook achterlijk.
Een wet die onderzoek naar zwakheden verbied?
Stel dat de spanjaarden/portugezen een wet hadden gemaakt die het verboden had om te twijfelen aan het plat zijn van de aarde.
Een wet die onderzoek naar zwakheden verbied?
Stel dat de spanjaarden/portugezen een wet hadden gemaakt die het verboden had om te twijfelen aan het plat zijn van de aarde.
Die wet was er.
Dat klopt niet; het is alleen illegaal als je de eigenaar ervan economische schade geeft. SHA-1 is een publiek algoritme. Er is dus niemand eigenaar en er is dus ook geen partij die je kan aanklagen omdat ze er economisch nadeel van hebben.Mag dit nog wel? Volgens allerlij wetjes (DMCA bv) is het toch verboden beveiligingen te proberen te omzeilen?
Daarom is deze wet (DMCA) ook zo vervelend; het maakt niet uit hoe bar slecht je algoritme is, en hoe makkelijk het te kraken is: als de eigenaar kan hardmaken dat zij er financieel nadeel van heeft, dan is de hacker de lul!
:strip_exif()/u/67831/Untitleda%252070x70.gif?f=community){kind=small}
Klopt niet helemaal.een kwart van de oorspronkelijke tekst terug achterhaald worden.
bron:
Er staat dus dat ze een collission kunnen berekenen met zelf gemaakte tekst, niet de orginele tekst terugvinden.een kwart van tekst vrijelijk geselecteerd kan worden. De overige 75% wordt bepaalt door de aanval.
Dit is dus erger want dat betekent dat je een gefingerprint document kan faken.
Of, nog erger, een virus dezelfde hash meegeven als winword.exe, zodat hash controlerende virusscanners het gewoon toestaan.
/u/13471/karnemelk.png?f=community){kind=small}
klopt SHA wordt volgens mij ook niet gebruikt om een document te encrypten maar om de authenticiteit te waarborgen. Je wil namelijk wel graag weten of het bestand met de jaarcijfers niet stiekem veranderderd is onderweg. In een aantal landen is het bijvoorbeeld niet toegestaan om verkeer te encrypten maar authenticeren mag natuurlijk wel.
Encrypten doe je met DES 3DES of AES
Authenticeren doe je met SHA of MD5
Encrypten doe je met DES 3DES of AES
Authenticeren doe je met SHA of MD5
SHA is al veel eerder gebroken. Daarom hebben we nu SHA-1.Authenticeren doe je met SHA of MD5
Overigens zijn de opvolgers SHA-256, SHA-384 en SHA-512 al voorzichtig in gebruik (er zijn nog wat compatibiliteitsproblemen tussen verschillende implementaties).
:strip_icc():strip_exif()/u/55080/el-inigualable-chuck-norris_07.jpg?f=community){kind=small}
Uhmm. niet?
Het is een demonstratie om zo de problemen naar voren te halen om het geheel veiliger te maken.
Dat is het zelfde als wanneer je een bug in os vind waarmee je bijv een buffer overload kan generenen.
Pas als je deze bug zou gaan exploiten ben je verkeerd bezig.
Dit soort demonstratie's zijn alleen maar beter.
Overigens vraag ik me nu wel af waar het einde is...?
Elk algoritme wat de mens bedenkt, kan de mens kraken...
Ik heb een keer een wachtwoord van 6 karakter in MD5 proberen te achterhalen en mijn Centrino Duo T2400 was na 14 uur nog maar bij 3 karakters...Dus zo hard loopt dat volgens mij niet echt...
Het is een demonstratie om zo de problemen naar voren te halen om het geheel veiliger te maken.
Dat is het zelfde als wanneer je een bug in os vind waarmee je bijv een buffer overload kan generenen.
Pas als je deze bug zou gaan exploiten ben je verkeerd bezig.
Dit soort demonstratie's zijn alleen maar beter.
Overigens vraag ik me nu wel af waar het einde is...?
Elk algoritme wat de mens bedenkt, kan de mens kraken...
Ik heb een keer een wachtwoord van 6 karakter in MD5 proberen te achterhalen en mijn Centrino Duo T2400 was na 14 uur nog maar bij 3 karakters...Dus zo hard loopt dat volgens mij niet echt...
edit:
Reactie op aartdeheus
Reactie op aartdeheus
Dus geef je laptop iets meer dan een volle dag de tijd, en hij kan min of meer willekeurig elk 6 karakters tellend wachtwoord van bijv. blogs (omdat die wachtwoorden meestal te vinden zijn op de webserver) kraken....
Dat vind ik genoeg reden voor angst en een extra lang wachtwoord
Dat vind ik genoeg reden voor angst en een extra lang wachtwoord
@dataghost: ik had het erover dat hij nog maar 3 van de 6 karakters na 14 uur had. Je hebt of alle karakters, of geen karakters. Dat je alleen het 1e, 3e en 6e karakter weet is echt zo'n hollywood filmpjes verhaal.
@xanderd: Valt wel mee. Er zijn twee methodes om een password te 'kraken'. Offline, waarbij je de hash moet hebben, en je net zolang gaat proberen totdat je een password hebt dat de hash matcht. Dit kan je vervolgens gebruiken om in te loggen. Deze hash achterhalen is vrij moeilijk, omdat die meestal in een of ander backendje word gecheckt tegen een waarde in een database. De tweede methode is online, waarbij je passwords gaat proberen in een inlogveld. Om een password van 6 karakters te bruteforcen, heb je 26^6 mogelijkheden. Als je ervoor zorgt dat er een login timeout van bijv. een uur optreedt na elke 1000 login pogingen duurt het een eeuwigheid voordat je dit wachtwoord achterhaald hebt.
Je angst is dus niet echt gegrond. Met een beetje verstand kun je nog steeds 99,999999999999999% van de mensen buiten houden.
@xanderd: Valt wel mee. Er zijn twee methodes om een password te 'kraken'. Offline, waarbij je de hash moet hebben, en je net zolang gaat proberen totdat je een password hebt dat de hash matcht. Dit kan je vervolgens gebruiken om in te loggen. Deze hash achterhalen is vrij moeilijk, omdat die meestal in een of ander backendje word gecheckt tegen een waarde in een database. De tweede methode is online, waarbij je passwords gaat proberen in een inlogveld. Om een password van 6 karakters te bruteforcen, heb je 26^6 mogelijkheden. Als je ervoor zorgt dat er een login timeout van bijv. een uur optreedt na elke 1000 login pogingen duurt het een eeuwigheid voordat je dit wachtwoord achterhaald hebt.
Je angst is dus niet echt gegrond. Met een beetje verstand kun je nog steeds 99,999999999999999% van de mensen buiten houden.
:strip_icc():strip_exif()/u/91018/dgtw.jpg?f=community){kind=small}
hij bedoelt dat zijn bruteforce op 3 karakters was,
a, b, c...z
aa, ab...zz
aaa
etc.
Dat noem ik een nogal slechte implementatie, aangezien eoa bruteforce die ik een tijd terug heb gebruikt binnen 923 milliseconden ergens ver weg in het alfabet zat, bij de r, op 4 letters. Ik wist toen niet hoeveel karakters het password bevatte, dat weet Fastex wel. Verder maakt dat niks uit voor de rekentijd tot aan 3 tekens.
a, b, c...z
aa, ab...zz
aaa
etc.
Dat noem ik een nogal slechte implementatie, aangezien eoa bruteforce die ik een tijd terug heb gebruikt binnen 923 milliseconden ergens ver weg in het alfabet zat, bij de r, op 4 letters. Ik wist toen niet hoeveel karakters het password bevatte, dat weet Fastex wel. Verder maakt dat niks uit voor de rekentijd tot aan 3 tekens.
Vooral de offline methode boezemt mij angst in.
Voor een studie project heb ik eens een klein blogje bijgehouden, en daarvoor gebruikte ik het pakket SimplePHPblog. Dit is zoals de naam al suggereert een recht-toe-recht-aan blog pakketje waar je alleen een PHP enabled server voor nodig hebt. Na een paar kliks kan je aan de slag met bloggen.
Het MD5 gecode pwd bestand zit ergens zeer ondiep, die had ik zo gevonden. Iedereen van mijn klas kon bij de server, hoewel ze niets konden aanpassen konden ze wel de mappen lezen. Dus het pwd bestand downloaden en decrypten zo zomaar kunnen...
Er zijn redelijk veel blogs met zon simpele opzet en bescherming... Ik schat ergens in de honderd duizend...
In ieder geval voor mij genoeg reden om lange niet-alfanumerieke wachtwoorden te nemen.
Voor een studie project heb ik eens een klein blogje bijgehouden, en daarvoor gebruikte ik het pakket SimplePHPblog. Dit is zoals de naam al suggereert een recht-toe-recht-aan blog pakketje waar je alleen een PHP enabled server voor nodig hebt. Na een paar kliks kan je aan de slag met bloggen.
Het MD5 gecode pwd bestand zit ergens zeer ondiep, die had ik zo gevonden. Iedereen van mijn klas kon bij de server, hoewel ze niets konden aanpassen konden ze wel de mappen lezen. Dus het pwd bestand downloaden en decrypten zo zomaar kunnen...
Er zijn redelijk veel blogs met zon simpele opzet en bescherming... Ik schat ergens in de honderd duizend...
In ieder geval voor mij genoeg reden om lange niet-alfanumerieke wachtwoorden te nemen.
vaak zie je dat dit soort wachtwoorden in een .php bestand in een commentaar veld staan. Een php script kan er zo wel bij, maar als je het met de browser probeert te benaderen gaat het door de php parser, en zal het commentaar verdwijnen.
Zeg euhm, hoe leuk deze discussie ook is, hij is wel nogal off-topic.
MD5 en SHA-1 hashes kun je niet "achteruit breken", dwz je kan niet op de een of andere manier een password uit een hash genereren. Je kunt het wel brute-forcen, oftewel net zolang proberen totdat je toevallig je goeie gevonden hebt.
Waar het nieuwsbericht echter over gaat, is het feit dat je voor twee bestanden dezelfde hash kan genereren. Een is dan hierbij het orgineel, en de ander gefabriceerd. Dat dat kan is al erg genoeg (hoort absoluut niet te kunnen), maar ze kunnen dus ook ongeveer 25% van die fabricatie een eigen invulling geven (zeer dodelijk). Hiermee kun je dus willekeurige gevens (lees: virus) doen voorkomen alof het bijvoorbeeld install_messenger.exe is, omdat deze dezelfde hash hebben.
MD5 en SHA-1 hashes kun je niet "achteruit breken", dwz je kan niet op de een of andere manier een password uit een hash genereren. Je kunt het wel brute-forcen, oftewel net zolang proberen totdat je toevallig je goeie gevonden hebt.
Waar het nieuwsbericht echter over gaat, is het feit dat je voor twee bestanden dezelfde hash kan genereren. Een is dan hierbij het orgineel, en de ander gefabriceerd. Dat dat kan is al erg genoeg (hoort absoluut niet te kunnen), maar ze kunnen dus ook ongeveer 25% van die fabricatie een eigen invulling geven (zeer dodelijk). Hiermee kun je dus willekeurige gevens (lees: virus) doen voorkomen alof het bijvoorbeeld install_messenger.exe is, omdat deze dezelfde hash hebben.
"Seperate The lock from the key"
Wat een redelijk vaak gebruikte methode is , is string concaternatie voordat je het crypt.
Mocht de php code in handen vallen van iemand, dan weten ze alleen de concat-string. Mocht de database in handen vallen, dan moeten ze sha1 hash van een string van 100 tekens ontbinden.
Deze 2 houden aardig offline hacks tegen.
Online script, gewoon voordat het wachtwoord word gecontroleerd de thread voor 3 of 4 seconden slepen. Dan word bruteforce al erg moeilijk.
Alleen sociale enginering is lastig te voorkomen, maar ja das niet de schuld van mijn implementiatie
Wat een redelijk vaak gebruikte methode is , is string concaternatie voordat je het crypt.
Mocht de php code in handen vallen van iemand, dan weten ze alleen de concat-string. Mocht de database in handen vallen, dan moeten ze sha1 hash van een string van 100 tekens ontbinden.
Deze 2 houden aardig offline hacks tegen.
Online script, gewoon voordat het wachtwoord word gecontroleerd de thread voor 3 of 4 seconden slepen. Dan word bruteforce al erg moeilijk.
Alleen sociale enginering is lastig te voorkomen, maar ja das niet de schuld van mijn implementiatie
heh, dan is je implementatie toch echt fout 
mijn oude Athlon 1400 had binnen 923 milliseconden het 4-letterig wachtwoord al gekraakt. Bij jou zou dit dus ruim langer dan 14 uur duren
Verder moet je de kracht van supercomputers/grote clusters/distributed computing _NIET_ onderschatten, daar moeten de algoritmes van tegenwoordig ook redelijk tegen bestand zijn, anders zijn ze nutteloos namelijk.
mijn oude Athlon 1400 had binnen 923 milliseconden het 4-letterig wachtwoord al gekraakt. Bij jou zou dit dus ruim langer dan 14 uur duren Verder moet je de kracht van supercomputers/grote clusters/distributed computing _NIET_ onderschatten, daar moeten de algoritmes van tegenwoordig ook redelijk tegen bestand zijn, anders zijn ze nutteloos namelijk.
Zelfs een bruteforce is oneindig-1 maal sneller dan 14 uur voor 3 karakters hoorLulkoek. Zo werkt het helemaal niet. Google maar eens op rainbowtables.
http://eprint.iacr.org/2006/105
Een gekraakt algoritme is wat anders dan brute force. SHA-1 is nu dus ook in zoverre gekraakt dat brute force niet meer nodig zou zijn.Revised version of this paper contains the appendix with the description of more tunnels. These tunnels further decrease the average time of MD5 collision to 31 seconds. On PC Intel Pentium 4 (3,2 GHz) it is 17 seconds in average.
Lulkoek. Zo werkt het helemaal niet. Google maar eens op rainbowtables.na 14 uur nog maar bij 3 karakters...
Ik heb geprobeerd een MD5 hash te decypheren door middel van brute-force. Een vriend van mij had de hash gegeven en gezegd dat het een range van minimaal 4 en maximaal 7 was. De keyspace was [a-z], [A-Z] en [0-9]. Decipheren van hashes gemaakt met 3 of 4 karakters zijn inderdaad zo gedaan. 5 karakters wordt al langer. 6 karakters begint al echt lang te duren, en hierna verder bleek brute-force toch echt niet een oplossing te zijn. ( sidenote: Je hebt inderdaad - zoals daapah onderaan zei - óf alle karakters, óf geen)
Toen zocht ik inderdaad ook naar andere manieren, en toen kwam ik op de rainbowtables + chains. Het idee hiervan is het genereren van alle mogelijke hashes in de range en keyspace die je opgeeft, zodat daarna in een erg snel tempo een hash ge-'decode' kan worden.
Nadeel is dat je een gigantische hoeveelheid data genereert (denk aan 32+ gigabyte). Voordeel is dat je hashes (MD5, SHA-1, ...) binnen een hele korte tijd gevonden heb (minder dan 10 minuten).
Toen zocht ik inderdaad ook naar andere manieren, en toen kwam ik op de rainbowtables + chains. Het idee hiervan is het genereren van alle mogelijke hashes in de range en keyspace die je opgeeft, zodat daarna in een erg snel tempo een hash ge-'decode' kan worden.
Nadeel is dat je een gigantische hoeveelheid data genereert (denk aan 32+ gigabyte). Voordeel is dat je hashes (MD5, SHA-1, ...) binnen een hele korte tijd gevonden heb (minder dan 10 minuten).
Check het boek "het juvinalis dilemma" van dan brown. daar gaat het over zo'n onkraakbare code (ok is wel fictie, maar wel vermakelijk)
http://nl.wikipedia.org/wiki/Het_Juvenalis_Dilemma
Iedere code is nog wel te kraken maar wat wil je er mee dat is het punt. En Kun je het optijd kraken. als je namelijk iets naar je bank verstuurd dan is dat ook encrypted, maar iedere zoveel minuten moet je weer opnieuw de Key gebruiken om dingen te versturen. Dus de kans dat iemand je internet monitort en kan kraken voordat de key niet meer geldig is... niet zo groot.
Zoals al genoemd werd, als de integriteit van documenten met die encryptie niet voldoende beschermt is moet er dus weer verbeterd worden. na een paar van zulke demo's kun je er donder opzeggen dat de hackers het gaan misbruiken.
http://nl.wikipedia.org/wiki/Het_Juvenalis_Dilemma
Iedere code is nog wel te kraken maar wat wil je er mee dat is het punt. En Kun je het optijd kraken. als je namelijk iets naar je bank verstuurd dan is dat ook encrypted, maar iedere zoveel minuten moet je weer opnieuw de Key gebruiken om dingen te versturen. Dus de kans dat iemand je internet monitort en kan kraken voordat de key niet meer geldig is... niet zo groot.
Zoals al genoemd werd, als de integriteit van documenten met die encryptie niet voldoende beschermt is moet er dus weer verbeterd worden. na een paar van zulke demo's kun je er donder opzeggen dat de hackers het gaan misbruiken.
Tja, dat boek heb ik gelezen maar hij heeft toch bepaalde belangrijke details mis. Zo heeft hij het steeds over 64 bits keys in pgp. Dat die gekraakt kunnen worden is evident, distributed.net kon dat ook met brute force. Maar pgp gebruikt alleen algorithmes met een key van 128 bits of meer, en die zijn echt onkraakbaar via brute force. Zo kun je bv. uitrekenen hoeveel energie je nodig hebt om alle mogelijkheden te proberen, dan kom je op getallen als "de energie die de zon in X miljoen jaar uitzend".
Er is een kans van 1 op [hoeveelheid-mogelijkheden] dat de eerste geprobeerde sleuel direct de juiste is, waarmee de cipher in ernkele miliseconden gekraakt is.
Omdat die kans zo klein is bij >128bits sleutels lijkt het misschien onmogelijk, maar de kans is er wel degelijk.
Omdat die kans zo klein is bij >128bits sleutels lijkt het misschien onmogelijk, maar de kans is er wel degelijk.
Hij heeft het ook over de octanium-processor...
Heeft iemand die al in zijn computertje zitten?
Heeft iemand die al in zijn computertje zitten?
:strip_icc():strip_exif()/u/3572/mashell%2520avatar_klein.jpg?f=community){kind=avatar}
Ja, best veel mensen. Je kent het rijtje 186,286,386,486. Daana komt Pentium (penta = 5) dus eigenlijk 586. De pentium 2 is dus de 686, de pentium 3 de 786, de pentium 4 de 868. En octa dat is 8. De octanium is dus gewoon een pentium 4. Niet alle Dan Brown puzzels en raadsels zijn moeilijk, maar onwaarschijnlijk zijn ze wel allemaal.octanium-processor... Heeft iemand die al in zijn computertje zitten?
Volgens mij wordt hier niet veel nieuws verteld...
SHA-1 is grotendeels gebaseerd op MD4 en MD5, dat MD5 niet al te veilig is wisten we ook al:
nieuws: MD5 opnieuw onder vuur na publicatie 'collision'-code
Omdat SHA-1 en MD5 in principe op eenzelfde manier werken zou je dus moeilijk kunnen zeggen dat SHA-1 veiliger is.
Het blijft tenslotte onmogelijk om van een willekeurige tekenreeks (uniek te noemen en tot 2^64 bits lang) een unieke SHA-1 hash (van 160 bits) te maken. 160 bits is tenslotte veel minder dan 2^64 bits.
Eigenlijk dus precies hetzelfde verhaal als bij MD5, gewoon zoeken totdat er een keer dezelfde hash uitkomt...
http://nl.wikipedia.org/wiki/SHA-familie
SHA-1 is grotendeels gebaseerd op MD4 en MD5, dat MD5 niet al te veilig is wisten we ook al:
nieuws: MD5 opnieuw onder vuur na publicatie 'collision'-code
Omdat SHA-1 en MD5 in principe op eenzelfde manier werken zou je dus moeilijk kunnen zeggen dat SHA-1 veiliger is.
Het blijft tenslotte onmogelijk om van een willekeurige tekenreeks (uniek te noemen en tot 2^64 bits lang) een unieke SHA-1 hash (van 160 bits) te maken. 160 bits is tenslotte veel minder dan 2^64 bits.
Eigenlijk dus precies hetzelfde verhaal als bij MD5, gewoon zoeken totdat er een keer dezelfde hash uitkomt...
http://nl.wikipedia.org/wiki/SHA-familie
Daarvoor hebben we HMAC.
Dat er colissions zijn, is evident, maar ze mogen niet optreden, dat is de hele crux.
Dat er colissions zijn, is evident, maar ze mogen niet optreden, dat is de hele crux.
Inderdaad... En dat is nu vaak wat mensen denken dat wel kan... Encryptie en Hashing zijn twee verschillende dingen... Als het wel twee kanten op kon hadden we de allerbeste compressie-tool ooit gevonden :-)Het blijft tenslotte onmogelijk om van een willekeurige tekenreeks (uniek te noemen en tot 2^64 bits lang) een unieke SHA-1 hash (van 160 bits) te maken. 160 bits is tenslotte veel minder dan 2^64 bits.
Worden SSL-certificaten niet gehashed met een SHA-1 hash?
Zou niet prettig zijn als men in staat raakt certificaten in naam van VeriSign te genereren op niet geverifiëerde domeinnamen. Dan kon phishing wel eens erg lucratief gaan worden
Zou niet prettig zijn als men in staat raakt certificaten in naam van VeriSign te genereren op niet geverifiëerde domeinnamen. Dan kon phishing wel eens erg lucratief gaan worden
Wat kost een sleutel voor een domein bij verisign? Hoeveel levert een phish-actie gemiddeld op? Zo duur zijn die sleutels echt niet, en veel checks op jouw identiteit worden er ook niet uitgevoerd.
registreer (bijv) www.abna-mro.nl, koop een verisign sleutel, en ga man-in-the-middle spelen. Geen SHA-hacks voor nodig...
registreer (bijv) www.abna-mro.nl, koop een verisign sleutel, en ga man-in-the-middle spelen. Geen SHA-hacks voor nodig...
Ik doelde meer op het kunnen maken van een eigen abn-amro.nl certificaat en met wat vieze DNS truukjes het verkeer naar je eigen server krigjen. Dan is het met geen mogelijkheid meer te zien of je op een autentieke of 'phising' server zit.
Dit toont maar weer aan hoe relatief computerbeveiliging is.
Dat is de eerste regel bij cryptografie. Bij voldoende rekenkracht is alles te kraken.
Cryptografie is ook niets meer dan een hele moeilijke som voor een computer, geen onoplosbare som.
Met een oneindig budget zou je een computer kunnen bouwen die een AES-256 of RSA-2048 gecrypt bericht binnen 60 seconden kan kraken.
EDIT: wat overigens niet hier gebeurde. Deze mannen hebben een hack gedaan in het algoritme waardoor er voorspelbare uitkomst uit komt.
Cryptografie is ook niets meer dan een hele moeilijke som voor een computer, geen onoplosbare som.
Met een oneindig budget zou je een computer kunnen bouwen die een AES-256 of RSA-2048 gecrypt bericht binnen 60 seconden kan kraken.
EDIT: wat overigens niet hier gebeurde. Deze mannen hebben een hack gedaan in het algoritme waardoor er voorspelbare uitkomst uit komt.
Niet helemaal waar, het heeft niets met computers te maken maar gewoon met de hoeveelheid data die je éxtra wilt gebruiken om iets te beveiligen. Een SHA-1 key van 30 tekens (geen idee hoe lang die dingen zijn) kan uit 16^30 combinaties bestaan. Een normaal tekstbestandje van 20 tekens kan uit 256^20 combinaties bestaan. Dat betekend dus dat hoe groter een bestandje wordt, hoe meer verschillende combinaties je ermee kunt maken en hoe groter de kans is dat de SHA-1 hash ervan overeen komt met een andere SHA-1 hash. Als ze de SHA-1 hash nou precies net zo groot zouden maken als de invoerwaarde, is de kans op een collission véle malen kleiner dan nu het geval is. Maar dat doen ze niet, want dan heb je tweemaal zoveel opslagruimte nodig voor wat je nu "onveilig" ook met 30 tekens ofzo kunt.
SHA-1 is dacht ik de beveiling in het nieuwe paspoort.
Dus wanneer komt er weer een nieuw paspoort?
Edit:
Ik weet niet zeker of deze beveiliging ook in het nederlandse paspoort zit. Het zit in elk geval WEL in het nieuwe Duitse paspoort.
bron: http://www.netkwesties.nl/editie138/artikel1.html
Verder ergens gevonden dat de beveiling in het nederlandse paspoort EAL4+ is. Ik heb daar alleen nog nooit van gehoord. Iemand meer info?
Dus wanneer komt er weer een nieuw paspoort?
Edit:
Ik weet niet zeker of deze beveiliging ook in het nederlandse paspoort zit. Het zit in elk geval WEL in het nieuwe Duitse paspoort.
bron: http://www.netkwesties.nl/editie138/artikel1.html
Verder ergens gevonden dat de beveiling in het nederlandse paspoort EAL4+ is. Ik heb daar alleen nog nooit van gehoord. Iemand meer info?
Ik hoop dat je het mis hebt, want SHA-1 is theoretisch al een tijdje niet meer veilig. (ergens begin deze eeuw was het verlopen).
:strip_icc():strip_exif()/u/20383/crop57de62db41c81.jpeg?f=community){kind=small}
Het is nog steeds een sterk versimpelde versie van het algoritme. Daarbij is het een collision-attack en geen preimage attack zoals gesuggereerd wordt. Het is inderdaad wel tijd om SHA-1 uit te faseren maar alle huidige hashes, en die van de nabije toekomst, zijn nog wel veilig en betrouwbaar.
Ik mis in het artikel en ook in de bron een beetje het aantal operaties dat ze nodig hebben gehad. is dat nog steeds 2^69? Dat zou me nl compleet niet ongerust maken.
(De veiligheidsproblemen die andere tweakers in deze thread posten zijn een kwestie van je passwords op de juiste plaats opslaan en die passwords lang genoeg kiezen.)
Ik mis in het artikel en ook in de bron een beetje het aantal operaties dat ze nodig hebben gehad. is dat nog steeds 2^69? Dat zou me nl compleet niet ongerust maken.
(De veiligheidsproblemen die andere tweakers in deze thread posten zijn een kwestie van je passwords op de juiste plaats opslaan en die passwords lang genoeg kiezen.)
Wat ik me nu af vraag, zou het niet slim zijn 2 of 3 technieken te combineren. Dus b.v. ondertekenen met MD5 en SHA1. Ze zijn dan wel beide te 'kraken', maar aangezien ze andere formules gebruiken lijkt het me een stuk lastiger 2 vervalsingen te maken die beide weer de correcte waarde geven.
@vortexwd
Inderdaad, want deze collisions maken allemaal gebruik van een soort gaten, die door het algoritme word overgeslagen. Bij SHA-1 ligt dat gat compleet anders dan bij MD5.
Een bestand dat een MD5 collision oplevert levert dus nooit dezelfde collision op in SHA-1 en andersom.
SHA-1 is trouwens al 13 jaar oud, dus zo verbazingwekkend is het nu ook weer niet.
Voor de zekerheid kan je Whirlpool, of Tiger2 gebruiken, die zijn vrij recent, en ook in theorie nog niet gekraakt.
linkje met alle hash algoritmes, en hun mogelijke zwakheden:
http://paginas.terra.com....aulobarreto/hflounge.html
Inderdaad, want deze collisions maken allemaal gebruik van een soort gaten, die door het algoritme word overgeslagen. Bij SHA-1 ligt dat gat compleet anders dan bij MD5.
Een bestand dat een MD5 collision oplevert levert dus nooit dezelfde collision op in SHA-1 en andersom.
SHA-1 is trouwens al 13 jaar oud, dus zo verbazingwekkend is het nu ook weer niet.
Voor de zekerheid kan je Whirlpool, of Tiger2 gebruiken, die zijn vrij recent, en ook in theorie nog niet gekraakt.
linkje met alle hash algoritmes, en hun mogelijke zwakheden:
http://paginas.terra.com....aulobarreto/hflounge.html
Net zoals de kans heel klein is dat je 2 reeksen met dezelfde SHA1 of MD5 vind, is er nog altijd een kans dat je een reeks vind met dezelfde SHA1 en MD5. Bovendien wordt je key 2 keer zo breed, dan kan je beter een grotere/nieuwer SHA key gebruiken.
/u/1401/haroid_icon_60x60.png?f=community){kind=icon}
Over het algemeen leidt het combineren van hashing of encryptie algoritmes tot minder veilige situaties, terwijl mensen denken dat het veiliger wordt.
Al zou het veiliger worden, dan wordt het "maar" 2x zo veilig (op z'n best). Dat lijkt wellicht veel, maar dat is helemaal niet veel. Sterker nog, het is verwaarloosbaar. (onkraakbaar * 2 = (nog steeds) onkraakbaar en kraakbaar * 2 = (nog steeds) kraakbaar Dan kan je beter overstappen over een ander algoritme.
Het voornaamste nadeel van het combineren van hashes of encryptie algoritmes is dat hierdoor wellicht random patronen ineens niet meer random worden, waardoor crypt-analyse ineens heel makkelijk zou kunnen worden, waardoor het resultaat makkelijker te kraken is.
Al zou het veiliger worden, dan wordt het "maar" 2x zo veilig (op z'n best). Dat lijkt wellicht veel, maar dat is helemaal niet veel. Sterker nog, het is verwaarloosbaar. (onkraakbaar * 2 = (nog steeds) onkraakbaar en kraakbaar * 2 = (nog steeds) kraakbaar Dan kan je beter overstappen over een ander algoritme.
Het voornaamste nadeel van het combineren van hashes of encryptie algoritmes is dat hierdoor wellicht random patronen ineens niet meer random worden, waardoor crypt-analyse ineens heel makkelijk zou kunnen worden, waardoor het resultaat makkelijker te kraken is.
Da's natuurlijk onzin: als nog eens versleutelen onveilig zou zijn is het voor iemand die je encryptie wil breken natuurlijk makkelijk om het document nog eens te versleutelen.
Wat je misschien bedoeld is dat het 2 maal versleutelen met dezelfde sleutel onveiliger kan uitpakken. Dat moet je dan dus ook niet doen.
Wat je misschien bedoeld is dat het 2 maal versleutelen met dezelfde sleutel onveiliger kan uitpakken. Dat moet je dan dus ook niet doen.
Nee, 2 maal encrypten maakt het uiteindelijke document niet significant veiliger, dan bij 1 maal encryptie. Ook niet bij het gebruik van verschillende sleutels. Encryptie wordt meestal gebroken door zwakheden te vinden in het algoritme. Niet door de sleutel te gokken.
Dat ging 'vroeger' meer op dan nu. Er is een groot verschil tussen het 'kraken' van een algoritme dmv brute force, dwz sleutelgeneratie, of dat het dmv cryptanalyse gaat; het vinden van zwakheden of patronen. Het 'kraken' van bijv. DES is imho ook gewoon gedaan door sleutelgeneratie (dwz lomp geweld) ipv van intelligentie.
Encryptie-in-encryptie is idd niet veel veiliger, grote kans dat de ene encryptie zwaktes in de andere aan het licht brengt zelfs.
Wat wel veilig is om de integriteit van iets te bewaken is het combineren van 2 hashing algoritmes. Bedenk jij maar eens een collission tussen twee MD5 hashes waarbij het gehashte deel hetzelfde is als degene voor een collission met SHA-1.
Wat wel veilig is om de integriteit van iets te bewaken is het combineren van 2 hashing algoritmes. Bedenk jij maar eens een collission tussen twee MD5 hashes waarbij het gehashte deel hetzelfde is als degene voor een collission met SHA-1.
Op dit item kan niet meer gereageerd worden.