Instructievoorspelling cpu's legt encryptiesleutels bloot

Een analyse van de manier waarop cpu's de verwerking van data versnellen levert volgens onderzoek een aanzienlijke verkorting op van de benodigde tijd voor het kraken van versleutelde gegevens. Voorlopig houden de cryptologen de details hun onderzoek geheim.

Een team van de Duitse cryptoloog Jean-Pierre Seifert is erin geslaagd om een 512bit-encryptiesleutel in enkele milliseconden te kraken. Ter vergelijking: de grootste tot nog toe gekraakte public-key-encryptiesleutel is 640 bits groot en werd gevonden door tachtig 2,2GHz-cpu's die daar drie maanden voor nodig hadden. Seiferts team bereikte hun resultaat door op vernuftige wijze de manier in de gaten te houden waarop de processor poogt het resultaat van de berekeningen waar het mee bezig is, alvast te voorspellen. Dat wordt gedaan om de instructiestroom te optimaliseren zodat de processor zo min mogelijk op opdrachten hoeft te wachten. 'Er wordt veiligheid opgeofferd ten behoeve van prestaties', aldus Seifert, die daarmee doelt op het feit dat de voorspellingsmodule van cpu's niet is versleuteld. Dat zou processors namelijk tot viermaal langzamer maken, zo verduidelijkt de cryptoloog. Essentiële details van Seiferts onderzoek blijven voorlopig geheim maar worden in februari uit de doeken gedaan tijdens de RSA-conferentie. De onderzoekers verwachten dat het dan een kwestie van weken is voordat er software verschijnt om de aanval uit te voeren.

Reacties (105)

[MrNOnamE]

Zelfs zonder die nieuwe techniek zal het tegenwoordig toch een stuk sneller gaan. Was zijn nu 80 2.2 Ghz cpu's. Als je die vergelijkt met de nieuwe xeons op 3Ghz zullen die al snel een faktor 3 zo traag zijn. Zelfs zonder een erg groot serverpark zou je die 640 bits versleuteling dan al binnen enkele dagen moeten kunnen kraken.

Om nog maar te zwijgen over supercomputers die de overheid of iemand met veel geld kan gebruiken (of kan huren).

[terabyte]

Volgens mijn ben je niet echt bewust van hoeveel mogelijke sleutels je mogelijk moet controleren bij een brute-force attack.

640 bit = 4562440617622195218641171605700291324893228507
2485599305791925178992751672086773865059128113
1737139977864230957359440731068870472137543799
8252661319722214188251994674360264950082874192
246603776
mogelijke sleutels.

Stel nu dat je dit brute-force wil kraken, en dat dat binnen enkele dagen gepiept is, zoals jij dat verwacht.

Stel dat enkele dagen = 3 dagen = 72 uur = 259200 seconden.
Stel dat er gebruik wordt gemaakt van 3 GHz cpu's in een niet-zo-groot "server"park zoals jij dat voorstelt (bijv 20 CPUs).

Stel nu dat de 3 GHz in elke klokcycle een sleutel kan checken (wat dus eigenlijk niet zo is).

Dat betekent dat een CPU per seconde 3*10^9 sleutels kan checken. We hebben 20 CPUs die parallel werken en dus checken we 60000000000 sleutels per seconde.

Dat betekent dat in het ergste geval het totale proces
2^640/(20*3*10**9) = 76040676960369920310686193428338188748220475120
80933217631987529832125278681128977509854685528
95233296440384928932401218448117453562572999708
77688662036903137533244572671082501381236 seconden duurt

Dat is toch wat meer dan die 259200 seconden ("enkele dagen").

@Hieronderr:

Stel dat de eerste testsleutel raak is

Zoals altijd in de informatica wordt zoals duidelijk vermeld uitgegaan van worst-case (vandaar de big-Oh notatie bij tijdscomplexiteitsanalyses van algoritmen). En de kans dat de eerste sleutel direct raak is, gaat richting de 0.

