Archive for the ‘Om Kryptoblog’ category

Ny version av Internet Draft för RC4

June 29th, 2010

Vi (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.

Länk till Data Compression Explained

June 14th, 2010

Jag insåg att jag gjort bort mig. I postningen om Mahoneys ypperliga genomgång av datakompression, Data Compression Explained glömde jag att ta med länken till just denna sida. Nu är det uppdaterat och för säkerhets skull är den även med i den här postningen. Är du intresserad, nyfiken på datakompression – gå och läs.

Och eftersom jag tog upp Mark Nelsons bok om datakompression – den riktigt klassiska boken på området är Text Compression av Bell, Cleary och WItten. Inte alls lika lättsmält som Nelsons bok eller Mahoneys sida, men väldigt bra.

Paneldebatt om molnet och IT-säkerheten

January 19th, 2010

I morgon onsdag skall jag vara med i en debattpanel på ICT-mässan i Göteborg om hur molnet påverkar IT-säkerheten. I debatten deltar även Predrag Mitrovic (CIO, MyNethouse), Per Josefsson (Information Security Manager, Telia Sonera), Johan Broman (Teknisk expert, Red Hat), Kaja Narum (Nordisk chef, RSA) och Rosella Carbone (Senior Account Manager, Salesforce).

Jag har aldrig gjort något liknande förut och är just nu lite nervös. Men det skall bli spännande och intressant att träffa de andra och höra vad de har att säga samt vad publiken har för frågor.

Mer om GSM-attacken

December 30th, 2009

Det verkar aldrig ta slut på uppmärksamheten kring Karsten Nohls attack på A5/1 (se tidigare bloggpostning ett och bloggpostning två). I dag har Sveriges Radio och Ekot plockat upp tråden och jösses vilket reportage det blev.

Ekots bild till artikeln.

Egentligen är Per Eurenius reportage (webbradio) från 26C3 i Berlin inte så illa, utan det är snarare påannonseringen och SRs nyhetstext som är tokfel:

Hemlig gsm-kod hackad av forskare

En tysk forskare har lyckats avslöja den kod som ska skydda mobiltrafiken i världens största telefonsystem, gsm.

Nej, SR, det är ingen kod som avslöjats, och det är inte hemligt.

Även Cryptome har uppdaterat sitt material In support of Karsten Nohl’s cracking of GSM A5 och den här sidan hos Cryptome är nog den mest kompletta samlingen av information om A5-krypton, säkerhet (eller avsaknad därav) i GSM, GPRS och UMTS.

För den som vill ha Karstens regnbågstabeller finns det nu torrentfiler.

Återanvänd text om FPGAer och säkerhet

September 11th, 2009

Myndigheten för samhällsskydd och beredskap (MSB) bildades första januari 2009 och tog då över verksamhet från Räddningsverket, Krisberedskapsmyndigheten samt Styrelsen för psykologiskt försvar. I brist på annat att göra när man ligger med en eventuell svininfluensa slösurfade jag på MSBs webbplats. En sak jag gjorde var att söka på ordet kryptering och fick då upp KBMs gamla rapportserie Nyhetsrapport – omvärldsbevakning ur ett krypteringsperspektiv.

Enligt informationsrutan i rapporterna är:

Nyhetsrapporten är utgiven av Combitech AB på uppdrag av Försvarets materielverk (FMV) och Krisberedskapsmyndigheten (KBM). Nyhetsrapporten kommer ut ungefär tre gånger per år. Tidigare utgåvor kan erhållas genom att kontakta redaktören. Innehållet fokuserar på krypto, men kan även innehålla andra säkerhetsrelaterade notiser. Nivån är övergripande för att ”alla” och inte bara branschfolk skall ha glädje av den.

Intressant nog hävdar webbplatsen ovan att: Nyhetsrapporterna är utgivna av AerotechTelub, men det är nog mest en detaljfråga. Jag tycker att rapporterna är väl värda att läsa med såväl nyheter som förklaringar av kryptografiska funktioner och begrepp. Det är synd att nyhetsrapporten snarare verkar komma ut en gång per år än tre gånger per år som informationsrutan vill göra gällande. (Kommer nyhetsrapporten att komma ut under MSBs regi också, någon som vet?)

En sak i nyhetsrapporten från april 2008 gjorde mig tyvärr lite fundersam. Rapporten innehåller ett stycke om NSA och SRAM-baserade FPGAer för kryptosystem som tar upp det arbete NSA och Xilinx genomfört – ett arbete jag bloggade om i slutet av augusti 2007 med rubriken… NSA och SRAM-baserade FPGAer för kryptosystem

I nyhetsrapportens text läser jag bland annat:

National Security Agency (NSA) och FPGA-tillverkaren Xilinx [1, 3] har genomfört ett intressant projekt vad gäller säkerhetskonstruktioner med hjälp av Field-programmable gate array (FPGA). Vad NSA och Xilinx har gjort är att både analysera säkerheten i SRAM-baserade FPGA:er samt utvecklat metoder och verktyg för att implementera system som möter NSAs säkerhetsklass Fail Safe Design Assurance (FSDA).
...
Att implementera kompletta säkerhetssystem i en FPGA:er har tidigare undvikits av rädsla för att det inte skall gå att upprätthålla röd/svart-separation [2] inne i FPGA:n, med risk för informationsläckage och säkerhetsproblem.
...
Exempel på vad NSA vill kunna implementera i en FPGA är redundanta kryptoenheter, röd/svart-separering internt på chippet och chip med funktioner som arbetar med olika säkerhetsklasser.

Hmmm…. Jag tycker att jag känner igen den där texten. Min egen bloggpostning innehåller texten:

NSA och FPGA-tillverkaren Xilinx genomfört ett i mitt tycke extremt intressant projekt. Vad NSA och Xilinx har gjort är att både analysera säkerheten i SRAM-baserade FPGAer samt utvecklat metodik och verktyg för att implementera system som möter NSAs säkerhetsklass FSDA - Fail Safe Design Assurance.
...
Att implementera kompletta säkerhetssystem i en FPGA har även det undvikits av rädsla för att det inte skall gå att upprätthålla röd/svart-separation inne i FPGA:n, med risk för informationsläckage och säkerhetsproblem.
...
Exempel på vad NSA vill kunna implementera i en FPGA är redundanta kryptoenheter, röd/svart-separering intern på chippet och chip med funktioner som arbetar med olika säkerhetsklass.

Kryptoblog är en blogg – en öppen text. Därmed är det fritt att länka och referera till vad jag skriver, och ingen blir gladare än jag om det jag skriver används för att sprida information om krypto i sverige (förhoppningsvis inte som driftkuku och exempel på tokfrans). Men om ni lånar min text får ni helst se till att tala om att ni lånat den på Kryptoblog. Tack!.

En ny kryptohöst

August 31st, 2009

Aloha!

Japp, Kryptoblog lever faktiskt.
Efter en lång, hård och slitsam vår som tyvärr gjorde mig oförmögen att blogga på flera månader börjar det ljusna, hösten till trots. Och det finns faktiskt hur mycket spännande krypto- och IT-säkerhetsprylar att skriva om som helst. Tack alla som skickat tips, kommentarer, uppmaningar och uppskattningar. Dom har värmt, även om jag inte hunnit svara eller posta.

Bloggen kommer den närmaste tiden att förändras utseende- och funktionsmässigt, skrik om du ser något fel som ser märkligt ut. Förhoppningsvis kommer det inte att vara som normalt om ett tag, utan mycket bättre.

Nu kör vi! (lite långsamt ;-)

RC4 i programspråket Lua

January 30th, 2009

Tyvärr har jag just nu väldigt lite tid, lust och ork för bloggen. Har dessutom legat sjuk i några dagar.

Det enda jag orkat med är att leka lite med programspråket Lua. Och vad kan vara bättre som kodexempel när man prövar ett nytt språk är strömkryptor RC4?

Så nu finns det en väldigt enkel och ful implementation av RC4 i Lua. Bara att tanka ner från sidan med filer för nedladdning för den som är nyfiken och vill se Lua-fulkod.

Eftersom jag kodar en hel del Python kan jag kanske våga mig på några korta jämförelser mellan Lua och Python:

  • Lua är litet och enkelt. Det går snabbt att greppa grunderna i språket. Ungefär som Python.
  • Att exekvera Lua-program verkar gå fort. Bra prestanda helt enkelt.
  • Kompilering och installation av Lua gick väldigt smidigt. Inga varningar och bra tester för att kontrollera installationen.
  • Debugutskrifter från VM:en när den stöter på fel är inte speciellt tydliga. Python kan dränka dig i kärlek och utskrifter, men det brukar alltid gå att enkelt se var, vad och varför det är fel. Lua ger ibland det något kortfattade “?” som sammanfattning.
  • Lua har inte alls samma mängd med bibliotek med i distributionen som Python. Och de som finns är inte lika välmatade och inte minst lika väldokumenterade som Pythons standardbibliotek.
  • Lua räknar index från ett inte noll. Dock kan man räkna från noll, men tydligen bara ibland. Har man vant sig att allt börjar från noll (typ C, Verilog, Python etc) och dessutom algoritmer är byggda utifrån indexeringar från noll till XYZ blir det lite trixigt att få till det.

(Gissar att jag nu kommer att få massor med ilskna kommentater om Lua…)

Implementation av Keccak i FPGA-teknologi

December 17th, 2008

Jag har precis lagt upp en artikel kallad Implementation of the Keccak Hash Function in FPGA Devicessidan med artiklar och dokument.

Artikeln beskriver en del försök jag gjort med att implementera en av SHA-3-kandidaterna, Keccak i olika FPGA-kretsar. Som utgångspunkt har jag använt de referensimplementationer i VHDL som skaparna av Keccak har tagit fram.

Att döma av resultatet verkar Keccak vara en hashfunktion som lämpar sig väl att implementera i FPGA:er. Jag gillar att den går att skala så mycket som den gör. Den minimala low_area_copro-implementationen är verkligen mycket liten ocg ger trots det bra prestanda.

Jag hade dock en del strul med referensimplementationerna vilket till största delen beror på hur VHDL-koden är skriven. Om Keccak skulle bli vald till SHA-3 kommer det att behövas en hel del uppstädning för att få koden till att bli en riktigt bra referensimplementation.

Notera att jag inte i det här läget tar ställning till säkerheten hos Keccak, utan detta är enbart ett försök att utvärdera hur effektivt det går att implementera Keccak i FPGA:er.

Jag tar mycket gärna emot kommentarer och tips.

Uppdaterad version av snow.py

November 3rd, 2008

Jag har gjort en liten uppdatering av min Pythonimplementation av strömkryptot Snow. Det jag har ändrat är två saker:

  1. Utökat test/exempelkoden med samtliga testvektorer i specifikationen för Snow 2.0

  2. Fixat en bugg i initieringen av kryptot relaterat till initialvektorn (IV)

Helt kort kan man säga att jag insåg att jag varit extremt slarvig och inte testat ordentligt med IV skild från noll. I initieringen av 128-bit nyckel med IV skild från noll genererade min version inte korrekt värden då jag missat IV-ord två (i mängden IV[0..3]). Den buggen är nu fixad.

Den nya versionen av kryptoimplementationen finns på samma plats som förut, men har fått nytt versionsnummer och uppdaterat releasedatum. Naturligtvis är även signatur och filstorlek uppdaterade.

Strömkryptot Snow i Python

October 30th, 2008

Min nya hobby att implementera krypton i programspråket Python har den senaste veckan gjort att jag pillat med kryptot Snow.

Snow är ett strömkrypto av Thomas Johansson och Patrik Ekdahl vid LTH. Den version av Snow jag implementerat är Snow 2.0 som kom 2002. Snow 2.0 var en av kandidaterna till NESSIE-projektet och har även använts som jämförelse med kandidater i eSTREAM.

Det finns en nyare version av Snow kallad Snow 3G. Snow 3G är det krypto som används som bas i algoritmerna EUA2 och EIA2 för att säkra kommunikationen i 3G. Jag har ännu inte lagt in stöd för Snow 3G. En sådan förändring skulle dock vara relativt enkel – det som krävs är väsentligen att lägga till ett extra register i FSM:en.

Snow arbetar på 32-bitars ord och kryptot består i grunden av ett skiftregister (en LFSR-kedja) med 16 steg samt en tillståndsmaskin (FSM) med två 32 tillståndsregister – R1 och R2.

Uppdateringen av LFSR-kedjan sker genom återmatning av tidigare värden som mixas samman genom två multiplikationer, vilka är implementerade med tabeller. Uppdateringen av R2-registret i FSM:en sker genom en S-box (baserad på S-boxen i AES) där indata är värdet i R1. Totalt sett finns det sex stycken tabeller i den här implementationen av Snow.

Min implementation av Python är en fristående klass med metod load_key() för att ladda nyckel och IV, samt en metod gen_keyword() för att generera nästa nyckelströmsord. Klassen stödjer både 128- och 256-bitars nyckel.

LFSR-kedjan och FSM:en är sammankopplade på ett relativt intrikat sätt och att få ordning på ordningen i uppdateringen i ett sekventiellt program visade sig vara lite klurigt. Men genom att dumpa alla interna tillstånd gick det att få ordning på sekvenserna. Min implementation av Snow inkluderar därför en metod för att dumpa interntillståndet. När ett objekt av Snow skapas går det även att ange hur pratig (verbose) den skall vara när den utför en metod.

Ett litet exempel (hämtat från exempelkoden):

my_snow = Snow(False) my_key = [0×00000000, 0×00000000, 0×00000000, 0×80000000] my_iv = [0×00000000, 0×00000000, 0×00000000, 0×00000000] my_snow.load_key(my_key, my_iv) my_snow.gen_keyword()

Detta ger (med lite utskrifter och en loop):


key:
[0, 0, 0, 2147483648L]
iv:
[0, 0, 0, 0]
running key 0: 8d590ae9
running key 1: a74a7d05
running key 2: 6dc9ca74
running key 3: b72d1a45
running key 4: 99b0a083
running key 5: fb45d13f
running key 6: cf9411bd
running key 7: 9a503783
running key 8: a98265ae
running key 9: bf2dc77f
running key 10: f2eb41e4
running key 11: aa896508
running key 12: 19d8ab8f
running key 13: 2eb8077f
running key 14: 78f8c1f1
running key 15: 9d4c5ce2

Rent och snyggt gränssnitt om jag får säga det själv, HW-nisse som jag är (så vad vet jag?).

Jag har testkört på min laptop med 2GHz Core 2 Duo-processor. Generering av 10.000.000 värden tar 135 sekunder, vilket ger ungefär 295 kByte/s. Inte kanonsnabbt, men vill man ha en ren Pythonimplementation av en applikation där det finns ett behov av att skydda data med hjälp av ett bra krypto kanske den här implementationen kan vara användbar.

Min implementation av Snow finns på sidan för nedladdning. Det finns ett par korta exempel i main()funktionen med testvektorer för 128 och 256-bit nycklar hämtade från specifikationen för Snow 2.0.

Koden är BSD-licensierad och jag hoppas att den kommer till nytta. Mycket nöje!