Ontwerpers Rijndael niet onder de indruk van aanval

De encryptiestandaard Rijndael ligt onder vuur, maar de bedenkers van het systeem zijn niet onder de indruk, zo schrijft de Standaard. Twee wetenschappers denken dat ze een zwakke plek gevonden hebben en met efficiënte algoritmes de beveiliging kunnen kraken. Het Rijndael-algoritme, bedacht door de Vlamingen Vincent Rijmen en Joan Daemen, werd twee jaar geleden door de Amerikaanse overheid gekozen als nieuwe officiële encryptiestandaard, en wordt gebruikt om vrijwel alle vertrouwelijke Amerikaanse overheidsgegevens te beveiligen. Natuurlijk is 'Rijndael' daardoor een opvallend doelwit voor hackers, maar tot op heden is het algoritme veilig gebleken en bovendien wordt er verder onderzoek gedaan om mogelijke kraakpogingen te voorkomen:

"Om te beginnen is het een puur academische aanval'', zegt Rijmen. Want zelfs met alle slimmigheidjes van Courtois en Pieprzyk blijft het kraken van Rijndael té veel rekenwerk voor de huidige generatie computers. Áls die slimmigheidjes tenminste al werken, want volgens Rijmen en enkele andere experts hebben Courtois en Pieprzyk zich gewoon vergist in hun rekenwerk en blijft Rijndael even veilig als het altijd geweest is. De Amerikaanse overheid lijkt die opinie te delen, want ze is voorlopig niet van plan iets aan de standaard te veranderen.

Reacties (37)

Wel grappig dat kopje bij De Standaard " Rijndael doorstaat eerste aanval". Terwijl deze encryptie-methode juist aangenomen is na een soort wedstrijd tussen grote bedrijven en uniefs die er in bestond elkaars codering aan te vallen en wie gekraakt werd viel af. Rijndael bleef over, samen met nog twee anderen dacht ik.
Eerste aanval?

Wat ik niet snap is dat 'ze' (de amerikaanse overheid bijvoorbeeld) niet gewoon een aantal encryptieprotocollen op elkaar stapelt, in plaats van van een enkele afhankelijk te zijn.

gewoon het ene protocol 'tunnelen' binnen het andere dus.

Heb dat zelf ook wel eens gedaan, een datastream door zowel rc6, rc5 en blowfish te sturen, vervolgens (of eerst) te gzippen en klaar ben je. Performance mag toch heden ten dage geen excuus meer zijn als een word documentje in 1/10 seconde 3voudig gecodeerd wordt.

Ook al blijkt dan in later stadium een van de lagen potentieel onveilig, dan heb je altijd de andere nog.

Ik denk niet dat dit een goede oplossing is.
Mijn kennis van encryptie is helemaal niet groot maar als ik mij niet vergis maakt een algoritme bvb een zo groot mogelijke chaos van je Word bestand. Die chaos kan je alleen maar ongedaan maken door een (zeer lange) sleutel.
Nu kan het zijn dat je eerste algoritme een hele hoop chaos heeft veroorzaakt. Hierna neem je een ander algoritme dat ook zoveel mogelijk chaos moet gaan veroorzaken... maar die is er in princiepe al. Het kan dus zijn dat je een tegengestelde werking krijgt, dus dat het 2de algoritme de bits (of wat dan ook) zo veranderd dat er weer wat minder chaos is...
Je moet het zien als 2 heel lekkere drankjes die je mixt, deze mix kan ook wel eens vies smaken

Nogmaals, ik ken eigenlijk niet zoveel van encryptie, maar ik denk dat het zoiets moet zijn.

niet helemaal dus.. chaos * chaos = nog meer chaos.
dus niet -1*-1=1 maar 1*1=1

Als het zo simpel was dan zou je op vergelijkbare manier ook kunnen decoderen.

je vergelijking met mix van drankjes is overigens wel in orde een encryptie moet zo 'vies' mogelijk smaken voor een decoderingsalgoritme.

je bedoelt 1+1=2

Meer chaos ga je niet krijgen.

Je moet de laatst gebruikte encryptie kraken, daarna kan je pas aan het voorlaatste beginnen.

Dus je moet 2 keer kraken ipv van 1 keer. Dus verlenging van de uren.

De meeste encryptie protocollen maken al gebruik van een "mix" van algoritmes om het bruteforcen moeilijker te maken. Ook zal er voor communicatie waarschijnlijk nog voor additionele encryptie op het verkeer zitten. Je moet je ook voorstellen dat voor iedere extra vorm van beveiliging ook andere keys nodig zijn, extra rekenkracht/ opslagcapaciteit/ bandbreedte, enzovoorts. Er zijn ook encryptiemethodes die niet zonder meer op elkaar stapelen, maar voor "side-effects" kunnen zorgen als je ze combineert.

