Den första observationen är publicerad på det öppna artikelarkivet Arxiv. Artikeln handlar om huruvida AES kan ses som en slumpmässig transform av indatat, eller om det finns ett detekterbart mönster – ett mönster som går att gissa. En ideal kryptoalgoritm skall möta den så kallade Random Oracle-modellen där det inte skall gå att på förhand gissa vilken sekvens som skapas. En avvikelse från denna slumpmässighet innebär en svaghet hos algoritmen.

Författarna tAnna Rimoldi, Massimiliano Sala och Enrico Bertolazzi skriver i sin artikel Do AES encryptions act randomly? följande:

With our attack we give some statistical evidence that the set of AES-$128 encryptions acts on the message space in a way significantly different than that of the set of random permutations acting on the same space.

While we feel that more computational experiments by independent third parties are needed in order to validate our statistical results, we show that the non-random behaviour is the same as we would predict using the property of our embedding.

Indeed, the embedding lowers the nonlinearity of the AES rounds and therefore the AES encryptions tend, on average, to keep low the rank of low-rank matrices constructed in the large space. Our attack needs 2**23 plaintext-ciphertext pairs and costs the equivalent of 2**48 encryptions.

We expect our attack to work also for AES-192 and AES-$56, as confirmed by preliminary experiments.

Om jag fattat det rätt kan författarna alltså särskilja/identifiera att en viss mängd data är krypterat med AES, eller om det är en rent slumpmässig sekvens. Dom kan alltså inte extrahera nyckeln. Och notera att dom behöver par med okrypterat och motsvarande krypterat material. Detta är mao inte en attack som gör AES värdelös, utan är snarare en observation.

Den andra artikeln, On Deviations of the AES S-box when Represented as Vector Valued Boolean Function, tittar mer specifikt på den substitutionstabell (S-box) som finns i AES.

S-boxen, även kallad SubBytes-steget i AES är en enkel tabell som byter ut en byte mot en annan. Tabellen ser ut så här:

S-boxen bidrar till kryptots olinjära egenskaper, men för att göra det skall det inte finnas något enkelt mönster bakom S-boxen, utan bör vara en slumpmässig hög med tal. Samtidigt vill man väldigt gärna veta varifrån dessa konstanter kommer ifrån – hur dom genererats.

Säkerhetsexperten Bruce Schneier brukar prata om Nothing up my sleeve numbers som en viktig egenskap hos en säkerhetsfunktion. Vad han avser med denna egenskap är att det inte skall finnas hemliga antaganden eller delar av funktionen, delar vilkas säkerhetsmässiga betydelse inte går att avgöra. Bra specifikationer talar därför om varifrån konstanter kommer ifrån.

I fallet med AES S-box är det i standarden är det tydligt specificerat att den genereras på ett specifikt sätt. Wikipedia ger en bra beskrivning av SubBytes:

In the SubBytes step, each byte in the array is updated using an 8-bit substitution box, the Rijndael S-box. This operation provides the non-linearity in the cipher. The S-box used is derived from the multiplicative inverse over GF(28), known to have good non-linearity properties. To avoid attacks based on simple algebraic properties, the S-box is constructed by combining the inverse function with an invertible affine transformation. The S-box is also chosen to avoid any fixed points (and so is a derangement), and also any opposite fixed points.

Att man känner till hur S-boxen är genererad utnyttjas även i vissa AES-implementationer som istället för att ha en fast tabell på 256 Bytes räknar ut S-boxen under det att transformen genomförs. Detta tar tid, men sparar minnesutrymme.

Nå, tillbaka till artikeln. Vad författarna Danilo Gligoroski och Marie Elisabeth Gaup Moe visar är att, till skillnad på vad Wikipedia säger visar sig S-boxen inte vara riktigt så slumpmässig och vara så icke-linjär som man skulle kunna hoppas utifrån ett idealperspektiv, och vad man tidigare antagit. Författarna skriver:

