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.

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.

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.

För den som vill titta på och använda vår IP-core finns den här. Koden är BSD licensierad. Skriven i Verilog (naturligtvis). Förhoppningsvis kommer den till nytta för att exempelvis driva FPGA-baserad test med kontrollerad, slumpmässiga indata. Det är så jag ex använder den för att testa kryptoimplementationer.

Glädjande nog fick vi en del uppmärksamhet för släppet, bland annat i Elektroniktidningen och Elektronik i Norden. Ett litet förtydligande angående Opencores och Sourceforge är att vi på InformAsic tycker att dessa är mycket bra initiativ.

Dock är Opencores en aning (lite väl) knölig att använda, både för utvecklare och användare av cores. Tittar man på många av de (ex Rudolf Usselman) som var med att starta Opencores bor deras cores i dag på andra platser även om det finns information om deras core på Opencores. En sådan lösning skulle säkert kunna fungera för oss också. Vi får se hur vi gör nästa gång, speciellt när vi snart släpper nästa öppna IP-core.

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.

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.

No related posts.

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

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!

No related posts.

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

Detta fick mig att kasta ett getöga till på min fulkod. Jag insåg snabbt att koden behövde städas upp, och i samband med det byggde jag om den till att bli objektorienterad.

Koden innehåller en klass CellularAutomata() som tar en godtyckligt lång array med ettor och nollor som representerar initialtillståndet i cellerna i den endimensionella cellautomat arrayen skapar. Klassen tar även array med åtta ettor eller nollor som representerar uppdateringsreglerna för cellerna. I mainfunktionen skapas som ett exempel en liten automat för regel 30 genom instansiering av klassen.

För den som vill testa finns koden nu på nedladdningssidan här på Kryptoblog.

Kommentarer, tips och råd är högst välkomna.

No related posts.

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

Processormodelln inkluderar i dag alla API-synliga register, flaggor och pekare. Dock finns det ingen egentlig funktionalitet för stack och interrupt. Vidare är inte de mer ortodoxa instruktionspekar, och adressberäkningarna i MOS 6502 med.

Däremot finns det stöd för att räkna cykler och instruktioner samt stega processorn en instruktion i taget. Vidare kan processorn dumpa valfri del av sitt minne. Tanken är att detta skall underlätta profilering och debuggning av assemblerprogram.

MOS6502 klarar i dagsläget av att exekvera en delmängd av alla instruktioner, och av dessa inte alla adesseringsmoder. Dock klarar den i alla fall av att köra en implementation av PRNG-delen av strömkryptot RC4:

js@sotis:>time ./rc4_MOS6502.py
Key byte 0: 2
Key byte 100000: 34
Key byte 200000: 27
Key byte 300000: ba
Key byte 400000: 56
Key byte 500000: ac
Key byte 600000: b
Key byte 700000: 9c
Key byte 800000: 6b
Key byte 900000: 20
Cycles executed: 80000000
i_ptr = 40
j_ptr = 81
acc_reg = 8a
x_reg = 8a
y_reg = 8e
carry = 0
95.658u 0.103s 1:35.97 99.7%0+0k 0+16io 0pf+0w


Körningen ovan är från ett exempelprogram som kör PRNG-delen av RC4 en miljon gånger. Assemblerkoden (som INTE är optimerad) tar 80 cykler per varv. Som synes tar körningen nästan 100 sekunder på min MacBook. Dvs jag får nästan 1 MHz(!) i klockfrekvens och drygt 10 kByte/s i kryptoprestanda. Inte snabbt, men samtidigt inte illa av en emulerad processor som körs i en emulerad miljö (Python VM).

RC4-exemplet finns med i den release som finns att tanka ner på emulatorns sida. Jag tar väldigt gärna emot kommentarer, buggrapporter, patchar och tips för att utveckla emulatorn vidare.

No related posts.

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