Allemaal erg lastig dus en ik denk niet dat ze daar zin in hebben, maar gewoon vertrouwen hebben in Rijndael. "Aanval" vind ik ook een groot woord voor een wiskundig verhaaltje van een paar wetenschappers die het niet eens kunnen toepassen omdat het alleen theoretisch kan. Eerst zien, dan geloven...

Ipv van meerdere encrypties over elkaar te gebruiken kun je toch beter de 'strength' van 1'te verhogen? Om maar een voorbeeld te noemen. In PGP kun je key 1024 bits of 2048 bits of etc etc maken.

Was die encryptie van je serieus voor een klant oid, want dan plaats ik er nogal wat vraagtekens bij. Je kunt namelijk niet zomaar blockciphers chainen (streamciphers wel met onafhankelijke sleutels).

En compressie doe je altijd voor het versleutelen om de redundantie in de plaintext te reduceren. Hierdoor wordt het veiligheidsniveau hoger.

Wat zou ik als goed beveiliging bedenken???

Origineel: een txt-document
.txt ff laten inzippen
.zip laten remixxen met een .mp3 bestand
.mp3 in stukjes hakken en met bepaalde volgorde doorelkaar gooien.
dat bestand in een bmp uitsmeren
.bmp naar .jpg omzetten
.jpg naar wav omzetten
.wav in zeer grote aantal stukjes hakken en in .mp3 remixxen
-dan verspreiden via kazaa

Daar mogen ze lang achterzoeken, het zal wat langer duren dan alle mogelijk passwords uitproberen. Men moet exact alle stappen, volgorde, details en materiaal kennen. Het is ook leuk om beveiligde bestand te laten besmetten met de 10 vieste virussen. De ongewenste h@x0r zullen problemen krijgen...

Deze methode met zoveel stappen en ingewikkeldheden is niet bepaald gebruiksvriendelijk, maar goed genoeg voor mensen die wat van computers kennen.

volgend mij kan dat niet wat jij vertelt. mp3 en jpg zijn allebei compressie waarbij je bits verliest en je dus nooit het orgineel terug krijgt.

verder is deze manier ook niet veilig want als iemand de volgorde kent weet die hoe die alles moet lezen. bij echt encryptie moet je de source code van een pragramma kunnen lezen en zelfs dan moet het niet kraakbaar zijn

[i]Als je de volgorde van de letters en cijfers van een password kent is het ook niet meer veilig.

Alle beveiliging zijn gebaseerd op geheimhouding.
[\i]
daar ben ik het helemaal mee eens maar als jij een programma schrijft om dat voor je te doen. en dat doe je wel als je het een paar keer perdag doet(neem ik aan). is dat programma niet veilig als er iemand is die dat programma reverse engineert en er achter komt in welke volgorde je je bestanden 'encrypt' kan die alles lezen. voor een speel encryptie is het genoeg maar niet genoem voor de amerikaanse overheid

Je kan toleranties instellen en je moet de juiste tolerantie kennen om te decoderen. Dat is te vergelijken met een modem, die moet men ook met toleranties werken om informatie van slechte kwaliteit te decoderen. Zowel met .mp3 en .jpg

verder is deze manier ook niet veilig want als iemand de volgorde kent weet die hoe die alles moet lezen. bij echt encryptie moet je de source code van een pragramma kunnen lezen en zelfs dan moet het niet kraakbaar zijn

Als je de volgorde van de letters en cijfers van een password kent is het ook niet meer veilig.

Alle beveiliging zijn gebaseerd op geheimhouding.

Eigen taaltje in de txt-document ontwerpen is ook interessant.

Zelfs als men de volgorde kent moet men alle bestanden en instellingen hebben voordat men kan beginnen met het decoderen. Een password (x aantal bits) is veel sneller door een herkauwd dan een zoeken naar een bepaalde .mp3 (x aantal MegaBytes)
bestand+mp3=beveiligd
beveiligd-mp3=bestand
zonder de juiste mp3 gaat het niet.

goh misschien ideetje na RC5-72. Distributed.net is principe opgezet om de US overheid te overtuigen dat met brute Force ( bijna ) alles te kraken is

Ja, maar hoe lang duurt dat? Toch een beetje lullig als je er na 5 jaar achter komt dat er in het bericht staat: "We vallen morgen om 10 uur daar-en-daar aan." De meeste dingen hoeven niet eeuwig geheim te blijven, alleen maar lang genoeg.

Ik denk niet dat je de US overheid daarvan hoeft te overtuigen. De NSA doet het namelijk zelf ook, waarschijnlijk zelfs op een wat hoger niveau.

