'Vederlichte' Present-encryptie opgenomen in industriestandaard

Present, een 'lichtgewicht' encryptiemethode die deels aan de KU Leuven is ontwikkeld, zal door de ISO en de IEC worden opgenomen in een nieuwe standaard voor cryptografische algoritmen die weinig processorkracht nodig hebben.

De Present-encryptiestandaard is ontwikkeld door Andrey Bogdanov van de Katholieke Universiteit Leuven in samenwerking met Franse collega's van Orange Labs, de Ruhr Universiteit Bochum en de Technische Universiteit van Denemarken. Het algoritme zou in tegenstelling tot het breed toegepaste aes veel minder processorkracht vereisen en daarmee het energieverbruik terugdringen. Het als lichtgewicht omschreven Present, met sleutellengtes van 80 of 128bit en een blokgrootte van 64bit, zou daarom onder andere toegepast kunnen worden in mobiele telefoons, implantaten en autosleutels.

De kwaliteit van de Present-versleuteling is uitgebreid bestudeerd door deskundigen en inmiddels als veilig bestempeld. Daarmee is de weg vrij voor standaardisatie. Present zal na het groene licht door de ISO en de IEC worden opgenomen in een wereldwijde standaard voor lichtgewicht encryptiemethoden. De KU Leuven stelt dat daarmee de weg vrij is voor ontwikkelaars om de nieuwe encryptiemethode breed toe te passen.

Reacties (54)

Hier wat software implementaties: http://cis.sjtu.edu.cn/in...ESENT_for_8-Bit_Platforms, http://www.lightweightcrypto.org/implementations.php
Hier nog een of ander vergelijkingstabelletje: http://www.ecrypt.eu.org/lightweight/index.php/Block_ciphers

[Reactie gewijzigd door darkfader op 28 februari 2012 21:00]

Is Present uberhaupt wel veilig?

Present, met sleutellengtes van 80 of 128bit

Aangezien er geen short-circuit attacks op AES bekend zijn betekend dit dat we bij AES alle combinaties moeten proberen (2^128 mogelijkheden bij 128bit) toch is bij AES 128 bit te weinig voor goede encryptie, waarom zou present dan wel veilig zijn? Of is het zo dat present alleen bedoeld is voor korte-termijn encryptie, zoals key-exchange algoritmen?

128bit AES sleutels zijn prima voor goede encryptie.
Stel dat we een 3Ghz CPU hadden die elke klokcycle 1 key zou kunnen proberen, dan zitten we nog te kijken naar 3596761023602004729656 jaar CPU tijd. Dat geeft heel wat speelruimte voor eventuele toekomstige aanvallen op AES waardoor het aantal bits entropie lager uitvalt dan 128.

Laten we zeggen dat lichte beveiliging nog steeds beter is dan geen beveiliging op bepaalde toestellen? An sich heb je natuurlijk gelijk dat het misschienn minder sterk kan zijn dan AES, maar het is specifiek ontworpen om minder krachtig te zijn en zal dus natuurlijk nooit gebruikt worden om een bankpagina mee te beveiligen of je super geheim bestand te versleutelen

DES was een algoritme met 16 rounds en is behalve met brute force nooit gekraakt. AES, present en andere nieuwe encryptie algoritmen hebben meer dan 16 rounds wordt er tegenwoordig een grotere veiligheids marge aangehouden of was de theorie achter DES gewoon beter?

DES had het probleem dat het met 56bit keys werkte dus dat was al snel niet veilig meer. Daarom bedacht men, nou laten we maar gewoon 3x DES uitvoeren over het zelfde blokje data met drie verschillende keys dus toen had men 3DES met 168bit keys. Dit is natuurlijk een stuk trager dan AES of een van de andere methodes, die in 1 keer een 128bit block kunnen encrypten ipv Triple DES die een 64bit block encrypt.

id init - stel je zou AES kunnen kraken, zou je het aan de grote klok hangen en die paar dollar incasseren die ermee te verdienen valt (waarvan te bezien valt of je het ook gaat krijgen dat geld want er zijn megaveel voorwaardes voor je die poen krijgt en dan nog kunnen ze er net als RSAlabs destijds onderuit door gewoon een maand voor je je poen gaat krijgen, de stekker uit het prijzengeld te trekken)?

