No related posts.

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

Inside Snow Leopard’s hidden malware protection ger en mer detaljerad beskrivning av det nya skydd mot elak kod som Apple byggt in i Snow Leopard. Enligt artikeln lagrar SL en lista med signaturer över kända elakingar i filen:
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist

Just nu innehåller den bara referenser till OSX.RSPlug.A Trojan Horse och OSX.iService men gissningsvis kommer Apple att trycka ut uppdateringar med fler definitioner via Software Update.

För övrigt finns det om jag räknar rätt inte mindre än fem olika python-wrappers för libpcap, alla med usel dokumentation. Just nu får jag inte en enda av dom att bygga eller installera i SL. Wrappern py-pylibpcap finns exempelvis i Macports, men den tokbombar på ncurses… samt Perl och Ruby?! Beroende-h-lvetet när det är som värst…

No related posts.

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

OpenSSH is the ubiquitous method of remote access for secure remote-machine login and file transfers. Many people — systems administrators, test automation engineers, web developers and others have to use and interact with it daily. Scripting SSH access and file transfers with Python can be frustrating — but the Paramiko module solves that in a powerful way.

Paramiko är en modul med en ren Pythonimplementation (dvs inget anrop till C-bibliotek, exempelvis libssl) av SSH2. Modulen är LPGL-licensierad.

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.

Intressanta algoritmer behöver både vara enkla att begripa och kunna ge stor skillnad i prestanda, genomströmning etc när funktionen flyttas från SW till HW. Utifrån detta var mitt förslag RC4 (som är enkel, men inte skalar speciellt bra i HW), XTEA, SHA-1 och SHA-2 (256).

Några andra algoritmer man borde kunna sätta i händerna på studenter är eSTREAM-kryptona Grain och Trivium. Båda dessa krypton är relativt enkla att förstå, har intressanta explicita skalbarhetsegenskaper och är välspecificerade med testvektorer, referensmodeller etc.

Sedan slog det mig att en annan, något annorlunda algoritm som skulle kunna användas är Stephen Wolframs cellautomat Rule 30.

Rule 30 är en endimensionell cellautomat som ger upphov till ett slumpmässigt (PRNG) mönster. Rule 30 används som slumptalsgenerator i Wolfram Research Mathematica. En fördel med att använda en endimensionell cellautomat är att den enkelt går att rita upp och grafiskt verifiera.

De första iterationerna av regel 30 samt de styrande tillståndskombinationerna.

En annan kul egenskap är att algoritmen är trivialt parallelliserbar, detta då alla celler kan uppdateras samtidigt. Antagligen går det att göra bra SW-implementationer, inte minst om man tar till SSE-instruktioner alt GPU-acceleration, men en ren HW-implementation blir väldigt enkel.

Jag blev så inspirerad av Rule 30 att jag satte mig ned och hackade ihop ett par implementationer. Först en version i Python (naturligtvis) för att få koll på att jag tänkte rätt. Det blev inte speciellt många rader kod, ca 20 inkl kommentarer. Och jag är säker på att om man är en riktig Pythonista går algoritmen att stampa ner till ett fåtal rader kod, ex med lite list comprehensions.

Sedan hackade jag ihop en RTL-generator (i Python) som kan generera Verilogkod för en Rule30-automat med godtyckligt antal bitar. Den genererade konstruktionen består väsentligen av ett tillståndsregister med en bit för varje cell. För varje cell finns det sedan en enbitars 8-till-1-MUX som implemeterar uppdateringsregeln.

En sak man behöver fundera på är vad som händer för första resp sista biten i arrayen. Jag har valt att göra en ring av arrayen. Detta innebär att vid uppdatering av den högsta biten tittar vi på bit 0 och tvärs om. Implementationsmässigt innebär detta två separata ledningar som går från kant till kant, inte bara lokalt mellan ett cellregisters närmaste grannar.

Jag genererade några stycken versioner av min Rule 30-konstruktion och använde sedan Alteras verktyg Quartus II för att implementera konstruktionen i en Cyclone II-FPGA. Lite resultat:


256 bitar: 687 LEs, 263 MHz
128 bitar: 344 LEs, 358 MHz
64 bitar: 128 LEs, 420 MHz
32 bitar: 64 LEs, 420 MHz
16 bitar: 32 LEs, 420 MHz
8 bitar: 16 LEs, 420 MHz


(Notera att implementationen kräver lika många register som bitar, jag redovisar dock inte det här.)

En snabb analys ger att varje MUX (samt logik för att ladda in ett användarstyrt initialvärde) implementeras med två logikelement (LE). Mellan 64 och 128 bitar ser det ut som att någon form av replikering behöver införas.

Vad gäller klockfrekvensen är 420 MHz max som Cyclone II är specad för. I en annan FPGA, ex Stratix III går det antagligen att få upp klockfrekvensen ytterliggare en bit. Eftersom uppdateringsfunktionen för resp bit består av en 8-1-MUX med ett grinddjup motsvarande ungefär tre NAND2-grindar eller en LE, blir det transportfördröjningen genom FPGA:ns switchnät som sätter gränsen för klockfrekvensen.

Nu är Rule 30 inte en kryptografiskt säker PRNG, men för att vara en PRNG som ger så bra slumpserier så att den duger för Mathematica förbrukar den väldigt lite resurser. Och med 256 PRNG-bitar varje cykel i 263 MHz får vi 67 Gbit/s! (Vilket skulle vara hopplöst att få ut på ett kort och använda utanför FPGA:n.)

