Kraken sha-1 kan veel goedkoper dan gedacht met gpu's

Een team van cryptologen, waaronder de Nederlander Marc Stevens van het CWI, heeft aangetoond dat de sha-1-standaard efficiënt gebroken kan worden met gpu's. Voor een geslaagde collision-aanval zou een relatief laag bedrag van zo'n 100.000 euro volstaan, schatten ze.

Dat is aanzienlijk lager dan een paar jaar geleden werd voorspeld en de cryptoanalisten dringen er dan ook op aan de standaard versneld uit te faseren. "We hebben de binnenste laag van sha-1, de compressiefunctie, gebroken met gpu's", vertelt Stevens van de Cryptology Group Centrum Wiskunde & Informatica aan Tweakers.

Hoewel dat geen volledige aanval is, is het fundament nu onder de standaard vandaan. "Als je een collision voor sha-1 wilt vinden, moet je ook een collision voor de compressiefunctie vinden. Het is nog net iets moeilijker maar we kunnen met deze bouwstenen een volledige aanval uitwerken", zegt Stevens. De cryptoloog voerde zijn freestart collision-aanval uit in samenwerking met Pierre Karpman van Inria uit Frankrijk en Thomas Peyrin van NTU Singapore.

Sha-1 is een hashing-algoritme uit 1995 dat nog altijd veel gebruikt wordt voor de verificatie van de ssl/tls-beveiliging van onder andere online transacties en inlogverbindingen en voor het ondertekenen van software. De beveiliging berust erop dat een invoer tot een enkele specifieke uitvoer, de hash, leidt en dat het extreem lastig is een tweede invoer te vinden die tot dezelfde uitkomt leidt. De mogelijkheid tot een collision of botsing ondermijnt dat: een aanvaller kan dan de digitale handtekening op basis van zijn eigen invoer vervalsen, waardoor de integriteit van een verbinding of code niet meer gegarandeerd kan worden.

Om een botsing te berekenen is veel rekenkracht en daarmee geld nodig, maar het onderzoek van Stevens toont aan dat de kosten relatief laag kunnen blijven. Bij collision-aanvallen werden tot nu toe vooral cpu's aan het werk gezet: het rekenwerk leunde sterk op bijvoorbeeld branche instructions en andere taken waar cpu's goed in zijn. Stevens heeft echter zijn eigen aanvalsmethode uit 2013 zo geoptimaliseerd dat nu ook efficiënt van de parallelle rekenkracht van gpu's gebruikgemaakt kan worden.

Hij gebruikte bij zijn onderzoek het Kraken-cluster met 16 nodes, elk bestaande uit vier Nvidia GTX 970-kaarten, een Core i5-4460 van de Haswell-generatie en 16GB ram. "Met 512 grafische kaarten is een volledige aanval in enkele maanden uit te voeren, bij 1000 kaarten daalt dat tot enkele weken", zegt Stevens. "Zoveel onderdelen zijn nog steeds erg duur maar je kunt ook online rekenkracht van Amazons EC2 huren. Volgens onze berekening ben je dan tussen 75.000 en 120.000 dollar kwijt om de standaard in enkele maanden te kraken."

Beveiligingsexpert Bruce Schneier kwam in 2012 tot de schatting dat de kosten van een volledige sha-1 aanval dit jaar op ongeveer 700.000 dollar en in 2018 op 173.000 dollar zouden uitkomen. Dit laatste bedrag was toen volgens hem laag genoeg voor criminelen om daadwerkelijk in te zetten.

Stevens en de andere leden van het internationale team doen daarom een dringend beroep op het CA / Browser Forum om de uitgifte van sha-1-certificaten niet met nog een jaar te verlengen. Het forum stemt daar volgende week over en de discussie hierover sluit op 9 oktober. Volgens Stevens is de sfeer door zijn onderzoek al omgeslagen en is in ieder geval Google voorstander van het vervroegd staken van de ondersteuning.

Sha-1 is een 160bit-hashfunctie. Onderdeel van de sha-2-familie zijn onder andere sha-256 en sha-512. Met opvolgers sha-2 en de net nieuwe standaard sha-3 kunnen we nog jaren vooruit, verwacht Stevens: "Die bevatten fundamentele wijzigingen, respectievelijk een volledig ander ontwerp. Die standaarden bieden meer dan genoeg weerstand tegen de huidige aanvallen."

