NSAs National Cryptologic Museum har (naturligtvis) Enigma-maskiner att visa upp. Silicom.com har varit på sommarbesök och tagit några fina bilder. Den här på Enigma-rotorer exempelvis:
![]()
Posts Tagged ‘Krypto’
Fina Enigmabilder
August 9th, 2010Ny version av Internet Draft för RC4
June 29th, 2010Vi (Jag och Simon Josefsson) har precis släppt version 01 av vår Internet Draft med testvektorer för strömkryptot RC4.
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.
Två nya attacker på AES
June 12th, 2010Det var inte så länge sedan jag bloggade om att det varit mycket attacker på det symmetriska blockkryptot AES det senaste dryga året. Och nu kommer ett par nya attacker.
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.
Hälsoläget för AES
June 1st, 2010På Eurocrypt 2010 idag tisdag 2010-06-01 presenterade Ali Biham, Orr Dunkelman m.fl. en uppdaterade attack av sin attack på AES: Key Recovery Attacks of Practical Complexity on AES-256 Variants with up to 10 Rounds.
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.
Draft med referensbeskrivning för ECC
May 11th, 2010Det finns en intressant Internet Draft (I-D) av (David) McGrew från Cisco och Igoe från USAs National Security Agency.
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.(Notera att jag flyttat om ordningen på styckena.)
...
...
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.
Längd på nycklar och säkerhet
May 10th, 2010Jag har den senaste tiden fått flera frågor om längder på kryptonycklar – frågor om vad som är säkert, hur lång en assymetrisk nyckel skall vara för att motsvara en symmetrisk nyckel av en viss längd osv.
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).
Sectra får order på höghastighetskrypto
May 6th, 2010Elektronik i Norden rapporterar att Sectra fått en order från FMV på att utveckla linjekrypto för 10 Gbit/s.

Sectra ska på uppdrag av Försvarets materielverk (FMV), utveckla ett höghastighetskrypto för kryptering av känslig information i de nationella nät som används av myndigheter och försvar.
Hastigheten uppges till 10 Gbit/s, vilket är avsevärt snabbare än den kryptering som används idag. Ordervärdet uppgår till 23 miljoner kronor
Höghastighetskryptot ska skydda tal, data och video och säkerhetsnivån är den högsta, Hemlig/Top Secret.
Sectra har tidigare leverarat såväl linjekrypton, truppkrypton, flyg etc och även kryptomoduler som den här:

Ny Internet Draft: Test vectors for the stream cipher RC4
May 4th, 2010Igår kväll släppte Simon Josefsson och jag den första versionen av en ny Internet Draft vi hackat på ett litet tag.
Test vectors for the stream cipher RC4 (draft-josefsson-rc4-test-vectors-00) försöker lösa ett problem vi ser finns när man försöker implementera varianter av strömkryptot RC4.
Eftersom RC4 från början inte är en öppen standard har det inte funnits en tydlig specifikation med testvektorer att använda för att verifiera att implementationen är funktionellt korrekt. Vidare, då RC4 har en del säkerhetsproblem – inte minst problemet med att den läcker nyckelinformation under de första genererade värdena efter initiering finns det ett antal versioner av RC4 där ett visst antal värden skall kastas bort.
Ett exempel på en sådan standard är Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol (RFC 4345). Denna standard beskriver två versioner av RC4, arcfour128 och arcfour256. För dessa versioner skall de första 1536 värdena kastas bort.
Vår draft innehåller testvektorer genererade med två olika typer av nycklar med längder från 40 till 256 bitar. För varje nyckel och nyckellängd specificerar vi 32 Bytes runt ett flertal punkter i nyckelströmmen, exempelvis just 1536. Under arbetet har vi testat ett flertal implementationer av RC4 i exempelvis libgcrypt och andra bibliotek så väl som fristående implementationer, detta för att få så stor konfidens i att vektorerna är korrekta som möjligt.
Vi skulle uppskatta kommentarer och synpunkter på draften så om du läst igenom, ser något fel som strular, kommer på något som borde vara med, tas bort eller ändras – hör av dig till mig eller Simon!
Tack!
Vackra bilder på Fialka-rotorer
March 10th, 2010Ok, det börjar bli sent, men jag kan inte låta bli att posta några bilder från en sida med extremt detaljerad beskrivning av rotorerna till den gamla ryska, elektromekaniska kryptomaskinen Fialka. Det här är vackert:




Integritet på nätet med Microsofts U-Prove
March 4th, 2010Svenska Microsofts blogg On the Issues berättar om en ny teknik för att skydda användares integritet på nätet kallad U-Prove. Microsofts Daniel Akenine skriver:
Gammal visdom säger dig att om du vill ha en ökad säkerhet så måste du vara beredd offra en del av din integritet.
...
2004 introducerade forskaren Stefan Brands en process kallad U-prove för att adressera denna utmaning och 2008 köpte Microsoft upp denna teknologi. Stefan och hans medarbetare har sedan dess arbetat för att integrera idéerna i Microsofts teknologier och idag kan vi börja se resultatet av deras arbete.
...
Tankarna kring att i varje situation veta precis så mycket som krävs för att utföra en uppgift men inte mer kommer ifrån militärt tänkande där risken för läckande information kan innebära att faran ökar för en operation. Samma principer gäller även på Internet där du sprider (ofta omedvetet) mängder med information om dig själv i sammanhang där de fastnar och senare kan utnyttjas i andra syften.U-prove är en teknologi för att kunna skapa sådana fungerande scenarier och säkerställa att man inte röjer mer information än nödvändigt. Jag har följt U-prove teknologin i flera år och det är roligt att nu kunna annonsera ut att vi nu öppnar upp allt intellektuellt kapital som är associerat till U-prove och släpper det under Microsoft Open Specifikation Promise . Vi släpper samtidigt två stycken bibliotek som öppen källkod under båda Java och C# så att utvecklare kan börja använda denna teknologi på riktigt.
Låter som en mycket bra teknik. För den som vill veta mer och testa finns det mer info på U-Proves sida.

