Warning: Missing argument 2 for wpdb::prepare(), called in /home/stromber/public_html/kryptoblog/wp-content/plugins/wp-super-edit/wp-super-edit.core.class.php on line 109 and defined in /home/stromber/public_html/kryptoblog/wp-includes/wp-db.php on line 1222
Om Kryptoblog » Kryptoblog

Archive for the ‘Om Kryptoblog’ category

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!

rule30.py nu på nedladdningssidan

October 14th, 2008

Jag fick en fråga om jag kunde tänka mig att skicka över den Pythonkod för Stephen Wolframs cellautomat med uppdatering enligt regel 30 jag skrev om för någon dag sedan.

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.

MOS6502 – En Pythonbaserad emulator

August 29th, 2008

Jag har precis lagt upp en sida med mitt sommarhack MOS6502. MOS6502 är en enkel, objektorienterad emulator av den gamla processorn MOS 6502 skriven i Python.

MOS 6502

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.

Säkerhet i minnesbaserade hårddiskar

August 25th, 2008

IDG publicerade i dag en artikel om att Flashdiskar är en säkerhetsrisk. I artikeln är jag intervjuad, men allt jag sa i intervjun fanns det naturligtvis inte plats för. Jag vill därför här på min egen blog (där jag kan bladdra på) förtydliga det jag sa samt ta upp något av det som inte kom med i artikeln.

Det stämmer att jag anser att det är enklare att sprätta upp en Flashbaserad hårddisk (Solid State Drive – SSD) och läsa ut innehållet ur minneskretsarna än vad det skulle vara att försöka plocka ut informationen direkt från skivorna i en traditionell hårddisk. Det senare kräver bland annat klart mer avancerad utrustning och renare miljö.

Intel presenterade för några dagar sedan på IDF att de kommer med specialutvecklade FLASH-minnen för att bygga en riktigt snabb SSD, men de flesta SSD-diskar på marknaden innehåller i dag vanliga FLASH-minnen som går att proba (dvs koppla in sig direkt på kretsens ben) och läsa ut innehållet ifrån med enkel och billig utrustning.

SSD med FLASH-minnen.
En SSD med flera stycken FLASH-kretsar.

MEN för att någon skall sprätta upp din SSD och läsa ut minnesinnehållet måste du blivit av med din hårddisk. Du är kort sagt redan rökt, något jag påpekade i intervjun. Vidare bör det vara så att skälet för att en skurk skulle ge sig på kretsarna är antagligen för att det lösenordsskydd som finns i ATA-standarden (ATA Security Feature Set) är aktiverat. Men det lösenordsskyddet finns det enklare sätt att ta sig runt.

Vad det handlar om är alltså att om man gör en ren jämförelse mellan de två typerna av hårddiskar så finns det en säkerhetsteknisk skillnad. Men den här skillnaden i säkerhet mellan Flashbaserade hårddiskar och traditionella hårddiskar är marginell, troligen inte den väg en attack skulle ta och rent praktiskt inte ett hot värt att förlora speciellt mycket sömn över.

Vad som kom med i artikeln och jag tycker är bra är att jag tycker att diskkryptering är bra. Både den typ som implementeras direkt i disken och i den som finns i operativsystem (FreeBSD, Mac OS X, Windows Vista, Solaris med flera) samt via fristående applikationer exempelvis TrueCrypt.

Informationsförluster på grund av stulna eller förlorade datorer är i dag ett stort och verkligt problem, men går att i stort sett eliminera genom diskkryptering och vettig nyckelhantering. Och den dag gammal utrustning skall rensas ut behöver inte de redan hårt belastade sysadministratörerna ägna tid åt att köra scrubbing-program för att förstöra data. Dumpa nycklarna och problemet är löst. Mycket mer ekonomiskt och enklare att metodiskt hantera i en organisation.

Jag anser att om du står i valet mellan en minnesbaserad hårddisk eller en traditionell hårddisk finns det viktigare parametrar att skillnad i säkerhet. Men oavsett vilken typ av hårddisk du väljer är det bra att använda diskkryptering.

Kryptohösten är här

August 14th, 2008

Aloha!

Efter några veckors sommarstiltje har hösten kommit till Kryptoblog. Inget mer sol och bad, utan nu blir det full fart som vanligt igen. Jag har under sommaren roat mig med att läsa en hel del intressanta böcker och forskningsartiklar (finns det något mysigare att läsa i hängmattan än en forskningsartikel om kryptomoder?) och jag kommer bland annat att skriva en del om detta den närmaste tiden.

En sak jag precis lade till är en länk till Googles säkerhetsblog som jag tycker innehåller en hel del intressant information.

NXP förlorade – publiceringen godkänd

July 25th, 2008

För ett tag sedan skrev jag att kretsföretaget NXP stämt ett antal forskare i ett försök att stoppa publiceringen av svagheter i MiFare. Domstolen har kommit med sitt beslut, och NXP fick på pälsen.

Jag tycker att domstolen i sitt beslut sammanfattade situationen elegant: Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings.

Pokersajt publicerar RNG-utvärdering

June 15th, 2008

För ett tag sedan undrade cashkuler om hur pokersajters slumptalsgeneratorer fungerar.

Jag visste inte då att det faktiskt finns pokersajter som publicerar utvärderingar av sina slumptalsgeneratorer (RNG). När jag i morse Googlade på “rng evaluation” sprang jag på en sida hos Titan Poker. Dom skriver:


Titan Pokers mjukvara, utvecklad och underhållen av Playtech använder slumpgeneratorer för att säkerställa total spelintegritet.

Playtechs spelprogram innehar ett officiellt Certifikat genom RNG Evaluation från Technical Systems Testing (TST), en internationell, erkänd och respekterad Ackrediterad Testningsfacilitet (ATF).

TST har arbetat med industriella operatörer, leverantörer och regulatorer för att säkerställa att gamingprodukten fungerar på ett rättvist och säkert sätt och att det körs enligt några av de mest följdriktiga och omfattande lagstiftningar och reglerande fodringar som finns.

Institutet dom pekar på är alltså Technical Systems Testing (TST). Jag känner inte till dom, och jag hade gärna sett att man publicerade utvärderingsrapporten. Vidare är jag tveksam till om en bra slumptalsgenerator implicerar total spelintegritet (vad det nu innebär).

Men jag tycker att det är intressant att pokersajter försöker skapa trovärdighet för sina system genom att göra utvärderingar och publicera resultaten.

Kryptoblog ser konstig ut…

May 17th, 2008

Aloha!

Snabbt statusmeddelande:
Just nu ser Kryptoblog konstig ut. Jag har uppgraderat till senaste WordPress. Men det betyder att alla fixar jag gjort tidigare skall lyftas in i den nya kodbasen och det tar lite mer tid…

Snart skall allt vara som vanligt igen…

Pawal pudlar, och jag också.

April 28th, 2008

I förra veckan rapporterade Pawal att flera myndigheter inte längre plockades upp av Creeper. Tanken var då att myndigheterna börjat blockera Creeper. Denna tanke spred jag vidare.

Men nu visar det sig att det var PHP som var boven. Pawal ber om ursäkt och det gör jag också.