Reacties (63)

[Tweekzor]

Om dit zelf uit te schakelen in je eigen browser kun je de volgende stappen volgen:
Firefox
Nieuw tabblad -> about:config -> zoek naar "security.ssl" en zet alle 128_sha uit.

Safari
Voorkeuren -> tabblad Geavanceerd -> vink onderaan aan: “toon ontwikkel-menu in menubalk” -> ontwikkel-menu en vink aan “behandel SHA-1-certificaten als onveilig”

[Nightjar]

Thanks!! Gelijk gedaan.

[cdwave]

Alleen als je meer dan 100k op je bankrekening hebt staan natuurlijk, anders is het voor een crimineel nog niet aantrekkelijk om je te hacken.

[gekkie]

De beveiliging berust erop dat een enkele invoer, ook slechts tot een enkele specifieke uitvoer, de hash, kan leiden. De mogelijkheid tot een collision of botsing ondermijnt dat: een aanvaller kan dan de digitale handtekening op basis van zijn eigen invoer vervalsen, waardoor de integriteit van een verbinding of code niet meer gegarandeerd kan worden.

Opzich zullen er toch bij elk algoritme gegarandeerd collisions mogelijk zijn ?
(waarbij alleen de mate van moeite die je er in moet stoppen om er uberhaupt eentje te krijgen, en nog beter ook nog op basis van voor jou nuttige wijzigingen verschilt)

[Armin]

Opzich zullen er toch bij elk algoritme gegarandeerd collisions mogelijk zijn ?

Klopt, maar het gevaar is dan ook voroal bij certifciaten. Slechts één collission is meteen het einde. Tweakers meldt TLS/SSL als (data) verificatie, maar daar is SHA1 nu net nog steeds veilig. Zelfs het inmiddels afgeschafte MD5 is in combinatie met TLS/SSL geen probleem (al is het natuurlijk aan te raden iets moderners te gebruiken).

Bij TLS/SSL wordt het immers als verifciatie voor data integriteit gebruikt. Een collission zou je dan in staat stellen één paketje te vervalsen. Een gemiddelde transactie bestaat al snel uit honderden pakketjes, en je hebt nog steeds het probleem dat je de encryptie-sleutel niet kent. De mogelijkheden zijn beperkt.

Bij certificaten is het echter gevaarlijker. Als ik één stukje malware zou hebben, en via een collission deze een geldige handtekening zou kunnen geven waardoor iedere iPhone denkt dat dit een officiele iOS update is, heb je 'goud' in handen. Nu hebben update systemen van de grote fabrikanten vaak nog extra controles, maar je snapt het principe. Idem als ik TLS/SSL zou aanvallen, door niet de verificatie te vervalsen, maar de authenticatie. Ik kan dan een MITM aanval uitvoeren.

Vandaar dat het een goed idee is dat de grote techbedirjven gezamelijk besloten hebben in 2016 afscheid te nemen van SHA1 certifciaten.

EDIT: typos

[Reactie gewijzigd door Armin op 22 juli 2024 18:01]

[Jester-NL]

Vandaar dat het een goed idee is dat de grote techbedirjven gezamelijk besloten hebben in 2016 afscheid te nemen van SHA1 certifciaten.

'Beetje' jammer is wel dat veel mensen niet helemaal stil staan bij het feit dat de eerste SHA1-certificaten begin 2016 al ingetrokken zullen worden, en dat er dus nog maar drie maanden zijn om ze te vervangen. En dat is (deels) terug te voeren op waarschuwingen die Chrome al sinds april geeft. Waarschuwingen die (eigenlijk) straffeloos zijn, en dus in veel gevallen leiden tot schouderophalen en negeren... en straks moor en brand roepen omdat de site niet meer werkt.

Zou ik laag inzetten als ik beweer dat zo'n 33% van de (beveiligde) websites nog geen actie heeft ondernomen?

[Armin]

Microsoft heeft gesteld gewoon geen nieuwe certifciaten (TLS, signing, etc) te accepteren vanaf 2016. Omdat certificaten vanzelf verlopen lost het probleem zichzelf op.

Google heeft zichzelf in de voet geschoten met een onhaalbaar doel, bestaande TLS certifciaten uit te faseren ook al zijn ze nog geldig. Diezelfde websites die laks zijn met bijvoorbeeld export-grade encryptie of niet gepatchde load balancers (POODLE TLS) gaan echt niet wel hun certifciaten vervroegd uitfaseren.

