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 1292
May » 2008 » Kryptoblog

Archive for May, 2008

Unbound – en ny DNS-server

May 31st, 2008

I förra veckan släpptes version 1.0.0 av en ny DNS-server kallad Unbound.

Syftet med Ubound är att erbjuda ett alternativ till BIND. Unbound är modulärt uppbyggd och ger bland annat stöd för DNSSEC. Några av de grundläggande funktionerna är:

  • Dubbla stackar för IPv4 och IPv6

  • DNSSEC-validering: NSEC, NSEC3, förberedd för SHA-256

Grunden till Unbound var en prototyp i Java utvecklad av jakob Schlyter på svenska Kirei och Roy Arends på Nominet.

Koden till Unbound är BSD-licensierad och det finns webbaccess till SVN-repon.

På Unbounds sida finns en hel del dokumentation och även ett par presentationer som beskriver Unbound, bland annat den här presentationen från RIPE56.

Krypto i Vietnam

May 30th, 2008

På Cryptome dök det upp en länk till en bok publicerad av NSA som beskriver den kryptoteknik som använts i Vietnam från 1945 till 1989.

Boken A History of the Cryptographic Branch of the People’s Army of Viet-Nam, 1945-1975 with a supplement on Cryptography in the Border Guard (formerly the Armed Public Security Forces) 1959-1989 publicerades tydligen av NSA 1994. När jag sökte på boken dök den upp på en intressant sida på Wikipedia om signalspaning.

Är du intresserad av kryptohistoria kan det vara intressant att läsa igenom dokumentet. PDF:en är på 108 MByte så det tar en stund att ladda ner. PDF:en innehåller scannade sidor av boken, men det är bra kvalitet på bilderna så den går bra att läsa.

Brio lär ut epostsäkerhet

May 22nd, 2008

(Tipstack till Jakob)

BRIO (Bröderna Ivarsson, Osby) har gjort ett antal söta reklamfiler för sina Network-produkter. Även om filmerna handlar om träleksaker finns det faktiskt en del klokskap vad gäller epost i filmerna:

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…

Yubico öppnar upp sin teknologi och kod

May 17th, 2008

Svenska Yubico som utvecklar den fräcka OpenID-nyckeln Yubikey har valt att öppnat upp sin källkod.

YubiKey

Yubicos sida för utvecklare finns information och länkar till bland annat hur man sätter upp OpenID-server som använder Yubico samt API:er i .Net, Ruby, Java, PHP samt en PAM-modul för att bygga webbtjänster som kan använda Yubico för autenticiering. Slutligen finns det ett grundbibliotek i Java och C för att dekryptera och tolka de OTP-lösenord som Yubico genererar.

En kul detalj är att Yubico valt att lägga upp koden på Google Code. Vidare har Yubico valt att inte försöka vara smarta och klura till en egen, förvirrande och avskräckande licens, utan det är BSD-licens rätt av.

Yubico har även publicerat en säkerhetsanalys av Yubico utförd av Simon Josefsson, av en av Sveriges duktigaste säkerhetstekniker som arbetat mycket med design och implementation av exempelvis DNSSEC, Kerberos, OpenPGP. Väl värd att läsa.

Jag är generellt tveksam till hembyggda säkerhetsalgoritmer. Men Yubico gör nog så bra man som ett företag kan göra. Publicera inte bara resultat utan hela analyser. Inte försöka låsa in teknologin utan öppna upp API:er, kod och använda licenser som ger stor frihet. Då blir andra intresserade att titta närmare på, analysera och använda teknologin.

Jag gillar YubiKey för att den för mig som användare är så enkel att använda. Och nu är det enkelt även för utvecklare och säkerhetsanalytiker att integrera och bedöma YubiKey-teknologin. Att döma av Yubicos webbplats är deras affärsmodell att sälja YubiKey-nycklar och tjänster kring dessa, att då öppna upp teknologin borde borde vara i samklang med affärsmodellen.

Smart, bra och kul att se ett företag som grokkat hur Internet, säkerhet och öppen kod-världen fungerar.

En mycket liten AES-implementation

May 6th, 2008

I en diskussion på maillistan för NISTs AES-tävling dök det i helgen upp en länk till en söt implementation av AES skriven av Ilya O. Levin.

Ilyas implementation av AES är Byte-orienterad, vilket gör att den enkelt går att kompilera för 8-bits MCU:er. En annan udda sak med den här implementationen är att den inte innehåller en tabell för S-boxen. Istället räknar programmet ut korrekt substitutionsbyte under körning. Detta tar naturligvis tid, men eliminerar 256 Bytes. Tyvärr öppnar detta troligen även för sidoattacker.

Däremot innehåller koden funktioner för att expandera nyckeln, både för kryptering och dekryptering, och dessa räknas ut i förväg. För kryptering går det att räkna fram round-nyckeln inför respektive round, vilket skulle spara ett antal Bytes till. Och om man inte kör ECB-mod, utan en ström-mod ex CTR-mod behöver man inte ha stöd för dekryptering.