AES, present en andere nieuwe encryptie algoritmen hebben meer dan 16 rounds

Voor de duidelijkheid: AES-128 gebruikt 10 ronden, AES-192 gebruikt 12 ronden en AES-256 gebruikt 14 ronden.

Minder processorkracht is omgekeerd evenredig met de tijd die nodig is om te brute forcen.

nee, de keylengte is belangrijk bij het bepalen van hoe lang het duurt om te brute forcen.

de eigenlijk methode maakt dan niks uit, zolang je idd praat over puur brute forcen (als in, gewoon alles raden)
zolang de gebruikte methode een veilig key oplevert, die niet te verzwakken is door bepaalde fouten in de methode maakt het niks uit hoe veel processor kracht het kost om de methode toe te passen.

[Reactie gewijzigd door Countess op 28 februari 2012 20:50]

Nou... Als je er nog even over nadenkt wel. Stel, je hebt t seconden nodig om een key te genereren. Dus heb je 1000t seconden nodig voor 1000 keys. Logisch? Als er n mogelijke sleutels zijn, is de hoeveelheid tijd die je nodig hebt n × t seconden. Hoe lager t wordt, hoe minder tijd je nodig hebt.

Je hebt natuurlijk gelijk. Als iets 1000x sneller gaat om te encrypten, dan verlaagt dat theoretisch de tijd die je nodig hebt om te kraken.

Maar, je verlaagt het met een constante factor (1000) terwijl een vergroting van een encrpytiesleutel de tijd exponentieel vergroot. Dus bij relatief kleine encryptiesleutels is het effect al nauwelijks merkbaar, omdat als iets 10.000.000 jaar duurt of 10.000 jaar het nogsteeds onwaarschijnlijk is dat hij gekraakt wordt.

En dan hebben we het nog niet eens over moderne (1024, 2048 bits) encryptiesleutels, waar de tijd benodigd om te kraken ontelbaar veel groter is.

De 1024/2048 bits sleutels die jij bedoelt zijn bedoelt voor asymmetrische encryptie mbv priem factorisatie. Deze sleutels zijn minder veilig "per bit" dan de 128+ bit sleutels gebruikt bij AES/Blowfish/Camellia en nu dus kennelijk ook Present omdat ze niet random zijn maar gegenereerd moeten worden in paren. Daarom gebruikt men ook veel meer bits per sleutel voor die algoritmen.

Dit is een beetje versimpelt maar je zou dus kunnen stellen dat een 1024bit RSA sleutel ongeveer evenveel bits aan entropie heeft als een 128bit "AES" sleutel (pure random bits).

Wilt u dat even bewijzen?

Er zijn de afgelopen 50 jaar fiks wat algoritmes voor RSA verschenen. Als over een jaar of 10, wellicht waarschijnlijker is dat hij al bestaat, er dus voor Bogdanov een algoritme is, dan is die entropie van een 1024 bits public key RSA sleutel nog altijd heel wat dimensies groter dan van Bogdanov 60 bits versleuteling, idemdito 128 bits AES.

Verder is AES ook een afgeleide van iets wat met priemgetallen werkt, dus als je kunt bewijzen dat je daarvoor priemgetallen nodig hebt die kleiner zijn dan de pak hem beet 400-600 bits bij een 1024 RSA sleutel, dan hang je ook met je uitspraak.

Quote van wikipedia over RSA:
"Keys of 512 bits have been shown to be practically breakable in 1999 when RSA-155 was factored by using several hundred computers and are now factored in a few weeks using common hardware.[11] Exploits using 512-bit code-signing certificates that may have been factored were reported in 2011.[12] A theoretical hardware device named TWIRL and described by Shamir and Tromer in 2003 called into question the security of 1024 bit keys. It is currently recommended that be at least 2048 bits long.[13]"

Je laatste uitspraak slaat kant nog wal. AES mag dan wel van "iets wat met priemgetallen werkt" (finite fields) gebruiken, maar de manier waarop deze gebruikt worden verschilt totaal van RSA. Het priemgetal dat voor AES gebruikt word is "2". Toch helpt dat niemand om AES te kraken.