Het is ook een beetje onnodig, want het is niet zo dat er nu opeens morgen een gevaar is. Een SHA1 certifciaat vervalsen zoals gebruikt voor authenticatie kan nog steeds niet binnenkort. En de gewone gebruiker snapt er niks van. De ene security warning is een echte waarschuwing en de andere is een Google stimulans.

"Boy Cry Wolf" dus ...

Zou ik laag inzetten als ik beweer dat zo'n 33% van de (beveiligde) websites nog geen actie heeft ondernomen?

Je ziet ietsje te hoog, maar niet veel. Het huidige cijfer zit rond de 28%.

Ik ben benieuwd of Google inderdaad chaos gaat veroorzaken en een rood schild afbeelden per 1-1-2016 voor die websites.

[Jester-NL]

Dat percentage is gebaseerd op de data van SSLlabs. En op basis van ongeveer 150.000 sites.
Ik denk dat het aantal certificaten toch wat hoger ligt. EN dat mensen die daar testen iets meer van SSL af weten dan de gemiddelde systeembeheerder die eens in de twee, drie jaar een nieuw certificaat moet installeren.
En dat zijn uiteindelijk ook de mensen die POODLE, BEAST en andere issues (SSL2.0) negeren (en dat meestal onbewust, want SSL is een noodzakelijk kwaad).

Misschien is intrekken nodig... is die harde les nodig.

[aadje93]

Weet niets van it* (geen opleiding in gedaan of enigr cursus) echter mijn site volledig tls gemaakt en zeer snel kwam ik ssllabs tegen, meg veel google guids binnen een uurtje van grote waarschuwingen naar volledig groen. Je hoeft echt geen systeembeheerder oid te zijn om gewoon goede beveliging op een webserver te maken.

[Jester-NL]

Daar ben ik blij om. Maar mijn reactie is gestoeld op wat ik dagelijks tegen kom...

[Rafe]

Mooi voorbeeld van een MD5 collision zijn deze twee documenten, de een aan aanbevelingsbrief, de ander een security clearance: http://web.archive.org/we...its.rub.de/MD5Collisions/ - de handtekening van de hash van het ene document is dus geldig voor de ander.

[gekkie]

Mooi voorbeeld , redelijk dichtbi met ook dezelfde filesize ..

Al zit er nog wel een redelijk verschil tussen document a en b .. of je er mensen mee kunt foppen is dus de vraag. Wat dat betreft is subtiele wijzigingen aanbrengen zonder dat de hash verandert nog steeds lastig.

[Gomez12]

Dat was dus in 2007.

En zeker met postscript of pdf kan je elke hash verkrijgen die je zo ongeveer wilt, elke verandering zorgt voor een andere hash en in een gemiddeld document kan je heel heel heel erg veel mutaties doorvoeren met het verplaatsen van 1 witte pixel (en als je het daarmee niet redt voer je 2 witte pixels in en heb je nog meer mutaties zonder dat er iets zichtbaar is etc)

Het is nog steeds niet iets wat je even in een uurtje op je thuispc doet, maar trek er een maandje voor uit of huur wat cloudcomputing en je komt echt ver.

[gekkie]

Maar dan is het dus zo dat niet de mogelijkheid tot een collision de beveiliging ondermijnt, maar de betrekkelijke eenvoud waarmee een ("nuttige") collision kan worden verkregen. Kortom ik vond het wat krom verwoord.
En idd met additionele controles en kenmerken (filesize, datastructuur, etc) valt het alsnog niet mee een "nuttige" collision te krijgen waar je ook daadwerkelijk heel veel mee kunt.
Maar goed je wilt idd een zo groot mogelijke marge aanhouden (afgewogen tegen snelheid en size van je hash) dus is het idd wel slim om er afhankelijk van je gebruiksdoel afscheid van te nemen.

[HerrPino]

Iedere hash heeft idd een oneindig aantal collisions, het is immers geen compressie.

[CAPSLOCK2000]

Collisions zal je bijna per definitie krijgen. De kunst is een collission krijgen met een specifieke checksum die je wil aanvallen.

[MaZeS]

CWI... Doet me nog steeds denken aan het oude Centrum Werk en Inkomen. Misschien niet zo handig om zo'n bestaande afkorting te kiezen?

[djiwie]