@AugmentoR: al die getalletjes zijn juist om aan MrNOnamE te laten zien hoe veel mogelijkheden 640 bit oplevert. En natuurlijk kan ik wetenschappelijke notatie gebruiken, maar wat heeft dat voor zin als men niet weet hoe groot 10^45 eigenlijk is?

[RSpliet]

Met 20 3GHz computers brute-force je in 3 dagen een 53,8-bit encryptie. Elke bit extra is een verdubbeling in tijd. Om de grote getalletjes in je post leesbaar te houden
Dat betekend dat er voor een 64-bit encryptie in zo'n parkje als jij beschrijft pak m beet 3072 dagen, of iets meer dan 8 jaar nodig is.

[humbug]

Zoals altijd in de informatica wordt zoals duidelijk vermeld uitgegaan van worst-case (vandaar de big-Oh notatie bij tijdscomplexiteitsanalyses van algoritmen).

Dat is natuurlijk niet helemaal waar. Wat is bv de worst case van de levensduur van een harddisk? Wat je als maatstaf gebruikt is sterk afhankelijk van waarom je het gebruikt. Bij dit soort sleutels is dat de gemiddelde rekentijd. Want het is eenvoudig mogelijk een algoritme te bedenken waarbij de worst case oneindig is, maar die in 99,9999999% van de gevallen in een minuutje gekraakt is.

En big-Oh notatie is inderdaad een mooie maatstaf voor de complexiteit van het algoritme, maar niet meer dan een hulpmiddel als je voor een specifiek geval op zoek bent naar een algoritme. Afhankelijk van je dataset en de specifieke algoritmen kan een algoritme met een grote factor interessanter zijn dan een met een kleine. Maar aangezien we in een tijdperk leven waarbij de datasets alleen maar groter en groter worden, wordt inderdaad vaak simpelweg het algoritme met de kleinste complexiteit gekozen. "Nu is het nog niet het snelste, maar na een paar jaar data verzamelen vast wel....."

[Verwijderd]

Het gevaar is inderdaad dat het snelste algoritme niet altijd de beste big-Oh prestaties heeft. Bij matrix-vermenigvuldigingen en lineair programmeren bijvoorbeeld. Daarbij zijn de 'beste' algoritmes pas bij gigantische datasets of alleen in extreme gevallen sneller. Aangezien big-Oh dat allemaal meeneemt is het niet alles-zeggend...

[Verwijderd]

Stel dat de eerste testsleutel raak is

[AugmentoR]

Je kunt natuurlijk ook 4.562244062 × 10^45 voor je getal hanteren, dat leest wat makkelijker...

maar hoe kom je er eigenlijk aan? Ik kom met 2^640 bits uit op 4.56244062 x 10^192 mogelijkheden, héél wat meer...

[Iblies]

Brute-force kun je makkelijk onaantrekkelijk maken door na een aantal keren het verkeerde wachtwoord in te typen de account enkele minuten uit te schakelen.

[Verwijderd]

Dit heeft helaas geen nut als de hacker de hash waardes al in bezit heeft en daar de wachtwoorden uit probeert te halen.

[_JGC_]

Het enige wat je nodig hebt om lekker brute force te kunnen kraken is harddisk ruimte, alles wat erna komt is peanuts. Je genereert eenmalig een bak met hashtable bestanden, vervolgens kraak je elk wachtwoord van dat soort in een minuut.
Voor de mensen die me niet geloven: http://www.antsight.com/zsl/rainbowcrack/
Enige probleem met rtcrack is dat je gigantische tablefiles nodig hebt (500MB p/stuk, en dat in 20-voud wil je alleen alphanumeric-lowercase md5 cracken), die per stuk op een P4 3.0GHz te genereren zijn in pakweg een week.
Overigens zijn die dingen ook gewoon te downloaden op bepaalde sites.

[reddog33hummer]