In this paper we give an explicit representation of the AES S-box as a vector valued Boolean function in GF(2)8 and show several significant deviations in the number of terms that follows from that representation when it is compared with the algebraic representation of randomly generated permutations of 256 elements. We see this as a potential research direction in cryptanalysis of AES.

Inte heller denna artikel visar på en direkt, praktisk attack – utan är en observation. En av författarna, Danilo Gligoroski har även sagt på en maillista att han inte ser speciellt stora möjligheter att utnyttja deras observation i en seriös attack.

Vad är då slutsatsen efter denna långa postning? Ungefär det här: AES har inte fallit, långt ifrån det. Men tillsammans med tidigare publicerade attacker de senaste åren visar de här artiklarna på att det sker framsteg inom kryptanalysen.

Detta visar även hur viktigt det är att låta utvärdering av algoritmer ta tid och att vid systemdesign inte binda sig stenhårt för en enda algoritm vid systemdesign. Det kan hända att den algoritm så såg bra och säker ut vid design, några år senare visar sig vara svag. Om systemet och det systemet hanterar har längre livslängd än så behöver man kunna byta ut algoritmerna, att vara flexibel.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Adam Dunkels – pappa till uIP, bland annat.

Den nuvarande generatorn ger en monotont ökande sekvens som är lätt att prediktera. En ny generator skall ge en bra slumpmässig som inte är lätt (inte går) att prediktera. MEn samtidigt får storleken på stacken inte växa speciellt mycket och skall gå att implementera på en 8-bitars processor. Vidare får vi inte inför en massa nya krav på målsystemet, exempelvis tillgång till bra fysisk entropi. En icke-trivial kombination av krav.

Jag har tänkt, kladdat och sedan postat på Cryptography-listan och fått en del tips. Men jag (vi) tar med stor glädje emot mer klokskap. Här kommer därför min postning till listan. Läs, kommentera. Tack!

uIP [1] is a very compact TCP/IP stack for small, networked connected, embedded devices. (The code size for uIP including TCP and ICMP on the AVR processor is about 5 kBytes.)

Unfortunately, the TCP sequence number generator in uIP is a bit simplistic – basically a monotonically increasing number. In order to reduce the opportunities for TCP Spoofing (like this nice one [2]) we are trying to implement a new TCP sequence number generator.

What we want to find is an algorithm that generates a good (secure) TCP seq numbers, but use very little resources (on 8-bit computing devices).

We have done some preliminary investigations, have some rough ideas and would really appreciate comments and suggestions from the enlightened minds on this list.

As we see it, the two main problems to solve are:
(1) Find a secure PRNG algorithm that have as low implementation complexity as possible.

(2) Add as little system/application requirements on entropy source and persistent storage as possible.

Looking at TinyRNG [3] for example, it seems that a block cipher in CTR mode (or OFB mode) should be sufficient. The question then is what block cipher to use? The XTEA block cipher [4] is very compact, but would it be a wise choice from a security perspective?

But what to feed the PRNG with? Looking again at TinyRNG, it uses a simplistic version of the entropy accumulator from the Fortuna PRNG [5], but with fewer and smaller pools. The pools are processed using a CBC-MAC built around the same block cipher as used in the PRNG.

The combined storage for the pools as well as CBC-MAC state would probably be acceptable for uIP. The question is if the pool feeding operation as such adds operational requirements on uIP that makes it harder to integrate?

A simpler scheme could be to feed the PRNG (CTR-mode) with entropy used as part of Key and IV, that is not use a pool mechanism at all and leave it to user application to provide entropy words when performing a reseed. The Key (and IV?) would also consists of a counter that is monotonically increased.

The problem with this (we guess) is that in order to ensure that KEY+IV is never reused is to keep at least part of KEY or IV as a counter that is stored in persistent memory and increased once (and stored) every time reseed (or boot) is performed. (How bad from a security perspective would this be? Compared to other TCP sequence generators?)

The current version of uIP places few (basically no) demands on the system/application regarding physical resources (besides mem for code and data) and does not use any persistent storage besides code memory. It seems that any good sequence generator that are driven by physical entropy and tries to avoid sequence repetition need to place additional demands on the system. No?