Het Centrum voor Wiskunde en Informatica bestaat al sinds 1946 (en is in 1983 CWI gaan heten, daarvoor was het Mathematisch Centrum). Het Centrum Werk en Inkomen is volgens mij pas veel later zo gaan heten, dat heette vroeger nog het Arbeidsbureau.

[Anoniem: 80466]

Volgens onze berekening ben je dan tussen 75.000 en 120.000 dollar kwijt om de standaard in enkele maanden te kraken.

Waarom niet in weken of dagen of zelf uren ?
Zo'n cloud huren is toch schaalbaar?

[ASS-Ware]

[...]

Waarom niet in weken of dagen of zelf uren ?
Zo'n cloud huren is toch schaalbaar?

Er staat " tussen 75.000 en 120.000 dollar".
Natuurlijk kun je opschalen, maar dan praat je niet meer over "tussen 75.000 en 120.000 dollar".

[Anoniem: 80466]

Maakt het qua prijs dan echt uit dan uit of je 500 cloud cores huurt voor 12 weken of bijvoorbeeld 3000 cores voor 2 weken?

[diyoo]

Zoals @Timoo.vanEsch al aangeeft is er een economische kant die een korte termijn duurder maakt. Daarnaast zit je ook nog met een technische kant.

Parallelle algoritmen schalen vaak niet lineair. De reden is dat er bij een grotere partitionering van de data meer communicatie moet plaatsvinden tussen de afzonderlijke processoren (dit is afhankelijk van het gebruikte algoritme). Daarnaast heb je te maken met de aggregatie van de data nadat de afzonderlijke berekeningen zijn afgerond. Op parallele supercomputers gaat dat bijvoorbeeld "relatief snel" met 10(tallen) Gbps interconnects. Ik kan me voorstellen dat dat in de "cloud" een stuk langzamer gaat wanneer de hoeveelheid cores wordt vergroot, doordat je over het trage Internet moet. Nu heb ik zelf geen ervaring met het vakgebied van hashes berekenen, dus wellicht dat er op dat gebied hele efficiente algoritmen bestaan en dat schalen toch vrij goed kan werken. Misschien is er iemand anders die hier meer informatie over kan verschaffen?

In nederland hebben we trouwens de DAS supercomputer staan, verdeeld over verschillende universiteiten (VU, UvA, Delft en Leiden). Als je het interessant vindt zou je de site eens kunnen bekijken: http://www.cs.vu.nl/das3/starplane.shtml

Edit: Na wat lees werk heb ik het vermoeden dat de cores geen onderlinge communicatie nodig hebben, anders dan "ik heb een collision gevonden" als het zover is. Dat zou betekenen dat er voor dit domein technisch weinig in de weg zou moeten staan om op te schalen.

[Reactie gewijzigd door diyoo op 22 juli 2024 18:01]

[Timoo.vanEsch]

Economisch bekeken: ja.
Voor het bedrijfsresultaat is 500 voor 12 weken interessant, omdat ze dan 3 maanden lang verzekerd zijn van een vaste afname.
Met 3000 cores voor 2 weken wordt de kans op een wachtlijst verzesvoudigd, terwijl het 'maar' 2 weken geld oplevert. Daarna vallen die 3000 cores weer stil en is het maar hopen of die 2500 'extra' cores kunnen worden ingezet voor diegenen in de wachtlijst.

Rule of thumb: 1 dag is relatief duur, 3 maanden relatief goedkoop. Simpelweg vanwege gegarandeerde inkomsten. Dus 3000 cores voor 2 weken zal een stuk duurder zijn dan 500 voor 12 weken.

[aadje93]

Ja, als je lang de tijd hebt kun je bij amazon zogenaamde spot instances huren die een variabele prijs hebben. Afhankelijk van de vraag stijgt of daalt de prijs, je kunt een grens instellen waarbij ze automatisch starten/stoppen. Is ideaal voor rekenwerk wat niet binnen 2 weken ofzo nodig is (denk aan onderzoek waar het tijd mag kosten) heb er zelf nooit gebruik van gemaakt. Maar het kan zeer gord lonen, dat is echt cloud compute pur sang. Capaciteit wanneer het nodig is met variabele prijzen

[CAPSLOCK2000]

