'Nieuwe Intel-processor ideaal voor encryptie'
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.
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.
Als het encrypten tien keer zo snel gaat en het kraken gaat ook tien keer zo snel, dan ben je uiteindelijk niets opgeschoten.
Als het encrypten tien keer zo snel gaat en het kraken gaat ook tien keer zo snel, dan ben je uiteindelijk niets opgeschoten.
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 ;)
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)
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 .
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.
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.
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' .
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 .
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