This is basically as far as we have taken this. More or less a bit of Googling, reading and attempts at thinking. The ambition is not to invent something new and unproven but to adapt existing tech and ideas that seem to work. But get it to work with the size, performance and API constraints of uIP.

Any thoughts, comments, suggestions and pointers would be very greatly appreciated.

Thank you!
Joachim Strömbergson

References
—————

[1] A. Dunkels. uIP TCP/IP stack.

http://www.sics.se/~adam/uip/index.php/Main_Page

[1] R. Lawshae. Picking Electronic Locks Using TCP Sequence Prediction
http://www.defcon.org/images/defcon-17/dc-17-presentation/Ricky_Lawshae/defcon-17-ricky_lawshae-picking_electronic_locks-wp.pdf

[3] A. Francillon, C. Castelluccia. TinyRNG: A Cryptographic Random

Number Generator for Wireless Sensors Network Nodes

http://planete.inrialpes.fr/~ccastel/PAPERS/TinyRNG.pdf

[4] R. M. Needham, D. J. Wheeler. Tea extensions.

http://www.cix.co.uk/~klockstone/xtea.pdf

[5] Wikipedia. Fortuna PRNG.

http://en.wikipedia.org/wiki/Fortuna_%28PRNG%29

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Den första attacken är en attack på AES-algoritmen i sig och knyter därmed an direkt till de attacker jag bloggade om. Återigen är det Orr Dunkelman, Nathan Keller och Adi Shamir som ligger bakom den kryptanalytiska attacken.

Det intressanta med den här attacken är att till skillnad från de flesta attacker på AES-algoritmen kräver den här inte ett stort antal nycklar, utan bygger på en enskild nyckel. Just att de senaste årens attacker krävt ett stort antal relaterade (kopplade) nycklar har varit dessa attacker svaghet. Eller som EU-projektet ECRYPT II skriver i sin årliga rapport om nyckellängder och kryptoprimitiver:

We note that related-key attacks’ practical relevance depends on context, and these attacks are unlikely to affect practical uses of the AES algorithm.

Shamirs, Dunkelmans och Kellers nya attack, Improved Single-Key Attacks on 8-round AES kan därmed ses som ett svar på detta, Författarna skriver:

AES is the most widely used block cipher today, and its security is one of the most important issues in cryptanalysis. After 13 years of analysis, related-key attacks were recently found against two of its flavors (AES-192 and AES-256).

However, such a strong type of attack is not universally accepted as a valid attack model, and in the more standard single-key attack model at most 8 rounds of these two versions can be currently attacked. In the case of 8-round AES-192, the only known attack (found 10 years ago) is extremely marginal, requiring the evaluation of essentially all the 2**128 possible plaintext/ciphertext pairs in order to speed up exhaustive key search by a factor of 16.

In this paper we introduce three new cryptanalytic techniques, and use them to get the first non-marginal attack on 8-round AES-192 (making its time complexity about a million times faster than exhaustive search, and reducing its data complexity to about 1/32,000 of the full codebook).

In addition, our new techniques can reduce the best known time complexities for all the other combinations of 7-round and 8-round AES-192 and AES-256.

Fortfarande är det på AES-versioner med ett färre antal iterationer än det som normalt används. Men det är ännu ett sår i AES-bygget.

Den andra attacken är inte på algoritmen, utan en sidoattack på implementationen av AES - mer exakt på en datorplattform som exekverat AES och som sedan stängts av(!). Genom att använda verktyg för att lösa Boolean SAT-problem (svensutvecklade MiniSat) anpassad kryptoproblem – CryptoMiniSat. Detta verktyg har använts för att lösa en Boolesk beskrivning av nyckelschemaläggningen i AES kan dom återskapa nyckeln även från ett minne som varit avstängt och därmed tappat en stor del av sitt innehåll.