Keys genereren is gratis als je brute forced, dat doe je immers niet door random cijfers te hashen maar om gewoon direct de random cijfers te gebruiken. Ik denk dat jij en Henk007 nog eens even moeten bijlezen

Een rainbow dictionary genereren doe je wel door een grote lijst bekende woorden/namen te prehashen, en die lijst te gebruiken, maar ook in een dictionary attack is de tijd die het kost om die lijst te genereren volgens mij niet vaak de begrenzende factor. Bovendien vraag je er ook een beetje om als je een standaardwachtwoord kiest, daar kan encryptie behalve ultratraag zijn het algoritme niets aan doen (maar dan dus echt veel trager dan AES ook enzo).

[Reactie gewijzigd door Brent op 28 februari 2012 21:05]

Wacht even... Of ik ben heel dom, of dat kan helemaal niet. Dan weet je wel de hash, maar dan weet je niet welke key erbij hoort... Of zie ik dat verkeerd. Want met de programma's die ik gebruik heb (Cain), zie ik bijvoorbeeld een enorm verschil in performance tussen MD5 en bijvorbeeld AES. Might be wrong...
EDIT: Want zover ik weet werkt het zo:
a -> hash genereren -> match?
b -> hash genereren -> match?
enzenz....

[Reactie gewijzigd door iThinkSo op 28 februari 2012 21:43]

Ojee, ik zat met hashes in het hoofd terwijl het over encryptie gaat, my bad. Punt staat nog wel dat snelheid het encryptie niet hoeft te verzwakken: je moet nog steeds 128bit aan sleutels uitproberen. Of dat nu honderdduizend jaar duurt of honderdmiljoen jaar is van weinig praktische consequentie.

Ja, die sleutellengte is dan ook wat me zorgen baart; 80- of 128-bits is echt niet veel, en een blokgrootte van 64 bits ook niet.
AES-128 heeft bijvoorbeeld al een sleutellengte van 128 bits en een blokgrootte van 128 bits, bij AES-192 en AES-256 is de sleutellengte nog groter (resp, 192- en 256-bits), en dan heb ik het nog niet eens over de andere vormen van Rijndael, waarbij de blokgroottes ook nog eens 192- of 256-bits kunnen zijn. Zelfde verhaal bij bijvoorbeeld Twofish, Serpent, RC6 enz.
Kortom, op het eerste gezicht lijkt het me allemaal wat té "licht-gewicht". Ik houdt het dus voorlopig nog even bij het inmiddels uitgebreid geteste AES en andere 'gerijpte' algoritmen.

Maar belangrijkere vraag is : welke implementatie vind je goed om te gebruiken?

Twee keer zo snel te kraken klinkt heftig, maar als de versleuteling zo goed is dat het dan nog steeds een eeuwigheid duurt en goedkoper/breder toepasbaar is, dan heeft het toch nut!

Oh dat klinkt interessant. Ik ben benieuwd hoe het algoritme eruit ziet en ben ook benieuwd hoeveel minder CPU kracht tov AES die gebruikt.

Wat te denken van Camellia?

De snelheid waarmee Camellia zou kunnen coderen en decoderen is hoger dan van Present (voor zover ik het kan volgen). Wat is het praktisch nut van Present over Camellia?

veel minder gates nodig.

Maar dat heeft toch maar beperkte impact op het geheel. Als het doel is om Present te gebruiken voor 'lichte' apparaten dan had dit al gekund met Camellia. Elke nieuwe ontwikkeling op dit gebied kan ik alleen maar toejuichen maar als hardwarefabrikanten nu al niet alle mogelijkheden gebruiken, waarom zouden ze dat nu plots wel doen?

je moet betalen voor zijn pdf om het te lezen. iets waarvoor je moet betalen in de wiskunde daar moet je zo je vraagtekens bij zetten. Als je echt iets hebt wat goed werkt dan schreeuw je dat van de daken natuurlijk.

De basis staat in deel 1, welke zo is te downloaden.

