image

'Nieuwe Intel-processor ideaal voor encryptie'

dinsdag 4 juni 2013, 11:36 door Redactie, 11 reacties

Intel lanceert deze week de vierde generatie Intel Core processoren en dat is goed nieuws voor mensen die encryptie gebruiken. De chips, die de codenaam Haswell dragen, zouden veel zuiniger zijn, betere prestaties bieden en over een snellere geïntegreerde graphics beschikken. Een andere belangrijke toevoeging zijn de nieuwe instructies voor het optimaliseren van encryptiealgoritmes.

Voorheen had Intel al instructies aan de eigen processoren toegevoegd, zoals de 'aesinc' instructie, om het AES encryptiealgoritme te versnellen. Deze instructie verscheen in de Westmere processor, die in 2010 uitkwam. De Haswell processoren beschikken over instructies die alle encryptiealgoritmes moeten versnellen, aldus beveiligingsexpert Robert Graham.

Instructies
Door deze nieuwe instructies zal de snelheid van elk willekeurig cryptografisch algoritme verdubbelen. Graham verwacht vooral verbeteringen in programma's als OpenSSL en wachtwoordkraker John-the-Ripper. Volgens de beveiligingsexpert is het Intel niet alleen om snelheid te doen, maar ook om het energieverbruik.

Notebook en tablets die over een Haswell processor beschikken verbruiken meer stroom als ze bijvoorbeeld video- en audiobestanden openen die door DRM-kopieerbeveiliging zijn beschermd. Door het toevoegen van de nieuwe instructies kan de processor efficiënter met cryptografie omgaan, waardoor de accu langer meegaat.

"Intels toewijding aan cryptografie is de grootste verandering denk ik. De reden dat encryptie prestatie- en batterijproblemen veroorzaakt is één van de redenen dat het weinig wordt gebruikt. Door dit op te lossen, helpt Intel ervoor te zorgen dat crypto straks overal aanwezig is", aldus Graham.

Reacties (11)
04-06-2013, 12:43 door Edwin Martin
Maar als de nieuwe encryptie-instructies zowel het encrypten als het kraken versnellen, dan is er netto toch geen winst geboekt?
04-06-2013, 12:57 door Anoniem
Door Edwin Martin: Maar als de nieuwe encryptie-instructies zowel het encrypten als het kraken versnellen, dan is er netto toch geen winst geboekt?

klein nuance verschil.....je gebruikt encrypten in één zin met kraken. Kraken is net iets anders dan het decrypten van informatie m.b.v. een bekende sleutel.

De nieuwe instructies versnellen het encrypten en decrypten!
Het kraken m.b.v. JTR zal alsnog langer duren dan het decrypten van informatie met een bekende sleutel maar zal een stuk sneller zijn t.o.v. de huidige processoren.
04-06-2013, 13:10 door Edwin Martin
Ik bedoel precies wat ik schrijf ;-)

Als het encrypten tien keer zo snel gaat en het kraken gaat ook tien keer zo snel, dan ben je uiteindelijk niets opgeschoten.
04-06-2013, 13:26 door Whacko
Door Edwin Martin: Ik bedoel precies wat ik schrijf ;-)

