Skälet till detta är att jag sedan årsskiftet driver konsultfirman SecWorks inriktad på den typ av säkerhet jag skrivit om här på Kryptoblog. Kryptoblog kommer därför att flytta över till SecWorks och förhoppningsvis utvecklas, bli bättre och klart mer aktivt uppdaterad.

Så om du har följt med på Kryptoblog – häng med till SecWorks!

Kryptoblogs arkiv kommer att fortsätta att finnas här under överskådlig tid, men det kommer inte att hända så mycket mer här.

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.

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.

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.

No related posts.

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

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.

No related posts.

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

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.

No related posts.

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

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!.

No related posts.

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

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

No related posts.

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

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…)

No related posts.

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

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.

No related posts.

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