Jag har testat att kompilera koden och det går finfint i vanilj-GCC. Implementationen blir som jag förväntar mig – liten och ganska långsam. Men vill du få tag på en riktigt liten implementation av AES till ett inbyggt system, eller bara titta på hur krånglig AES blir om man försöker göra den så liten som möjligt, kan jag rekommendera att titta på den här implementationen.

Jag, Python och kryptot HC-128

May 5th, 2008

Jag har ägnat några timmar den senaste dryga veckan med att implementera eSTREAMkryptot HC128.

Målet är egentligen att skapa en IP-core-generator, dvs ett program som kan generera ett antal olika implementationer, beroende på vilken prestanda som applikationen kräver och vilken storlek på konstruktionen som är acceptabel. Som jag brukar implementera krypton på InformAsic.

När jag bygger en generator av en funktion (ett krypto en hashfunktion etc) brukar jag börja med att skriva en SW-modell utifrån specifikationen. Ja, även om det redan finns en referensmodell. Skälet är helt enkelt att när jag arbetar med att skriva modellen får jag chans att arbeta rent konkret med specifikationen, se om jag begriper den och om den är entydig.

Att bygga en första modell gör även att jag hinner tänka igenom vad en HW-implementation kommer att kräva. Få koll på minnen, register och möjligheter att parallellisera. Se vilka resurser som i en HW-implementation skulle gå att dela på etc.

Själva generatorn skriver jag numera alltid i Python med diverse egenutvecklade klasser för att skapa generatorer för IP-cores. Och SW-modellen brukar jag skriva i C.

Men den här gången tänkte jag testa att göra även SW-implementationen i Python. Eftersom jag inte är ute efter att få en SW-modell som ger maximal prestanda, utan är funktionellt korrekt och uppdelad på ett sätt som stödjer verifieringen av HW-modellerna borde Python fungera bra.

Men Python är inte riktigt som C. En sak som skiljer är vad jag kallar för Pythons butler-inställning till problemlösning. (Om du verkligen vill skjuta dig i foten ställer Python snällt upp utan att klaga, och hjälper till så att du kan skjuta dig i foten på det sätt du vill.) Detta inkluderar att anpassa variabeltyper dynamiskt. Ett exempel på detta är skiftoperatorn:


>>> kalle
42
>>> kalle = kalle < < 33
>>> kalle
360777252864L

Exemplet ovan visar hur jag skapar mig en variabel kalle och tilldelar den ett litet heltal. Sedan skiftar jag kalle bitmässigt 33 bitar åt vänster. Hade detta varit i C och kalle var en (unsigned) int hade värdet på kalle varit noll. Men Python upptäcker att hoppsan! här är vi på väg att skifta bitar över kanten, och lägger helt enkelt till fler bitar i representationen för kalle så ingen information går förlorad.

Det här är en jättebra funktion i Python som gör att man (i stort sett) helt kan ignorera vad som händer internt, utan bara räkna på med godtyckligt stora tal. Det går exempelvis utmärkt att göra så här:


>>> kalle = kalle < < 100
>>> kalle
3241325209585634862861534625792L

Väldigt mycket datalogi och elegant. Men oj vad det inte funkar när man vill pilla runt på bitar – vilket man ofta gör i krypton.

Så nu har jag fått klura ut hur jag skall arbeta runt Pythons hjälpsamhet, något Python också snällt ställer upp på. Det blir en del hjälpfunktioner för att AND:a och MOD:a, men det går framåt. Jag har även sneglat på att använda array-modulen. Över huvud taget är val av representation något jag funderat mycket på. Jag vill få en modell med bra överblick över den interna implementationen, men jag vill även få en modell som är vettig att använda, dvs den får ett bra och normalt/användbart API.

Tyvärr har jag inte helt lyckats. Jag får fram en modell av som snurrar på bra och fint. Dock får jag inte ut rätt svar enligt de testvektorer som finns i specifikationen för HC-128. Modellen är inte korrekt.

I ren desperation/ilska hackade jag då snabbt samman en implementation i C. Den modellen är, trots att den inte är skriven för någon prestanda över huvud taget riktigt snabb. Jag får drygt 3 Gbit/s på min MacBook. Problemet är att den inte heller räknar rätt…

Jag sitter alltså med två SW-modeller, en i objektorienterad iPython och en i fulkodad C. Ingen av modellerna räknar rätt, och dom räknar inte heller lika utan ger olika fel svar på samma testvektorer.

Men jag ger inte upp! Ny vecka och nya tag! Och dessutom har jag klurat ut hur en HW-implementation bör se ut – om jag nu kan få till en sådan som dessutom räknar rätt.

Ang HC-128 och HW-implementation bör jag kanske säga att även om kryptot är rasande snabbt i SW är det ett krypto med bra möjligheter både till parallellism och till resursdelning – så jag tror att en HW-implementation är intressant och kan bli mycket bra. Det är svårt att banta bort de stora registerbankarna P, Q och W, så implementationen kräver rätt mycket register. Vad man kan laborera med är mängden läsportar, och därmed hur P, Q pch Q implementeras.

När jag fått min HW-generator att fungera kommer jag att publicera lite resultat. Och när jag får jag ordning på min Python-modell av HC-128 lägger jag upp koden här på Kryptoblog.