Jag tänker slänga upp en version av Verilogkoden, antigen här eller hos InformAsic. Återkommer med det. Nästa steg är att att bygga ut generatorn med stöd för resursdelning, men det gör jag inte i kväll i alla fall.

Att cellautomater har försökt användas i kryptosammanhang finns det flera artiklar som vittnar om. Jag hittade en färsk sådan med titeln LCASE: Lightweight Cellular Automata-based
Symmetric-key Encryption som just tar upp Rule 30. Värd att läsa om du vill veta mer.

No related posts.

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

gen_randfiles.py gör precis detta. Mata in filnamn, antal filer och längd i Bytes och du får det givna antalet filer fyllda med slumpmässigt valda Bytes. Uppenbarligen skrivet i Python och använder Pythons random-funktion vilken bygger på Mersenne Twister.

Filen ligger på sidan med filer för nedladdning. Hoppas att det kommer till nytta för någon. Kanske till en möhippa eller nåt, vad vet jag?

No related posts.

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

Bland alla förändringar avsedda att bereda vägen för Python 3.0, with-satsen, ett nytt I/O-bibliotek och en massa andra spännande saker hittade jag ett par säkerhetsrelaterade saker värda att uppmärksamma.

En förändring jag ser fram emot är den nya modulen ssl. Tidigare versioner av Python har haft ett ganska rudimentärt stöd för SSL (vilket finns i socket-modulen). Men Python 2.6 inkluderar en helt ny modul som bygger på OpenSSL. Den nya modulen exponerar väsentligen hela OpenSSLs funktionalitet för Pythonutvecklare.

Jag har tidigare försökt bygga applikationer som processar och analyserar certifikat, men gett upp på grund av bristande stöd. Nu är det snart dags att göra ett nytt försök. Titta i dokumentationen till ssl-modulen för mer information.

Den andra nyheten var mer av en överraskning. Beta tre av Python 2.6 introducerar ett nytt sätt att hantera regulära uttryck där remodulen (som hanterar regulära uttryck) nu är en separat, specialanpassad virtuell maskin. Poängen med detta är att regulära uttryck som leder till patologiska beteenden inte riskerar att skada Pythons egen VM. Den nya reimplementationen inkluderar även en ny regex-verifierare.

Den nya implementationen har utvecklats av Google för Google App Engine och ges nu tillbaka till Python som Apache-licensierad kod. Här finns mer information om detta.

Enligt den officiella tidplanen (PEP 361) släpps den officiella versionen av Python 2.den första oktober.

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.

Nyckelhantering är en av de riktigt svåra momenten när det kommer till kommunikationssäkerhet (både design och implementation). Tanken med KeyCzar är att underlätta för applikationsutvecklare genom att tillhandahålla ett bibliotek som sköter nyckelhanteringen på ett bra sätt. Några av funktionerna som KeyCzar erbjuder är:

• Nyckelrotation och versionshantering av nycklar inkl att återkalla (döda) nycklar.


• Implementation av bra algoritmer och vettiga nyckellängder.


• Generering av initialvektorer (IV) och signaturer.


• Stöd för att kryptera/dekryptera och verifiera.


• Stöd för applikationer skrivna i Java eller Python.

Bra algoritmer och vettiga längder är vad Google själva skriver, och det låter fluffigt. Men tittar man i den utmärkta designdokumentationen för KeyCzar ser man att de använder 1024-bit DSA med SHA-1 för signering. KeyCzar stödjer även RSA OAEP med 512-2048 bitar för publik kryptering och RSA SHA-1 med 512-2048 bitar för publik signering. Vidare används AES 128, 192 och 256 med CBC-mod för symmetrisk kryptering och HMAC med SHA-1 och 256 bit nyckel för symmetrisk signering.

KeyCzar genererar X.509-fält och allt annat pill som brukar ställa till det vid implementationer. Allt du behöver göra är att skapa ett KeyCzar-objekt och sedan lita på att KeyCzar gör rätt.

Enligt Google har KeyCzar ett enkelt API. Om det är enkelt eller ej är en bedömningsfråga, men jag hade iaf inga problem att på några få minuter ladda ner, installera och sparka igång KeyCzar i en testapplikation. Google påpekar även att:

Keyczar sacrifices some flexibility in favor of safety and ease of use. Protecting developers from mistakes and handling details for them may also hide useful underlying features. Please see the NonGoals wiki page for a description of things that Keyczar is not.

Av de saker KeyCzar inte är listar Google bla att det inte är en ersättning för OpenSSL eller vara en komplett PKI-lösning.

KeyCzar började som Ben Lauris startprojekt när han började på Google. Projektet togs sedan över av Googles säkerhetsteam som nu ansvarar för utvecklingen.

KeyCzar är Apache 2.0-licensierad och finns att ladda ner (Java, Python). Här finns Java-dokumentationen och här finns Python-dokumentationen. Slutligen finns det även ett diskussionforum (en grupp) för KeyCzar. Än så länge är det dock med KeyCzar-skaparna som postat i gruppen.

Jag tycker att KeyCzar är ett bra initiativ av Google och om det fungerer som det står i dokumentationen och det inte finns en massa fel i KeyCzar är det ett bra tillskott i verktygslådan för att bygga IT-säkerhet.

En fundering: I USA är det populärt att utnämna Tsarer för olika saker. Ex finns det en cybersäkerhets-tsar. Med tanke på alla starka signaler och liknande begrepp och koncept som verkar lånas in friskt, när får Sverige sin första tsar-någonting? Eller blir den svenska varianten hertig eller baron?)

No related posts.

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