Als het encrypten tien keer zo snel gaat en het kraken gaat ook tien keer zo snel, dan ben je uiteindelijk niets opgeschoten.
de reden dat dat zo is, omdat je meestal gaat bruteforcen. Dan encrypt je een willekeurige tekst, en checkt of de hash overeenkomt met de encrypted tekst die je probeert te kraken. Dus JA, dat gaat dan ook sneller ja.
04-06-2013, 15:17 door Terminator
Ja, of te wel, slecht nieuws voor mensen die encryptie gebruiken, en goed nieuws voor mensen die encrypties bruteforcen. Een snelheidswinst is niet zo belangrijk voor het encrypten, omdat dat in de praktijk meestal toch al wel snel genoeg gaat, omdat je het maar een paar keer hoeft te doen. Voor de krakers echter, die miljoenen keren per seconden zo'n algorithem draaien, maakt een snelheids winst van 100% best wel heel veel uit..
04-06-2013, 16:05 door lucb1e
Door Edwin Martin: Als het encrypten tien keer zo snel gaat en het kraken gaat ook tien keer zo snel, dan ben je uiteindelijk niets opgeschoten.
Weet ik niet zeker...
Stel dat je een algoritme hebt met een keylengte van 128 bits. Als je dan 10x sneller kan encrypten, kun je zonder snelheidsverlies een key van 1280 bits gebruiken. Echter bij een 128 bits key heb je 3.4*10^38 mogelijkheden, en bij de 1280 bits key 2.1*10^385 mogelijkheden. Als je dan 10x sneller kan kraken helpt dat bar weinig; dat gedeeld door 10 is nog altijd 2.1*10^384.

Dit is in ieder geval zover ik het begrijp, kan zijn dat mijn logica ergens niet klopt. In dat geval, onderbouw jouw stelling eens ;)
04-06-2013, 17:03 door Terminator
Goed punt lucb1e, maar betwijfel of mensen ineens over gaan steppen op een grotere key. Bovendien lijkt me bij het encrypten van data snelheid op dit moment geen probleem, pas bij het brutenforcen er van ga je merken dat die algorithmes best intensief kunnen zijn.
04-06-2013, 19:53 door Anoniem
Edwin Martin
Maar als de nieuwe encryptie-instructies zowel het encrypten als het kraken versnellen, dan is er netto toch geen winst geboekt?

Jawel

M.i. is het probleem dat het gemaakte "quitte"-punt niet de essentie van het artikel raakt.#
De essentie van het artikel is snelheidswinst in relatie tot het verlaagde energie verbruik.
Het mogelijke voordeel voor kraken is slechts een subpuntje bij gebruikersvoordelen van diverse andere software.

Samengevat is de netto winst dan :

- Verlaagd energie verbruik
- Verwachte toename van het gebruik van encryptie omdat de impact op batterijen acceptabel verlaagd is.
- Meer veiligheid door gebruik van encryptie dan 'met geen' gebruik van encryptie.
Bestanden zijn niet langer zomaar / direct toegankelijk.

En dat is winst vanuit security perspectief en tegen het licht dat misbruikers de weg van de minste weerstand kiezen. Als je de kraak-keus hebt begin je liever met onbeschermde devices, dat scheelt nogal wat aan kraak-tijd. 'Commerciële krakers' houden ook van efficiëntie : dat levert sneller meer geld op.

- De toename (het volume) van gebruikers met encrypted devices zal vermoedelijk veel groter zijn dan de toename van de capaciteit van krakers. Er zijn meer gebruikers dan krakers, die er nu gemiddeld genomen meer kraak-werk aan krijgen bij verminderd aanbod aan un-encrypted devices.

# bij verder op zich een interessante argumenten overigens (@16:05)
04-06-2013, 21:11 door Anoniem
Tjee. Een soort padlock, zoals, pak'm beet, via al tien jaar in hun energiezuinige chipjes stopt. Maar nu intel het doet, is het pas echt innovatie! Waarvan akte dan maar.
05-06-2013, 16:28 door Anoniem
Door lucb1e:
Door Edwin Martin: Als het encrypten tien keer zo snel gaat en het kraken gaat ook tien keer zo snel, dan ben je uiteindelijk niets opgeschoten.
Weet ik niet zeker...
Stel dat je een algoritme hebt met een keylengte van 128 bits. Als je dan 10x sneller kan encrypten, kun je zonder snelheidsverlies een key van 1280 bits gebruiken. Echter bij een 128 bits key heb je 3.4*10^38 mogelijkheden, en bij de 1280 bits key 2.1*10^385 mogelijkheden. Als je dan 10x sneller kan kraken helpt dat bar weinig; dat gedeeld door 10 is nog altijd 2.1*10^384.