Er zit natuurlijk een limiet aan hoeveel hardware er bij Amazon op voorraad is. Realistisch gezien kan je niet verwachten dat je 1 miljard cores bestellen om 1 minuut te gebruiken. Zoveel hebben ze gewoon niet. Als je meer wil is er vast wel iets te regelen met Amazon maar dan wordt het de vraag of je die hardware niet beter zelf kan kopen.

[Anoniem: 80466]

Ik vroeg ook niet om minuten. Het lijkt me echter wel relevant om bij encryptie breken te denken in dagen of uren. Daarna kan de waarde van die informatie snel afnemen.

[CAPSLOCK2000]

Ik trek de getallen ook maar uit de lucht: het punt is dat er een grens zit aan de capaciteit van Amazon.

Ik vat dit soort getallen overigens op als "werkuren" en niet zo zeer als "klokuren", net zoals mijn baas niet in mensen rekent maar in manuren en FTE's.

[FreezeXJ]

Tuurlijk, maar rond die tijd begint overhead heel belangrijk te worden, en ben je er zelf weken/maanden mee bezig om zo'n cluster goed aan te sturen. Normaal heb je weinig overhead nodig, als je thread eens per dag eens een nieuw blokje opvraagt is het al mooi (moet je maar eens doen met een paar miljoen threads, is alsnog druk) maar voor kortere totaaltijden moet je ook kortere intervallen hanteren.

