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.

Jag tyckeer ofta jag hör personer som resonerar att då nättjänster som Facebook inte är viktiga/känsliga behöver man inte bry sig om att skydda sitt konto, exempelvis med att använda olika och bra lösenord för varje tjänst. Dels har dom fel i sak, Facebook innehåller för många massor med personlig information.

Men sedan är det risken med att komma åt andra konton och samla ihop mer information på ett enkelt sätt som gravt underskattas. Slutligen är det ren säkerhetshygien att inte återanvända lösenord hur som helst. Ungefär som att alltid använda blinkers när man skall svänga…

No related posts.

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

Referenskoden är inte kanonsnygg och rätt dåligt dokumenterad. Bland annat stämmer inte namn med specifikationen, man gör egen definition av typer där man rimligen borde använd stdint.h och det finns inget körbart exempel. (I ärlighetens namn är det dock inte den sämsta referenskoden jag sett för ett krypto – kryptologer verkar i gemen vara rätt dåligt insatta i hur man skriver kod.)

Det var dock inga större problem att få snurr på ZUC och generera lite nyckelströmmar. På min laptop och med referenskoden får jag ca 250 Mbit/s när jag genererar block om 100 miljoner ord. Inte kanonhög prestanda, faktiskt något förvånande om man jämför med Snow.

Vad gäller algoritmen i sig och de naiva analyser jag kan göra ser jag egentligen inga nya saker. Jag hittar ingen bias mot några värden i Sboxarna, utan dom är rektangelfördelade. Initiering och klockning av interntillståndet ser väldigt mycket ut som i Snow. Däremot är det fortfarande oklart varför man valt de magiska konstanter och just de Sboxar man gjort. Vidare är det frågan hur mycket det påverkar att bara ha två Sboxar istället för fyra som i Snow.

En hårdvaruimplementation av ZUC ser ut att vara ungefär lika svår att göra som en implementation av Snow, dvs inte alls speciellt svårt och ge en kompakt implementation. Och då uppdatering av LFSR-kedjan samt uppslagning av Sboxar går att parallellisera borde det gå att få en rejäl prestandaökning jämfört med en SW-implementation.

Slutsatsen jag kan dra är att specifikationen verkar stämma med referenskoden och att det går att generera nyckelströmmar som stämmer med testvektorerna. Kan man lita på säkerheten hos ZUC ser det ut att vara ett helt ok strömkrypto. Det finns inga stora märkligheter men heller inget speciellt attraktivt och speciellt. Det är därför knappast av tekniska skäl som ETSI/SAGE, 3GPP och GSMA standardiserar ZUC. Speciellt då man precis standardiserat Snow 3G ger ZUC knappast någon algoritmisk diversitet, då borde man istället valt Trivium, Grain eller Rabbit, alla tre strömkrypton från eSTREAM-sviten med stora skillnader i struktur och uppbyggnad i jämförelse med ZUC och Snow..

Nej valet av ZUC handlar nog enbart om att möta kraven för access till en marknad och möjligheten att tjäna stora pengar. Förhoppningsvis blir vi som konsumenter inte lidande.

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.

Rätt skrämmande bildsekvens. Jag kan inte tolka det som att kriget är på väg att avslutas. Bilderna har även lätt till en analys och diskussion av krigets utveckling, ex att Talibanerna ser ut att ha börjat försöka störa den ringväg som tydligen finns i Afghanistan.

Vad gäller Wikileaks har tydligen president Obama bett England, Tydlland, Australien m.fl. länder att åtala Wikileaks Julian Assange för spionage på grund av publiceringen av Afghanistan-informationen.

Wikileaks har svarat med att publicera en stor fil kallad Insurance (finns längst ner på sidan om Afghanistan-kriget). På Bruce Schneiers blog går diskussionerna höga om filen verkligen innehåller vad den misstänks innehålla, om Wikileaks använder rätt strategi etc. Klart intressant läsning iaf.

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 största förändringen i draften är att vi ändrat en av kryptonycklarna och därmed genererat nya vektorer. Draften innehåller två olika slags nycklar med tillhörande testvektorer för olika nyckellängder. En av dessa nycklar är genererad genom att köra strängen Internet Engineering Task Force genom hashfunktionen SHA-256. Tyvärr inkluderade den gamla strängen radbrytning vilket inte syns i strängen. Detta är nu ändrat.

Andra ändringar är att vi nu även har med testvektorer runt nyckelströmspunkten 4096 Bytes. Vidare har vi förtydligat en del referenser och säkerhetsrekommendationer för RC4. Rent krasst skriver vi att:

The RC4 algorithm does not meet the basic criteria required for an encryption algorithm, as its output is distinguishable from random. The use of RC4 continue to be recommended against; in particular, its use in new specifications is discouraged. This note is intended only to aid the interoperability of existing specifications that make use of RC4.

Vi tar gärna emot kommentarer och synpunkter på draften.

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.

Med inbyggt stöd för att identifiera text i bilder, snygga till figurer, kopplingar till andra tjänster är det mycket jag gillar med Evernote. Och att döma av kommentarer från de som använder Evernote verkar jag inte vara den enda och att tjänsten faktiskt fungerar. Eftersom det är en molntjänst går det dessutom att komma åt alla sin insamlade information via klienter på mobil, dator, webbläsare etc.

Tyvärr måste jag dock, för att citera Tony Irving säga: Men….Kolla in användarvillkoren (Terms of Service) för Evernote:

by using the Service and posting Content, you grant Evernote a license to display, perform and distribute your Content, and to modify and reproduce such Content to enable Evernote to operate and promote the Service. (You also agree that Evernote has the right to elect not to accept, post, store, display, publish or transmit any Content in our sole discretion.)

You agree that these rights and licenses are royalty free, irrevocable and worldwide, and include a right for Evernote to make such Content available to, and pass these rights along to, others with whom Evernote has contractual relationships related to the provision of the Evernote Service, solely for the purpose of providing such services, and to otherwise permit access to your Content to third parties if Evernote determines such access is necessary to comply with its legal obligations.

Jösses, man blir lite tveksam till att använda Evernote – även om det som sagt är en väldigt nifty tjänst.

No related posts.

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