Rainbow tables is een gebruikelijke manier inderdaad voor windows passwoorden. Het grootste probleem is alleen dat in veel encrypties van passwoorden een salts wordt gebruikt. Deze maken rainbowtables onbruikbaar.

[Darude1234]

Rainbow tables is een gebruikelijke manier inderdaad voor windows passwoorden

Neem dan gewoon CIA Commander. Daarmee sloop je hem er in een paar seconden uit.

[Fairy]

Hou er wel rekening mee dat een 640bits sleutel een factor 'veel' moeilijker te kraken zijn dan 512 bits. 513 bits geeft namelijk 2x zoveel mogelijkheden, 514 bits al 4 keer, etc etc...

[Timfonie]

Dat dacht ik aanvankelijk ook. Maar het moet toch anders in elkaar zitten, want zo zou een code die een uur kost om te kraken, met 64 bits extra al een miljoen*miljard jaar moeten vergen.

[Verwijderd]

Zo zit het wel in elkaar. Dat er toch methoden gevonden worden om te kraken is meer omdat er klein ontwerpfouten in het algoritme worden gevonden waardoor de effectie stertke daalt van bijvoorbeeld 512 bit naar 320 bit, en daarna brute force. Ik denk dat het hier ook zo gegaan is.

[halfgaar]

De reden dat zo'n grote bitsprong weinig uit lijkt te maken, is omdat het asymmetrische encryptie is, met public en private keys. Daar zijn de mogelijke combinaties veel kleiner (omdat public_key x private_key = priemgetal), en moet de sleutel dus groter zijn. Daarom is een veilige assymetrische encryptie altijd in de orde van 1024-4096 bits, en is symmetrische encryptie van 128 bits al behoorlijk sterk, om maar te zwijgen over 256 bit.

[Verwijderd]