SRAM-minnen och till viss del även DRAM-minnen tappar sin information när strömmen kopplas bort, men kan behålla informationen under en längre tid – kallas data remanence. Speciellt i kalla förhållanden kan ett SRAM-minne behålla sin information under lång tid.

I artikeln Applications of SAT Solvers to AES key Recovery from Decayed Key Schedule Images visar Abdel Alim Kamal och Amr M. Youssef att dom för 10000 nycklar där 72% nycklen har förstörts (bitarna har ändrat värden slumpmässigt) kan dom återskapa 92% av nycklarna på mindre än 10 sekunder. Nu gäller detta inte enbart AES, utan som författarna skriver:

In this work, we modelled the problem of key recovery of the AES-128 key schedules from its corresponding decayed memory images as a Boolean SAT problem and solved it using the CryptoMiniSat solver. Our experimental results confirm the versatility of our proposed approach which allows us to efficiently recover the AES-128 key schedules for large decay factors.

The method presented in this work can be extended in a straightforward way to AES-192, AES-256 and other ciphers with key schedules that can be presented as a set of Boolean equations and, hence, lend themselves naturally to SAT solvers.

För den som vill läsa mer om data remanence rekommenderas Peter Gutmanns klassiska Data Remanence in Semiconductor Devices.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Detta är den första stora attacken (som dock snarare är en uppdatering på en attack från förra året) i år. Men sett över de senaste dryga året har vi sett fem, sex större attacker på AES som algoritm, samt ett antal mindre attacker där olika delar av algoritmen analyseras. Och sedan, naturligtvis ett antal attacker på implementationer, inte minst attacker basererade på felinjektering och sidoattacker. Wikipedias sida om AES listar några av dessa attacker, men långt ifrån alla. Bruce Schneier bloggade om dessa attacker ett par gånger i mitten på förra året (ett, två). En av de främsta på att attacker AES är Orr Dunkelmans.

Orr Dunkelman

Kolla man på Orr Dunkelmans forskningssida hittar man ett flertal artiklar med olika analyser av AES och attacker. Den här om vad som händer om MixColumns-operationen i AES inte fungerar i den sista iterationen är ett typiskt exempel på den typ av analys jag tycker att man ser ofta just nu (en trend inom kryptanalys).

Vad jag försöker säga är att jag upplever det som att AES, efter snart tio år sedan (AES publicerades i november 2001 så det snarare åtta år, men…) utan större säkerhetsproblem med algoritmen nu plötsligt börjar se lite skadeskjuten ut – att den kanske inte är så säker längre. Det är inte dags för panik, men långsiktigt och för nya applikationer bör man nog tänka på att inte låsa fast sig i AES, utan göra det möjligt att byta algoritm.

Till saken hör att AES har varit en formidabel succé och har designats in i alltifrån kommunikation för små sensorsystem (IEEE 802.15.4 – ZigBee) till 10G Ethernet och en oherrans massa saker däromkring. Skulle AES falla och måste bytas ut kommer det inte att bli enkelt.

Det skall bli spännande att se hur det går.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Nytt krypto fungerar bara där du förväntas vara tar upp ett iofs intressant fenomen där det går att koppla ett visst kvantfenomen till en given position. Idén är att använda detta för att skapa ett nyckelutbyte mellan två parter och att detta därmed skulle öka säkerheten. Jag tycker att det är ett intressant forskningsresultat, men har svårt att se den praktiska nyttan med tekniken.

Kommersiell kvantkrypterare knäckt handlar om hur några forskare lyckats attackera ett befintligt system för kvantbaserad kommunikation. Jag tycker att artikeln visar att kvantkryptering inte är den perfekta säkra kommunikationslösningen som kommer att stoppa alla attacker. Som vi sett tidigare (tack för tipset, Måns) har andra sedan tidigare (på C26C3) presenterat fungerande avlyssning på den här typen av system.

Och, jag är rätt allergisk mot begreppet kvantkryptering. Det må vara en metod för att kommunicera konfidentiellt genom att kvantkommunikationen störs om någon försöker avlyssna. Men det är inte en krypteringsmetod där en delad hemlighet används för att transformera meddelandet på ett sådant sätt att ingen utomstående kan förstå meddelandet. Det senare är vad iaf uppfattar som betydelsen av kryptering.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