Ben wel benieuwd naar de uitkomst hiervan. 'tis eigenlijk wel ironisch, bedacht door twee personen en gekraakt(?) door twee anderen

Dat is maar 72 bits. BlowFish ondersteund 448 bits keys en dit algoritme is daarmee vergelijkbaar IIRC.

Als dat zo zou zijn is dat natuurlijk een serieus probleem; alleen is het wel raar dat dit wordt afgedaan als onzin door de bedenkers. Zonder argumentatie ook nog eens. Stel dat er daadwerkelijk een lek in zou zitten dan is het toch belangrijker dat je dat oplost

Hoezo lek? Als ik het artikel lees lijkt het er meer op dat enkele mensen denken manieren te hebben gevonden om de beveiliging met brute-force sneller te kunnen kraken. Wat overigens dus nog niet is gebeurd / gelukt. Dus hoezo moeten ze argumenten geven tegen loze uitspraken? Wat ze overigens doen door te zeggen dat bruteforce hacken zelfs met die snelle manier, als die zou werken, nog te lang duurt..

Als dat zo zou zijn is dat natuurlijk een serieus probleem; alleen is het wel raar dat dit wordt afgedaan als onzin door de bedenkers. Zonder argumentatie ook nog eens. Stel dat er daadwerkelijk een lek in zou zitten dan is het toch belangrijker dat je dat oplost.

'Zie
http://www.be.linux.org/pipermail/asbl-libre/2002-October/000522.html

Bovenstaande link heeft de inhoud weer van het artikel die daarover in Science is verschenen.

Hier nog een stukje commentaar:

Looks like that the attack cannot be implemented using a modern hardware and moreover, it is quite possible that this attack does not exist at all and based on the flaw in the analysis.
Nothing to worry about yet.

-------

BTW... Dat is reeds tamelijk oud nieuws hoor. Science kwam daarmee uit in September...
Zie: ------------------------
COMPUTER SECURITY:
Crucial Cipher Flawed, Cryptographers Claim
Charles Seife
Science 2002 September 27; 297: 2193 (in News of the Week)
------------------

Want zelfs met alle slimmigheidjes van Courtois en Pieprzyk blijft het kraken van Rijndael té veel rekenwerk voor de huidige generatie computers.

Het lijkt me onmogelijk dat de NSA niet direct een of andere superPC vrijmaakt om te testen of die wiskundige kneepjes inderdaad een zwakheid in Rijndael vormen. Als ze dus uiterst kalm blijven, is het omdat het getest en fout bevonden is lijkt me. ZOOOO lang kanhet nu eenmaal niet duren voor de NSA?
En vertrouwen op een encryptie met bewezen zwakheid zullen ze al zeker neit doen!! Dus ik denk dat die Belgen met recht en rede de aanval afslaan als vliegen van hun puddinkje...

Ok, waarom doen ze zo moeilijk? Maak er gewoon een Distributed Computing programma van.. Wedden dat DutchPowerCows hem kraakt?

Ik zal zekerzzz mee doen!

Om ijndael Brute Force te kraken heb je zelfs met een redelijk grote cluster meer tijd nodig dan de leeftijd van het Heelal .... Good luck to you

totdat het wel wordt gekraakt , dan is iedereen opeens in rep en roer, omdat het niet veilig is gebleken.

ben toch benieuwd met wat voor supercomputer ze dat weer gaan proberen op te lossen.

Die twee lopen dus gewoon een hoop warme lucht te verkopen omtrent door de ameriaknen gebruikte encryptie die zou gekraakt kunnen worden door terroristen (wordt niet gezegd maar daar komt het uiteindelijk toch wel op neer).
Om maar in de media te komen...

Dit even terzijde: Joepie, weer een bericht uit september 2002 dat het nu haalt in de Standaard en tweakers als nieuws.

Maar goed: de aanval door de heren is echt alleen nog maar in theorie. en daarbij vergissen ze zich waarschijnlijk groots in de aanname wat voor rekenkracht er nodig is, omdat ze voor die berekening al geen genoeg rekenkracht hebben om het zeker te weten. En dat heet dan academisch onderzoek?

Maar hoe lang gaat het kraken van die code met efficientere decoders dan gaan duren?
Ik ben bang dat als ze gelijk hebben het kraken van deze code nog langer gaat duren als de tijd die nodig is om deze code geheim te houden.
Dat is eigenlijk ook zo zinloos aan het kraken van RC5 codes: je kunt er niets mee. De codes die bv. banken gebruiken worden ook vaak veranderd. Voordat je de code hebt is er al weer een andere in gebruik.