Je zal toch echt hardware toegang nodig hebben. Dus als je pas je toch al bij de NASA (bedoelde je NSA of NASA binnenlaat, ja, dan is dit een groot probleem.

Bas

[MBV]

simpel: hack de server, zodat je een user account hebt. Kijk vervolgens naar de processor als je de versleutelde database raadpleegt (en access denied terugkrijgt) en tada! je bent binnen...

[kozue]

Weet niet of het ook voor read-only geld, maar normaal mag een process niet aan processen van andere gebruikers zitten...

[blobber]

Weet niet of het ook voor read-only geld, maar normaal mag een process niet aan processen van andere gebruikers zitten...

Ik meende me te herinneren dat daar ook een manier voor was die overigens wel erg ingewikkeld was en nauwelijks in de praktijk uit te voeren, maar zeg nooit nooit

[Dutch_Razor]

Mission Impossible: Verberg je in de serverruimte en ontleedt een CPU terwijl ie draait

[mcdronkz]

Heel simpel inderdaad om een user account te krijgen op een NASA server

[SRI]

ja hoor ik heb er twee jij niet dan :P:P:P

[Roland684]

Het idee van encrypty is dat de data zelf veilig is. En bijvoorbeeld over onveilige media gecommuniceerd kan worden.
Als je de data al onbereikbaar kunt maken, heb je verder geen encrypty nodig.

Als ik die data eenmaal heb, maakt het niet uit of ik hardware-toegang heb, ik gebruik mijn eigen hardware wel.

[Dutch_Razor]

Dat is nogal een groot veiligheidslek..

Dus alle wachtwoorden zijn nu waardeloos?

[Jefrey Lijffijt]

Het klinkt eigenlijk alsof ze op de eigen computer als root kunnen afluisteren wat er als decryptiesleutel wordt gebruikt. Dat lijkt me eigenlijk geen nieuws, dat kan iedereen bedenken. Hij wordt tenslotte ook gewoon ingetypt...
Het daadwerkelijk uitvoeren ervan is niet zo eenvoudig, misschien zijn ze daarom zo trots, maar wel zinloos.

Er staat niet in het artikel wat ze geprobeerd te kraken hebben. Alleen dat ze iets met voorspellen hebben gedaan. Nu is het dus zo dat je niet uit het encryptiealgoritme de decryptie kunt afleiden. Encryptie is volledig open en transparent, iedere stap is publiek. Je kunt niet decrypten zonder sleutel, anders dan (slimme) bruteforce.
Daarom dus de initiele conclusie.

[Verwijderd]

Nee, er werd geen "decryptiesleutel" ingetypt, alleen een public key. De daarbijhorende private key werd berekend (wat jij decryptiesleutel noemt).

[Parasietje]

Neen, zo is het niet! Als dat zo zou zijn, zou iedereen jouw PGP private key kunnen ontdekken; door gebruik te maken van je public key.

[miw]

De oppervlakkige beschrijving geeft aan dat de aanval gebruik maakt van specifieke eigenschappen van een CPU. Dat betekent dat de aanvaller toegang moet hebben tot de computer. In de klassieke cryptografie (of volgens het nieuwbericht kennelijk "cryptologie" ) is het doel uitsluitend de beveiliging van de communicatieverbindingen. Als de versleutelinrichting in de handen van de tegenstander geweest is, kan je het kraken niet als zwakheid van het crypto algorithme beschouwen.

[stewie]

nee hoor aangezien dit over slechts 1 type encryptie gaat en niet alle.

error typen.
.

[newinca]

In dit artikel wel ja, maar het principe kan toegepast worden op elk soort encryptie algoritme: het gaat immer niet om een inherente wiskundige zwakheid van het algoritme, maar over de manier waarop een CPU het uitvoert.

[vso]

Inderdaad en als dit bericht waar is dan is elke encryptie waardeloos.

Ik vraag me af hoe ze dit gaan verhelpen.

[psyBSD]

Instructie toevoegen (zoals het aan-en-uitzetten van interrupts), het aan-en-uit-zetten van branch-prediction.

[newinca]

Door het algoritme 4 keer trager te maken.

Wel, daar komt het eigenlijk wel op neer: je moet er voor zorgen dat verschillende branch paden allemaal ongeveer even veel tijd nodig hebben. Nogal vervelend om te programmeren.

Het loopt allemaal wel zo'n vaart niet: men heeft nog steeds toegang nodig tot de computer waarop het algortime draait... En als dat zo is, is het echt wel een stuk gemakkelijker om gewoon een keylogger te installeren.

[denheer]

Kraakprogramma:

Aanzetten branch-prediction...start kraken...

[Verwijderd]

Neen. Je moet al volledige toegang hebben tot het systeem voor deze techniek toegepast kan worden. Bij dit experiment was alles toegankelijk, behalve het paswoord zelf.

Dus als er iemand onder je bureau ligt en een paar draden in je PC steekt, dán kan je alarm slaan...

[bamboe]

Hadden ze laatst niet problemen om een encryptie te kraken van een crimineel in amerika,....
Zou hier mee dus snel kunnen worden opgelost.

[Darude1234]

Kwestie van wat virussen en spyware en een hacker heeft volledige toegang tot je pc...

[DECOY88]

lijkt erop maarja is het is een keer niet de mens met waardeloos verzonnen wachtwoorden. maar de mannen die de processors ontwerpen.

[Verwijderd]

wachtwoorden zijn meestal niet encrypted maar zijn vaak een hash

[SKiLLa]

Klopt; en daar heb je oa. weer RainbowTables voor.

Helemaal nieuw is dit niet hoor, ze doen hier langer onderzoek naar; zie b.v: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

Met kennis van het encryptie-algoritme dat gebruikt wordt, kennis van de implementatie en direct toegang tot de CPU (voor oa. commando- en cache-timings) kun je met redelijke zekerheid de onbekende variabelen distilleren.

Het nieuws is nu dat iemand erin geslaagd is een dergelijk nauwkeurig algorithme en/of implemenatie te maken waardoor de onbekende data (= encryptie-sleutels) in ms. te achterhalen zijn...

De ketting is zo sterk als de zwakste schakel, ook bij encryptie

[thelynx]

Helaas dat gaat ook weer niet, aangezien deze chips weer in een hars-coating zitten :-) zogenaamde FIPS specificatie.