David McGrew.

Draften Fundamental Elliptic Curve Cryptography Algorithms (draft-mcgrew-fundamental-ecc-02.txt) ger en referensbeskrivning av Elliptic Curve-krypto (ECC).

Varför är nu detta intressant? Jo – som författarna själva skriver:

The adoption of ECC has been slower than had been anticipated, perhaps due to the lack of freely available normative documents and uncertainty over intellectual property rights.
...
...
This note contains a description of the fundamental algorithms of ECC over fields with characteristic greater than three, based directly on original references. Its intent is to provide the Internet community with a summary of the basic algorithms that predate any specialized or optimized algorithms, which can be used as a normative specification. The original descriptions and notations were followed as closely as possible.
...
...
These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B.

Jag håller med om att det länge behövts en bra beskrivning av ECC. Men att det Just är patenträttigheter på ECC som hållit tillbaka utvecklingen verkar de flesta vara överens om. Som någon på Cryptography-listan konstaterade ger draften inte bara en normativ beskrivning av ECC, den sammanställer även en referens som är mer än 15 år gammal och föregår därmed de patent som idag finns på ECC.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Det finns flera källor för information om nyckellängder. Den som ofta förekommer är den i idag något gamla boken Applied Cryptography av Bruce Schneier som i kapitel sju har ett längre resonemang om olika nycklar och längder.

Vidare har NIST publicerat rekommendationer om nyckellängder, deras rekommendationer är dock från 2007. Även IETF har publicerat en RFC, RFC 3766 - Determining Strengths For Public Keys Used For Exchanging Symmetric Keys som innehåller ett längre resonemang om nycklars styrka, hur nyckellängder behöver skala med tiden, samt rekommendationer för assymetriska nycklar.

Det många av dessa källor tyvärr har gemensamt är att dom inte uppdateras speciellt ofta (alls). Webb-baserade källor borde därför vara av intresse att titta närmare på.

WIkipedia har förvirrande nog (minst) två sidor i ämnet, dels en sida om nyckellängder och en sida om kryptonycklar, båda med text om nycklar och längder. Borde nog slås samman och städas upp för att det skall bli användbart.

När jag letat runt efter olika referenser hittade jag att belgiska konsultfirman BlueKrypt har en fin sida som sammanställer rekommendationer om nyckellängder.

Den i mitt tycke bästa källan är dock en rapport. ECRYPT Yearly Report on Algorithms and Key Lengths, utgiven av det EU-finansierade ECRYPT II-projektet.

Som namnet antyder är det här en rapport som uppdateras en gång om året. Den senaste versionen kom ut sommaren 2009. Rapporten innehåller ett ordentligt resonemang om hur nycklars styrkor bör värderas (inklusive diskussioner om metoder som NIST, IETF och andra använder). Resonemanget leder så småningom fram till ett antal rekommendationer.

En viktig sak man gör i ECRYPT II-dokumentet är att sätta in styrkan i nycklar i hur kostsamt (rent ekonomiskt) det är att attackera en viss längd:

Jämför dom sedan olika typer av nycklar – symmetriska, assymetriska baserade på RSA, logaritmer eller ellitic curves får kommer dom med följande rekommendationer:

Slutligen sätter dom in längderna i ett tidsperspektiv – hur lång tid kan man anta att en nyckel med en viss längd ger ett skydd:

Vill du skydda något i 10 år från idag bör du alltså välja minst 96 bitars symmetrisk nyckel eller en RSA-nyckel på drygt 2400 bitar.

Allt detta förutsätter dock att algoritmerna som används inte har några svagheter. Den andra delen av ECRYPTS rapport innehåller en genomgång av de vanligaste algoritmerna inom olika kategorier – krypton, hashfunktioner, signaturer etc (DES, 3DES, AES, RSA, MD5, SHA etc). För varje kategori och specifik algoritm presenterar ECRYPT aktuell status vad gäller säkerhet och kommer med rekommendationer om vad man bör och inte bör använda. Mycket bra läsning.