Wil je een praktische uitvoering, waarbij deel 2 nodig is, dan is een vergoeding niet vreemd. Wie wil nou niet zijn vinding beschermen?

Hopelijk hebben de personen die het algoritme bestudeerd hebben goed genoeg gekeken, zodat bij eventueel wereldwijd gebruik later geen zware fouten ontdekt worden die het boeltje dan weer onveilig maken...

Ik heb de source code even bekeken, er worden 1040 bytes gebruikt voor een lookup table, voor sommige microcontrollers is dat te veel. Toch maar weer XOR gebruiken ;-)

Waar kun je die downloaden? Bogdanov's pdf kost geld namelijk.

Volgens mij is heeft de sterkte van een encryptiemethode te maken met de lengte van de sleutel en de rekenkracht die nodig is voor het uitvoeren van de decryptie. In dit geval is minder rekenkracht nodig voor het uitvoeren van een decryptie dan bij AES. Dus is er ook minder rekenkracht nodig om te brute forcen. 2^128 * het verschil in rekenkracht dat nodig is om een decryptie uit te voeren om precies te zijn....

Tof. Eindelijk (?) wat standaardisatie in de encryptie(-industrie). Ten minste, zo intrepeteer ik dit...

Nou, je mag 1 keer raden waarvoor de S in AES staat

Omdat het een standaard is, en je hem dus niet kan veranderen. Je zou natuurlijk wel een AES2-standaard kunnen introduceren...

JPEG is ook een standaard maar daar worden nog altijd efficientere codecs voor ontwikkeld. Zo ook voor compressie algoritmen enz, dus waarom encryptie niet? Als de uitkomst niet veranderd kan het geen kwaad om een efficienter algoritme te ontwikkelen.

Zelfs een PIC16F84 microcontroller kan AES encryptie aan, zei het niet erg snel maar er wordt steeds weer efficientere manieren gevonden:
http://edipermadi.wordpre...nting-aes-using-pic16f84/

JPEG is een slecht voorbeeld, want het is alleen een standaard voor decryptie. Na codering en decodering heb ik mijn origineel niet terug; de standaard is bedoeld om een afweging te kunnen maken tussen bestandsgrootte en kwaliteit. Hij legt daarom alleen vast hoe de jpeg weer uit te pakken naar een plaatje. Een algemeen encryptie algoritme kan zich niet veroorloven bij encryptie informatie weg te gooien.

Bijvoorbeeld door middel van een fatsoenlijke hardware implementatie

Te lezen in je profiel doe of deed je een studie Informatica aan het HBO. Alleen al met deze wetenschap in het achterhoofd (en dan laat ik eventuele hobbymatige interesse er nog buiten) had ik toch wel beter verwacht dan de post die je gemaakt hebt ...

Wat een bullsh*t zeg jij allemaal?
Ik studeer momenteel aan de KUL. Het is niet omdat het een katholieke universiteit is, dat de studenten ook gelovig zijn (praktisch niemand van mijn richting is, zover ik weet, gelovig).

En veralgemeen inderdaad maar alle christenen, het zijn inderdaad allemaal pedo's [\sarcasm].

OT Als het zoveel minder processorkracht gebruikt, gaat de encryptie dan ook niet minder processorkracht nodig hebben om gekraakt te worden?

OT Als het zoveel minder processorkracht gebruikt, gaat de encryptie dan ook niet minder processorkracht nodig hebben om gekraakt te worden?

Het versleutelen en ontgrendelen met een sleutel gaat sneller, je kan als je de sleutel hebt de data sneller ontgrendelen, zonder sleutel gaat dat niet sneller. Het aantal mogelijkheden van 128bit Present-encryptiestandaard sleutel blijft gewoon evenveel mogelijkheden als de 128bit AES sleutel, je moet in bieden gevallen 128bit nalopen.

Zie ook
http://en.wikipedia.org/wiki/Brute-force_attack

Het aantal mogelijkheden van 128bit Present-encryptiestandaard sleutel blijft gewoon evenveel mogelijkheden als de 128bit AES sleutel, je moet in bieden gevallen 128bit nalopen.