[source]

In februari liggen dan gelijk de databases bloot van oa de NASA... weten we eindelijk waar die aliens geland zijn

[jaapstobbe]

waar op aarde ligt "NULL" ook alweer?

[opagrover]

Null ligt zowel in Memphis, TN als in Windsor Mill, MD.
... volgens Google Maps.

Google weet Echt alles, zelfs dingen waarvan je denkt dat ze niet te weten zijn.

[Olaf van der Spek]

Het klinkt als een online timing attack waarbij de tijd gemeten wordt die het 'slachtoffer' nodig heeft om een sleutel te valideren.

Ter vergelijking: de grootste tot noch toe gekraakte public-key-encryptiesleutel is 640 bits groot en werd gevonden door tachtig 2,2GHz-cpu's die daar drie maanden voor nodig hadden.

Dat klinkt als een offline brute force attack.

[smokalot]

encryptie maakt gebruik van het verschil in complexiteitsklassen P (polynomiaal) en NP (Nondeterministisch Polynomiaal). Dit onderzoek behoudt het enorme verschil tussen de twee klassen, en dus is geen enkel encryptiealgoritme echt gekraakt.

Het is in feite het verschil tussen 2 keer de huidige leeftijd van het heelal en 1 keer. Het kost nog steeds miljarden jaren als je een sleutel van voldoende formaat gebruikt.

Om even een veelvoorkomend misverstand uit de wereld te helpen: ook snellere computers maken encryptie niet onmogelijk, omdat ook zij het verschil tussen P en NP niet doen verdwijnen. Je zult misschien wel elke 10 jaar je sleutel moeten vergroten om dezelfde veiligheid te garanderen, maar het principe blijft gewoon werken.

Quantumcomputers is een ander verhaal, dat zijn in feite nondeterministische computers namelijk, die het verschil tussen P en NP dus wel oplossen. Maar als je quantumcomputers hebt kun je ook weer quantumencryptie gebruiken, die zelfs fundamenteel onkraakbaar is.

reactie op skin:
ik bedoelde te zeggen dat ook een factor 2, 4, of een miljoen versnelling van het kraken van een sleutel (en dat doet dit algoritme voor zover ik begrijp) nog steeds encryptie heel goed mogelijk maakt.

[fevenhuis]

"quantumencryptie gebruiken, die zelfs fundamenteel onkraakbaar is" -Smokalot
Mits de quantumencryptie gekraakt wordt door een quantumcomputer uit een nondeterministisch gencodeerd quantumheelal.
Aangezien quantumcomputers in deze tijdlijn nog niet te bezichtigen zijn, zijn dit nogal onduidlijke voorbeelden.
Deze link is dan duidelijker.

[Verwijderd]

Je hebt helemaal gelijk; er zal altijd encryptie zijn die werkt vanwege het feit dat er nog niemand de miljoen dollar voor het bewijzen van P=NP heeft opgestreken

Echter, dit onderzoek pretendeert niet P=NP op te lossen maar om een sleutel die door een CPU wordt gebruikt "af te luisteren". In feite is het dus een hardware probleem waardoor de veilgheid van je key in het geding is. Dit heeft niks te maken met het formeel/theoritesche aspect van het kraken van een sleutel met algoritmes.

Voorbeeld: als je key tijdens gebruik in platte tekst naar een ftp server wordt weggeschreven is je sleutel niet gekraakt maar heeft iemand blijkbaar een ernstige fout in de ondersteunende software gevonden en daarvan misbruik gemaakt om de sleutel simpelweg te kopiëren.