En sista sak: exportreglerna för krypto i Sverige säger maximalt 56 bitar symmetrisk kryptering och maximalt 512 bitars assymetrisk kryptering (antagligen RSA) eller 112 bitar (antagligen elliptic curve).

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Det pågår även flera forskningsprojekt där man bygger upp ramverk för att på olika sätt jämföra implementationer (SW och HW) av olika kryptografiska funktioner – krypton, hashfunktioner etc. Ett sådan projekt är Athena-projektet som fokuserar på hårdvaruimplementationer. Ett annat projekt är ECRYPTs eBASH som mer tittar på SW-implementationer över ett stort antal processorarkitekturer.

Ett bekymmer med alla olika HW-implementationer är att det finns så många design- och teknologimässiga frihetsgrader. Är en given implementation optimerad för maximal prestanda eller minimal storlek? Är målteknologin en ASIC-process (och i så fall vilken processnod) eller en FPGA? Vilka teknologispecifika funktioner utntyttjas etc. Det är lätt att det blir en jämförelse mellan äpplen och päron, och kanske äpplen och köttfärslimpa.

I höstas kom artikeln Artikeln High-Speed Hardware Implementations of BLAKE, Blue Midnight Wish, CubeHash, ECHO, Fugue, Gr{o}stl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD, and Skein där man försökt hantera detta. Genom att välja samma målteknologi, samma verktygsflöde, samma metodik och implementationstategi har man försökt skapa implementationer av kandidater som skall gå att jämföra med varandra.

Rapporten ger en bra översiktlig beskrivning av samtliga HW-implementationer som skapats. Målteknologi är en 180nm Standard Cell-process (ASIC) från Faraday och man har tagit design genom syntes ned till nätlista och där gjort prestandaskattningar.

Utifrån ren prestanda når Keccak 21 Gbit/s och vinner med bred marginal:

En mer intressant blir det om man tittar på prestanda kontra storlek på implementationen:

Det verkar som de flesta kandidater ligger inom 40-60 kGates och där återfinns de fem snabbaste kandidaterna. I diagrammet ser man även hur Keccak och Luffa sticker ut prestandamässigt. Vidare är det värt att notera hur mycket mer komplexa de största kandidaterna är, och att det iaf inte ger någon prestandafördel. Om man skulle gå på dessa siffror (och utgår ifrån att säkerheten är lika hög hos alla kandidater) borde Keccak och Luffa ligga bra till samt att BMW och SIMD samt Skein sitta sämre till.

Det jag saknar nu är en bra jämförelse med SW-implementationer, ex från eBASH samt vad andra får fram för resultat av HW-implementationer (ex Athena). Visserligen riskerar det att bli äpplen och köttfärslimpa, men jag tror att den samlade bilden är viktig.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

This paper presents new software speed records for encryption and decryption using the block cipher AES-128 for different architectures. Target platforms are 8-bit AVR microcontrollers, NVIDIA graphics processing units (GPUs) and the Cell broadband engine.

The new AVR implementation requires 124.6 and 181.3 cycles per byte for encryption and decryption with a code size of less than two kilobyte. Compared to the previous AVR records for encryption our code is 38 percent smaller and 1.24 times faster.

The byte-sliced implementation for the synergistic processing elements of the Cell architecture achieves speed of 11.7 and 14.4 cycles per byte for encryption and decryption.

Similarly, our fastest GPU implementation, running on the GTX 295 and handling many input streams in parallel, delivers throughputs of 0.17 and 0.19 cycles per byte for encryption and decryption respectively. Furthermore, this is the first AES implementation for the GPU which implements both encryption and decryption.

Artikeln ger bra information om optimeringar som gjorts för de olika arkitekturerna samt jämför med andra implementationer. Jag gillar även det faktum att man faktiskt nådde 59 Gbit/s(!) på en NVIDIA GTX 295, 1.24GHz.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.