Maar het is weldegelijk zo dat de tijd die het kost om gemiddeld 2¹²⁷ pogingen te doen voor Present dus een factor kleiner is dan voor AES.

2¹²⁷ is wel veel, een los factortje in de orde van 100 ofzo doet daar weinig aan af. Natte vinger schatting: 2¹²⁷ is iets in de orde grootte "aantal atomen in ons zonnestelsel".

2^127 is 10^38
Iets wat onder de 10^19 ligt nu kan wel redelijk berekend worden met huidige computers (gpu's).

Die 2^127 is dus zonder algoritme iets kraken - gewoon brute force.

Dus het eerste het beste algoritme dat gaat iets met 2^127 mogelijkheden al kraken.
Zelfs een random algoritme als pollard-rho (voor factorisatie) werkt al met de vierde
machtswortel.

Dus 2^127 is dan minder dan 2^32 om te kraken, maar een paar miljard mogelijkheden hooguit dus.

Dan heeft verder zo'n algoritme allerlei collissions en mogelijkheden die niet benut kunnen worden, wat de searchspace dus beperkt.

We kunnen er natuurlijk wel vanuit gaan dat als het gaat om extreem sensitieve data, dus met name financiele data want alles wat te maken heeft met geld is het meest sensitief, dat je met iets van een bit of 128 niet veilig bent.

offtopic:
Alle christenen pedo's noemen lijkt mij inderdaad kul. Da's wel erg makkelijk alles over een kam scheren...

On-topic: Ja, een lichter encryptie-algoritme zal inderdaad waarschijnlijk minder kracht nodig hebben om gekraakt te worden.
Maar het is nog steeds beter dan geen encryptie, en met name voor apparaten zoals pacemakers en insulinespuiten lijkt me dat wel degelijk een argument. Voor dat soort apparaten is de batterijduur ontzettend belangrijk: Batterij leeg betekent een dure, zware operatie om hem te vervangen. Aan de andere kant: Een inbraak op zo'n kritiek systeem kan je ook erg duur komen te staan... Als je dus kunt beveiligen zonder de batterijduur significant te verlagen is dat zeker het overwegen waard.

Edit: Bewoording veranderd.

[Reactie gewijzigd door Hadron op 28 februari 2012 21:12]

De naam van de K.U. Leuven is historisch gegroeid, en onlangs nog lichtjes gewijzigd. De meesten geven trouwens verschillende invullingen aan het woord Katholiek...

Jullie Belgen hebben de K.U.Leuven, wij NLers hadden de K.U.Tilburg
Maar on-topic: waarom niet meteen ook een fatsoenlijke 256-bits variant standaardiseren ? Is misschien minder ECO, maar wel meer future-ready ...

Ja die gasten in Leuven, zo'n hoofdprofessor daarvan kwam eens met mij praten een paar jaar geleden. Kijk, je moet het zo zien. Er komen teveel mensen om daar in de buurt die iets van cryptografie afweten, soms al op studentikoze leeftijd.

Alleen wat van die Russen overleven alles en iedereen.

Bogdanov?

Pardon mag ik u vragen?

Het probleem met dat soort ideetjes voor cryptografie is dat als iemand het snel weet de decrypten, dat ze dat meestal NIET aan de grote klok hangen.

Het voordeel van de vorige thread: RSA is in elk geval dat iedereen snapt dat factoriseren geen simpel probleem is.

Weliswaar kun je gokken dat het polynomiaal moet kunnen, omdat je bijvoorbeeld ook kunt bewijzen in polynomiale tijd dat iets een priemgetal (overigens bij een bit of 4096 zou dat wel eens tijdje kunnen duren die polynomiale tijd, want het gaat tot de macht 10).

Maar niemand heeft in elk geval publiekelijk dat ooit gevonden.

Op het moment dat AES werd gestandaardiseerd zat je natuurlijk al met het probleem dat eigenlijk bijna iedereen die iets afweet van wiskunde dat niet aan de grote klok hangt.

Dat nu dan een GCD truukje al een enorme implementatiebug laat zien, doet daaraan niets af.

Maar een lightweight encryptie die dus kennelijk sneller is dan AES, terwijl sommige AES dat al in 14 cycles per byte afkunnen, daar zou ik toch mijn vraagtekens bij willen zetten - en vooral bij hoe serieus men gaat pogen dit te kraken op een publieke manier.

Kraken zullen vast velen proberen, maar zij die succesvol zijn zullen dat vast niet aan de grote klok hangen, dat is eigenlijk het kernprobleem continue in alles wat met cryptografie te maken heeft.

Er is natuurlijk een reden dat bijna alles wat serieus encrypt, inclusief certificaten voor JAVA, dat dat met RSA werkt...

Zullen we allemaal Islamiet worden?
Kun je kiezen, sjiiet soeniet..

Het Katholieke net is zeer serieus. Zoals al blijkt uit het artikel zitten er zeer slimme mensen.

Dat men zich wil distantieren van het katholieke geloof is jammer.
Het is begrijpeljik dat de meerderheid tegenwoordig niet meer geinstreseerd is in de oude verhalen. Maar men moet durven toegeven dat al onze waarden en normen voortvloeien uit dit geloof. De democratisering van de maatschappij is langzaam tot stand gekomen, net door deze waarden. Dit in tegenstelling tot andere geloven (zie landen in het middenoosten of china/japan)
Ethische waarden worden overgedragen uit de maatschappij op de jongeren. Zo komt het dat er zonder revoluties maar langzaam een andere visie zich kan ontwikkelen.

(BTW: 1789: Franse revolutie, Mei 68: studente revolutie, beide hebben in een keer grote impact gehad op de maatschappij; Arabische Lente voorjaar 2011; Olie Crisis jaren 70 (invoeren zomertijd))

ASML werkt trouwens samen met zusterbedrijf Imec.

/ik wou hier eerst niet op reageren, maar nu andere het doen, moet ik wel even rechtzetten.

//offtopic:

Maar men moet durven toegeven dat al onze waarden en normen voortvloeien uit dit geloof.

Valt wel mee, religieuzen zijn er vaak als de kippen bij om moraal te monopoliseren maar veel waarden (en dus normen) staan los van geloof, of het nu christelijk, joods, islamtisch, wicca of boeddistisch is.

De democratisering van de maatschappij is langzaam tot stand gekomen, net door deze waarden

Eerder ondanks dan dankzij..

Nu ook niet overdrijven,
Het katholieke schoolnet in Belgie is meer dan deftig te noemen, daar hoeft de OP zich geen zorgen over maken, laat staan beledigingen over te uiten. Dat hij/zij zich eerst verdiept in het Belgisch onderwijs systeem voor hij/zij erover begint. Het katholieke gedeelte zit vooral in de naam en een paar andere details, voor de rest is zeker de KU Leuven meer dan ok.

Dit gezegd zijnde draait ge de boel hier wel om. Godsdienten waren/zijn eerder een medium om juist deze waarden en moraal te kunnen verspreiden, dan dat ze de oorsprong waren, maar of ze hier effectief in waren betwijfel ik ten zeerste. Ge kunt ze er perfect los van koppelen, zeker aangezien godsdiensten nogal de neiging hebben om lokale waarden en moralen over te nemen en te integreren indien het godsdienstigen helpt om hun godsdienst verder te laten groeien. De Islam en Christendom hebben nl heel veel waarden gemeenschappelijk, en de aziatische spirituele culturen staan dacht ik ook als vrij vredelievend en verdraagzaam gekend, verdraagzamer dan het Christendom zelfs dacht ik ( correct me if I'm wrong), als een godsdienst dan zo onontbeerlijk is voor waarde overdracht, waarom zou ik dan nooit van mijn leven in een Aziatisch of een Islamitisch land willen gaan wonen? Godsdienst is duidelijk niet de enige factor (als het er al één is) voor waarden aan uw bevolking over te dragen.

Trouwens, noch de franse revolutie, noch de mei 68 betogingen noch de arabische lente ontstonden uit godsdienstige problemen/initiatieven. Zeker de mei 68 betoging was etnisch en cultuur overschrijdend, laat staan dat het ingegeven was door een godsdienst.

Kunnen alle discussies die niet over het wiskundige algoritme gaan misschien encrypt worden hier?