Uiteraard is dit niet hetzelfde maar dit illustreert wel de aard van het probleem. Dit soort nieuwsberichten zijn helaas voor de leek vaak moeilijk te begrijpen waardoor het resultaat meestal FUD is. Spijtig, aangezien cryptografie een van de meest interessante en tot de verbeelding sprekende aspecten van het vakgebied is.

[Verwijderd]

Sinds wanneer is ontbinden in factoren NP-compleet? P=NP is (misschien) helemaal niet nodig.

[humbug]

Het probleem is dat door deze truc het verschil tussen de tijd die het een normale gebruiker kost om de data te decoderen en de tijd die een hacker nodig heeft drastisch verminderd wordt. Natuurlijk neem een 100000 bits key, dan is het nog wel veilig. Maar waarschijnlijk heb je er dan zelf niets meer aan doordat de encryptie en decryptietijden onredelijk hoog zijn geworden.

[Palomar]

Kan iemand misschien ook wat nader toelichten hoe dit precies werkt? Ik heb niet veel verstand van encryptietechnieken, maar volgens mij gaat het er hier alleen maar om dat er brute-force 1 voor 1 random codes worden geprobeerd, net zolang tot je de goede te pakken hebt. Maar hoe kan zo'n 'voorspellende' processor nou meer 'weten' dan een conventionele processor? De sleutel blijft toch de grote onbekende die gewoon geraden moet worden? Ik snap niet wat er voor die processor te voorspellen valt.

[newinca]

Encryptie algoritmes zijn meestal nogal branch intensief. De ene keer voeren ze een jump uit. De andere keer niet. Bij het programmeren van zo'n algoritme is de uitvoersnelheid dikwijls heel belangrijk en dus wordt er meestal geoptimizeerd voor uitvoersnelheid.

Het is hiervan dat de krakers gebruik maken: stel dat een key 20 nullen heeft en slechts 1 '1' en dat het uitvoeringpad van een nul een stuk trager is dan dat van een 1. Door het meten van het aantal uitgevoerde instructies kan je dan gaan beginnen raden naar de samenstelling van de key.
Een verschillende uitvoeringspad kan ook de snelheid beinvloeden van andere programma's die op de CPU lopen. Of het toegangspad tussen de CPU naar het externe geheugen.
Als je nu veel van dat soort tijdsdata verzameld, dan kan je de key space gigantisch reduceren en wordt een brute-force attack in die gereduceerde key space doenbaar.

In de posting hierboven is dat precies wat er verteld wordt: het algoritme wordt geoptimizeerd en 4 keer sneller gemaakt, maar ten koste van veiligheid.

Voor webencryptie is dat een non-issue omdat de variantie in de snelheid van de link veel groter is dan de variantie in het uitvoeren van programma paden.

Maar stel je heb een Unix machine met 1 CPU en meerdere accounts. 1 account doet encryptie. De andere is toegankelijk voor anderen. Op de vrije account kan je dan programma's draaien waarvan de snelheid varieert afhankelijk van wat waar de encryptieaccount mee bezig is.

De praktijk is ongetwijfeld een stuk complexer, maar dit is het basis idee.

Al bij al zou ik me er geen zorgen over maken: een tijdje geleden heb ik ergens gelezen dat als de FBI toegang wil tot een geencrypteerde computer, ze daar bij altijd voor 100% in slagen:
- een keylogger is veel efficienter dan paswoorden kraken.
- hints voor paswoorden kan je meestal vinden in niet geencrypteerde documenten op een computer waardoor targetted search mogelijk wordt
- veel mensen zijn bereid hun paswoord te vertellen als ze hierdoor, zeg maar, 10 jaar gevangenis gereduceerd zien tot 5 jaar bijvoorbeeld.

[kodak]

Als ik het artikel zo lees staat er helemaal niet dat ze het in het algemeen kunnen kraken maar dat ze "afluisteren" op een CPU waarbinnen al bekende gegevens zijn over de te kraken sleutels en dus zo een sleutel kunnen voorspellen.