Verder zijn die clusters wel groot maar niet oneindig groot. Voor een 1-week-1-collision-actie heb je meerdere clusters nodig, die je allemaal los moet aansturen. (voor GPGPU zijn hun instances max 8 GPUs groot, dus ehhh... overhead

[Durandal]

Tot de omvang van de cloud natuurlijk, en ik denk dat er bij de NSA wel een lampje gaat branden als je ineens heel amazon afhuurt.

[TheGhostInc]

[...]
Zo'n cloud huren is toch schaalbaar?

Huren? Een beetje crimineel zet zijn botnet in voor iets dergelijks.

Volgens mij zijn dit soort processen vrij redelijk 'distributed' op te zetten en een collision service kan wel eens meer geld opleveren dan DDoS-en.

[Hatsieflatsie]

De Bitcoin is toch op SHA-standaard gebouwd. Biedt deze ontdekking geen bedreiging voor Bitcoin?

[Biersteker]

Bitcoin is sha256d (double), Litecoin is Scrypt-Sha256. Er is volgens mij geen coin die sha1 gebruikt. (mag ik hopen)

Proof of Work van HashCash in 1997 trouwens wel.
https://en.bitcoin.it/wiki/Hashcash

[Reactie gewijzigd door Biersteker op 22 juli 2024 18:01]

[Anoniem: 390875]

Bitcoin is meerdere - je conclusie blijft echter staan: dit heeft geen impact op Bitcoin.

Voor het 'minen' is het sha256(sha256(header)), waarbij je niet eens alle stappen hoeft te doorlopen (aangezien het resultaat alleen maar 'laag genoeg' hoeft te zijn en dat kan je al eerder in het proces nagaan. Dit is dan al ook al erg geoptimaliseerd tot aan gespecialiseerde chips toe. Mocht hier nog een doorbraak bij plaatsvinden dan hebben ontwikkelaars al aangegeven dat ze desnoods op een ander proces over zullen stappen (jammer van de hardware en bedrijven die daarop draaien, maar het is niet anders).

Voor de omzet van een private key naar een adres is er een stap ripemd160(sha256(pubkey)), en vervolgens nog een stap sha256(sha256(1[resultaat van vorige])) waar een checksum uitrolt.
Voordat iemand een private key kan genereren voor een arbitrair adres zullen ze dus sha256, ripemd160 *en* elliptic curve cryptography moeten kraken Als die gekraakt zijn hebben we wel weer andere problemen dan alleen maar met Bitcoin.

[supersnathan94]

Dan nog. Is het hele idee van bitcoin mining niet dat je hash collisions uitrekent?

[Anoniem: 390875]

Nee, het idee van bitcoin mining is dat je een hash berekent die, omgezet naar een numeriek getal, onder een bepaalde grenswaarde (network target) valt. Vaak wordt dit gesimplificeerd voorgesteld als "een X aantal nullen vooraan".

Bij collisions gaat het om een exacte waarde - denk bijvoorbeeld aan de MD5 hash, waarbij je als malware schrijver zou proberen om bij de aangepaste versie van een bestand nutteloze data toevoegd om de MD5 van deze versie gelijk te maken aan het origineel, zodat zelfs mensen die de MD5 controleren gepakt worden.

Natuurlijk is het wel zo dat als je een kortere weg hebt gevonden om voor SHA256 een collision uit te voeren (op het moment moet dat met brute kracht en wordt algemeen gesteld dat het universum vergaat voordat je eentje - gestoeld op een goede willekeurige waarde - vindt), dat je dan ook het minen sneller zal kunnen doen. Maar nogmaals, dan hebben we wel grotere problemen want er draait ontiegelijk veel dat SHA256 gebruikt voor allerlei beveiligingsdoeleinden.

Voor minen is het probleem eigenlijk een stuk kleiner - er zijn al andere algoritmes (denk aan Scrypt bij litecoin en dogecoin, maar ook allerlei andere types in gebruik bij andere altcoins) en overschakelen is eigenlijk niet veel meer dan een paar stukjes code vervangen. Waarschijnlijk zouden ze zoiets wel via consensus mechanismes invoeren zodat niet in 1 klap alle hardware waardeloos is, maar da's een ander en langer verhaal met vooral economische prietpraat

[supersnathan94]

Aha okee nee dan zit ik fout inderdaad. Ik gebruik sha-256 zelf ook vaak om Passwords te bashen in simpele Java applicaties. Dus is het voor mij ook van belang dat het blijft werken. Anders mag ik alles gaan herschrijven. Dergelijke problemen wil je niet hebben met gevoelige data.

[PixelPhobiac]

Ter aanvulling: er wordt in Bitcoin altijd gebruik gemaakt van een dubbele hash als in sha256(sha256("")). Dit ter opvanging als SHA2 wordt gebroken.

[Jace / TBL]

Wat Kamiquasi zegt, en zelfs al was er een volledig werkende preimage attack voor Sha256, dan nog is het extreem onwaarschijnlijk dat je een input van 256 bits kunt forceren die de gewenste uitkomst heeft. En dat zou wel nodig zijn, aangezien Bitcoin een dubbele sha256 gebruikt.
Preimage attack wil zeggen dat je gegeven een hash waarde h, een input x kunt vinden zodat hash(x)=h. De extra conditie dat x dan precies 256 bits moet zijn legt er nog eens een enorme moeilijkheidsgraad bovenop.

Dus nee, deze ontdekking biedt juist kansen voor Bitcoin, omdat allerlei andere financiële systemen en protocollen wel het oudere sha1 gebruiken. Dus logischerwijs zouden gebruikers van dat soort onveilige varianten er goed aan doen om naar Bitcoin te vluchten.

[Pyrone89]

Als nu al SHA-3 er is neem ik aan dat ze daar op gaan overstappen en niet eerst op SHA-2, of zijn er belemmeringen die de tussenstap nodig maken?

[Anoniem: 390875]

SHA-2 is al veel meer onderzoek naar gedaan, terwijl SHA-3 relatief nieuw is. Dat kan je dus als voordeel zien. SHA-3 is uiteindelijk wel als vervanger voor SHA-2 bedoeld, natuurlijk.

[Dennism]

voornamelijk softwarematige belemmeringen geloof ik, nog steeds kan lang niet alle software met alle protocollen omgaan. Ik geloof dat bijv. SHA-2 ondersteuning bij Windows XP er pas vrij laat ingepatched is en zo zal er meer software (vooral oudere software) zijn die niet met SHA-2 of hoger overweg kan. Nu zal software die enkel met SHA-1 of lager overweg kan hopelijk niet veel meer voorkomen, maar ik verwacht dat gezien SHA-3 vrij nieuw is, dat een boel software daar niet mee om kan gaan. Dit zelfde geldt voor meedere protocollen op dit gebied trouwens. Wanneer je bijv. een interne PKI wil / moet opzetten voor bijv. bepaalde MS producten binnen je organisatie dan wordt op dit moment SHA-256 aangeraden als standaard, wil je ook van nieuwe protocollen gebruik kunnen maken dan wordt er bijv. aangeraden om een aparte "suite B" PKI op te zetten omdat veel software niet om kan gaan met certificaten uitgegeven met protocollen uit de "suite B".

[Reactie gewijzigd door Dennism op 22 juli 2024 18:01]

[CAPSLOCK2000]

Er is nauwelijks software die SHA-3 snapt. We zitten nog midden in de migratie naar SHA-2 en de voorgangers (MD5 en RC4) kom je ook nog steeds tegen.

[PolarBear]

Je zou 2 of 3 verschillende hash algoritmes moeten gebruiken. Dat je bij 1 hash een collision kan genereren is dan een stuk minder interessant aangezien de andere (of 2) veranderen. Dat lijkt mij de meest fail safe optie.

[Flaat]

Mooi dat er hard wordt gewerk om deze oude standaard eruit te schoppen.

Vaag dat er GTX kaarten worden gebruikt, ik dacht dat nvidia hard probeerde compute op hun Tesla kaarten te krijgen en allerlei wensenlijke features voor compute uit de consumer kaarten sloopt om dit te voorkomen.

[Reactie gewijzigd door Flaat op 22 juli 2024 18:01]

[FreezeXJ]

Mwa, puur rekenen kunnen ze beide, en die Tesla-dingen zijn 10x zo duur, dus wetenschappers on a budget (zeg maar alle) pakken de cheapo-versie. De voordelen van die dure dingen zitten em in betere ondersteuning, en ECC-geheugen, beide niet hard nodig voor dit soort klussen. Mocht Nvidia teveel slopen, dan stapt iedereen over naar AMD, dus dat doen ze ook niet.

[dehardstyler]

ECC geheugen niet nodig? Wat nou als de berekening 2 van de 3 maanden bezig is en er sluipt een fout in de berekening die er niet uitgehaald wordt? Dan heb je dus niks meer aan je berekening.

[bantoo]

Maar dit is juist geen een grote berekening.

[dehardstyler]

Het zijn inderdaad allemaal kleine berekeningen die samen een grote berekening vormen. Ook in die kleine berekeningen kunnen fouten sluipen, wat mij zeer onwenselijk lijkt!

[bantoo]

Een false positive is makkelijk opnieuw nagekeken, colisions zoeken is hoe dan ook een spelletje kansberekening, de kans dat je een geheugenfout raakt die ECC geheugen gevangen had is niet een significante factor.

[FreezeXJ]

Mwa, worst-kaas-scenario krijg je de volgende collision, die ruwweg 2x zo ver zit in de rekenspace. Om dat simpel op te lossen zet je 2x zoveel hardware in, klaar. Tesla-kaarten zijn 10x zo duur, dus 5x zo inefficient.

Dit is allemaal aangenomen dat je die ene error nou net exact op de verkeerde tijd krijgt, de kans daarop is... minuscuul (1 hash op de tig miljard die je getest hebt).

Voor langdurigere simulaties zoals weerkaarten etc is ECC een stuk nuttiger, dat klopt... maar zelfs dan... is het goedkoper om 3 systemen parallel te laten draaien, en bij fouten handmatige ECC te gebruiken

[drdelta]

worst-kaas-scenario

Ik moest grinniken.

[CAPSLOCK2000]

ECC is niet de enige manier van controleren, je kan dat ook op een ander niveau doen.

Google heeft een tijd lang zonder ECC gedraaid, de controles deden ze wel in software. Dat was zo efficient dat ze op een gegeven moment opzettelijk slecht RAM gingen kopen. Dat konden ze namelijk spotgoedkoop krijgen en de meeste balkjes hebben toch niet meer dan een paar foutjes.

[analog_]

Linux heeft een module voor badram. Je kan dmv. memtest het proces automatiseren dat de kernel deze locaties nooit alloceerd. Die module is er al sinds '95 ofzo.

[Reactie gewijzigd door analog_ op 22 juli 2024 18:01]

[ceun92]

Interessante doorbraak.

Toch heb ik mijn vragen bij de volgende uitspraken van Stevens:

"Als je een collision voor sha-1 wilt vinden, moet je ook een collision voor de compressiefunctie vinden. Het is nog net iets moeilijker maar we kunnen met deze bouwstenen een volledige aanval uitwerken"

Aangezien deze groep cryptologen en wiskundigen erin zijn geslaagd om een gedeelte van het SHA-1 algoritme te kraken, wie zegt dan dat het protocol zelf inmiddels niet al door een andere groep gekraakt is (of wordt)?

Zeker als wordt aangegeven dat SHA-1 nog een veelgebruikt hashing protocol is, baart mij dat aardig zorgen. Zodra SHA-1 gekraakt wordt, zullen alle gegevens die met deze hashing methode versleuteld zijn ook meteen zo lek als een mandje zijn.

[CAPSLOCK2000]

Aangezien deze groep cryptologen en wiskundigen erin zijn geslaagd om een gedeelte van het SHA-1 algoritme te kraken, wie zegt dan dat het protocol zelf inmiddels niet al door een andere groep gekraakt is (of wordt)?

Dat weten we omdat het nog niet in de krant heeft gestaan. Wie dat lukt zal het van de hoogste toren blazen.
Het kan natuurlijk dat een geheime dienst of criminele organisatie het in het geheim heeft gekraakt. Dat kan, maar dat kan net zo goed voor iedere andere vorm van beveiliging die we hebben. Absolute veiligheid bestaat niet en alles is te kraken. Of dat ook gebeurd is kun je niet weten tot het te laat is.

Zeker als wordt aangegeven dat SHA-1 nog een veelgebruikt hashing protocol is, baart mij dat aardig zorgen. Zodra SHA-1 gekraakt wordt, zullen alle gegevens die met deze hashing methode versleuteld zijn ook meteen zo lek als een mandje zijn.

Zo'n vaart zal het ook weer niet lopen. Het woord "kraken" is een beetje misleidend. Dat lijkt op een brandkast die open of dicht is. Zo werkt het niet. Denk aan een cijferslot waarvan je 1 cijfer weet. Dat maakt het openen van dat slot een stuk makkelijker maar het blijft veel werk.
Hoe meer cijfers je hebt hoe makkelijker het wordt maar het slot spring pas open als je alle cijfers hebt gevonden.

Bij cryptografie is het zo dat bij een doorbraak als deze de puzzel een klein beetje kleiner is geworden. Daardoor is het wat minder werk geworden om het te kraken. Iedere volgende aanval maakt het weer een beetje minder werk. We zijn nu op het punt aangekomen dat we het realistisch begint te worden om een echte aanval te doen.

De voorgangers van SHA-1 (MD5 en RC4) zijn ook nog steeds in gebruik en die zijn nog veel zwakker. Vroeg of laat krijg je daar problemen mee maar het is niet zo dat opeens alle computers ter wereld gekraakt zijn ofzo.

[ceun92]

MD5 is nu, mits unsalted, al in een paar seconden te kraken.

Uiteraard bestaat ultieme privacy niet, maar het feit dat veel systemen gebruik maken van verouderde technieken is niet optimaal te noemen..

Concepten zoals "eliptic curve cryptography" zijn theoretisch gezien niet te kraken, maar nadeel hierbij is dat dit ontwikkeld is door of in samenwerking met de SNA (Dual_EC_DRBG).

Ik wil niet wantrouwend zijn. Maar het wordt eens tijd dat veilige en betrouwbare hashing- en encryptionprotocollen, door onzijdige partijen, ontwikkeld worden.

[gekkie]

Door bij tijds aan te geven dat een algoritme te zwak begint te worden, kun je hem uitfaseren ruim voordat er ook daadwerkelijk structureel misbruik van gemaakt kan worden. Dat verzwijgen om mensen niet een idee te geven dat het zwakker wordt klinkt leuk, maar dat zou er vanuit gaan dat die crimimelen ontwetend zouden zijn op hun terrein. Dat is over het algemeen niet bepaald het geval.

[nick lunenburg]

Ah oke,

Ik wil mij binnenkort hier meer in gaan verdiepen dus
Denk ook niet dat zoiets zal gebeuren, maar je weet maar nooit

[CAPSLOCK2000]

Ik weet niet hoeveel mensen of hackers/criminelen dit lezen..

Wie slim genoeg is om hier aan mee te werken hoeft geen crimineel te zijn, die kan overal een goede baan krijgen.

Op dit moment is het niet echt realistisch. Ongeveer even realistisch als dat een stel criminelen hun eigen ruimtestation lanceren. Dat zou kunnen maar is niet echt waarschijnlijk. Wie het geld en de hersenen heeft doet er wel iets anders mee.

[SuperDre]

Leuk, maar als het nog steeds weken/maanden duurt om te kraken (en zoveel geld) dan is het voor nu nog steeds zinloos om er een realtime verbinding mee te proberen te hacken.. Dus nog steeds geen probleem, zeker niet omdat de opvolgers van de standaarden al gebruikt kunnen worden..