Dit is in ieder geval zover ik het begrijp, kan zijn dat mijn logica ergens niet klopt. In dat geval, onderbouw jouw stelling eens ;)

In elk geval klopt je berekening niet zo erg.
Aantal cijfers gaat exponentieel / logarithmisch .

10 is een getal van twee cijfers .
10 * 2 = 20 = getal van twee cijfers

Pas 1000 is een getal van 2x2 cijfers .

128 bit getal verdubbelen = 129 bit getal .

De brute-force keyruimte is dan ook (maar) twee keer zo groot geworden.

De _keylengte_ verdubbelen levert wel exponentieel meer werk op voor een brute-force stijl aanval.
Het volgt zeker niet "dubbel zo snel encrypten" wil zeggen dat keylengtes dubbel zo lang mogen zijn.
Normaliter betekent het dat je 200 ipv 100 Mbit/sec AES throughput haalt . Dat is niet altijd uitwisselbaar tegen 'de oude throughput met een dubbel zo lange key' .

Om eerlijk te zijn is het hele keylengte verhaal typisch geneuzel in de marge.
Het is een zeer mimiem aantal aanvallen wat lukt vanwege een echte aanval op de cryptografie waarbij de key te kort was.

Zelfs bij dictionary attacks op hashes vind ik het dubieus om daar de hoofdschuld op de hashlengte of hash-complexiteit te leggen.
In zo'n beetje alle gevallen is het beschikbaar komen van hashes al een heel serieus falen van beveiliging .
06-06-2013, 08:54 door lucb1e
Door Anoniem: In elk geval klopt je berekening niet zo erg.
Aantal cijfers gaat exponentieel / logarithmisch .

10 is een getal van twee cijfers .
10 * 2 = 20 = getal van twee cijfers

Pas 1000 is een getal van 2x2 cijfers .

128 bit getal verdubbelen = 129 bit getal .

De brute-force keyruimte is dan ook (maar) twee keer zo groot geworden.
Hmm volgensmij niet. Het kraken is altijd een kwestie van tijd, de vraag is hoelang. Wel kun je zeggen dat als nu 128 bits in één jaar te kraken is, dat met Haswell processoren (die tweemaal zo snel zijn, aldus Intel) je 129-bits keys in één jaar kan kraken. Maar zonder tijdseenheid erbij klopt het niet.

Daarnaast kom ik bij 1280 bits in plaats van 129 omdat ik het had over encryptie en decryptie, niet het kraken. Het kraken van encryptie- of hashalgoritmes moet altijd exponentieel langer duren dan het encrypten of decrypten, dus tot zover gaat mijn logica op. De vraag is dan nog of het ook evenredig langer duurt naarmate de keygrootte groter wordt.

De _keylengte_ verdubbelen levert wel exponentieel meer werk op voor een brute-force stijl aanval.
Het volgt zeker niet "dubbel zo snel encrypten" wil zeggen dat keylengtes dubbel zo lang mogen zijn.
Normaliter betekent het dat je 200 ipv 100 Mbit/sec AES throughput haalt . Dat is niet altijd uitwisselbaar tegen 'de oude throughput met een dubbel zo lange key' .
Dat is een van de punten waar ik over twijfelde. Toch vraag ik me af waarom dan niet; zolang je het aantal rounds en dergelijke in het algoritme zelf gelijk houdt (deze zijn niet gelijk tussen verschillende AES-keylengtes) zou het zover ik begrijp zo moeten zijn.

Om eerlijk te zijn is het hele keylengte verhaal typisch geneuzel in de marge.
Het is een zeer mimiem aantal aanvallen wat lukt vanwege een echte aanval op de cryptografie waarbij de key te kort was.

Zelfs bij dictionary attacks op hashes vind ik het dubieus om daar de hoofdschuld op de hashlengte of hash-complexiteit te leggen.
In zo'n beetje alle gevallen is het beschikbaar komen van hashes al een heel serieus falen van beveiliging .
Dat klopt zeker, maar het is wel een interessante discussie vind ik :)
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.