[Verwijderd]

nou ik weet het ook niet precies maar mijn gok is dat het een bug is waardoor de CPU het antwoord krijgt van de CPU die om het goeie antwoord te kunnnen controleren op de een of andere manier het antwoord krijgt ofzo

[martijn_brinkers]

Voor de duidelijkheid, het is niet zo dat het nu mogelijk is om RSA keys sneller te kraken als je geen toegang hebt tot de processor waar op dat moment iets wordt onsleuteld met de prive sleutel. De attack is een zgn “side-channel attack” en je moet dus wel toegang hebben tot de processor die met de private key iets aan het ontsleutelen is.

We prove that a carefully written spy-process running simultaneously with an RSA-process, is able to collect during one RSA signing execution almost all of the secret key bits

http://eprint.iacr.org/2006/351

[imqqmi]

Precies. In eerste instantie dacht ik aan de electromagnetische straling die een cpu afgeeft bij alle soorten routines en processen in kaart brengen. En dat de persoon in kwestie op die manier een verband kon leggen tussen tussen processor ruis en encryptie sleutel.
Een beetje te vergelijken wat ze tegenwoordig kunnen doen met keyboard geluid en zo de toetsaanslagen kunnen herleiden en dus wachtwoorden enz.

[Kaasje123]

Dus als ik het goed begrijp is de AES standaard nu waardeloos geworden? Lekker dan. Eerst is het nog goed voor top secret (in Amerika) met een sleutel van 192 bits en nu kan het in miliseconden gekraakt worden.

Verbeter me als ik het fout heb hoor! Want ik hoop toch echt dat ik het nu fout heb

[humbug]

AES is nooit geheim geweest in de VS of daarbuiten. Alle algoritmes die indertijd in de race waren om de Amerikaanse standaard te worden moesten zelfs publiekelijk gepubliseerd worden zodat er een goede peer review mogelijk was. Uiteindelijk is er een Belgisch algoritme gekozen.

Waarschijnlijk ben je in de war met DES maar dat is al enkele jaren gekraakt en niet meer veilig.

Maar inderdaad. Deze truc kan waarschijnlijk op elk algoritme worden toegepast. Hiep hoi.

[Rafe]

Hij zegt ook niet dat het geheim in de USA is geweest, maar dat het uiteindelijk gekozen algoritme voor AES, Rijndael, vanaf 192 bits volgens de NSA goed genoeg is voor top secret documenten, en 'gewoon' secret is goed genoeg af met 128 bits.

[Olaf van der Spek]

AES is private/secret key encryption, dit gaat over public key encryption (RSA enzo).

[Willem2]

Jammer dat het verhaal niet vermeldt met hoeveel rekenkracht dit is gedaan; als iedere Jan-jurk met een standaard desktop PC dit in milliseconden kan kraken dan is het idd een zorgwekkende ontwikkeling...

[Verwijderd]

Dat is weinig interessant. Ga er maar vanuit dat als een serverpark het in enkele milliseconden kan kraken, dat elke pc die genoeg rekenkracht heeft om Windows te starten het binnen enkele minuten ook gekraakt kan hebben.

[ichnaton]

Als het gaat over milliseconden is de snelheid van de pc niet meer relevant, ik schat een dag voor een 386 zolang het geen cray oid betreft.

[Verwijderd]

Het kan aan mij liggen maar ik vind in dit spectaculair stukje nieuws nergens een vermelding van HOE die onderzoekers erin geslaagd zijn de inhoud van de registers uit te lezen zonder access tot de hardware.

[Lex_brugman]

Seiferts onderzoek blijft voorlopig geheim maar wordt in februari uit de doeken gedaan tijdens de RSA-conferentie.

[Verwijderd]

Mja ik ken dat soort meldingen van spectaculaire doorbraken waar men nu verder nog niets over kan zeggen... Meestal blijft het dan ook bij die melding...