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
January » 2009 » Kryptoblog

Archive for January, 2009

RC4 i programspråket Lua

January 30th, 2009

Tyvärr har jag just nu väldigt lite tid, lust och ork för bloggen. Har dessutom legat sjuk i några dagar.

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

Ny version av Keccak

January 26th, 2009

Det finns nu en ny version av SHA-3-kandidaten Keccak.

Version 1.1 inkluderar ny användningsmoder och ny, mer optimerad SW-implementation. Efter att jag släppte min artikel om implementation av Keccak i FPGA har jag haft en del kontakter med skaparna av Keccak och den nya versionen av Keccak inkluderar även HW-implementation som fungerar mycket bättre.

Vita husets nya robots.txt-fil

January 21st, 2009

Boingboing berättar att i samband med att Obama tog över som president ändrades även Vita husets webbplats. En av de förändringar som skett är att filen robots.txt, vilken används för att blockera webbspindlar från att indexera sidan, har ändrats. En aning.

Den nya filen lyder kort och gott:


“User-agent: *”
“Disallow: /includes/”

Den gamla filen får dock mig att tänka på Jonas Gardells fantastiska spaning Det är kamouflaget som avslöjar en. För en snabb läsning av den drygt 2400(!) rader långa robots.txt som GWB använde gör mig väldigt nyfiken på vad det var dom försökte dölja. Några klipp:

  1. Disallow: /avianflu/text
  2. Disallow: /barney/barney/text
  3. Disallow: /barney/barneycam/text
    (Vem är Barney?)
  1. Disallow: /homeland/firstresponders/text
  2. Disallow: /homeland/hspd19/text
  3. Disallow: /homeland/progress/text
  1. Disallow: /infocus/terrorisminsurance/text
  2. Disallow:/pandemicflu/text

Nej jag tror inte att robots.txt är ett sätt att skydda information, informationen är öppen. Däremot får jag en känsla av att GWB:s stab har trott att det är ett sätt att skydda information.)

Det mest förbryllande är att de ex blockerat pressreleaser och annat som företag och organisationer publicerar för att få uppmärksamhet och brukar vilja få spritt.

Obamas stab verkar klart mer med i matchen.

Enigma i Flash

January 21st, 2009

MagnusL tipsade (för ett tag sedan) om en fin Enigma-simulator i Flash. Det som gör den här simulatorn bra är att den så tydligt visar den interna funktionen.

En annan fin Enigma-simulator är den som Terry Long skrivit. Den simulatorn är dock bara för Mac OS X.

Bra presentation om säkerheten i GSM och UMTS

January 19th, 2009

Sprang på en några år gammal men bra presentation om säkerheten i 2G- och 3G-mobilsystem.

Presentationen Design and Analysis of Cryptographic Algorithms for Mobile Communication Systems av Henri Gilbert från Orange Labs tar bland annat upp säkerheten på systemnivå såväl som algoritmer som används. Presentationen ger även en kort intro till Security Algorithms Group of Experts (SAGE), gruppen inom ETSI som arbetar med att specificera de algoritmer som används.

Om du är nyfiken på säkerheten i mobilsystem kan den här presentationen vara värd att bläddra igenom.

OpenPGP SDK 0.9 släppt

January 18th, 2009

Ben Laurie och Rachel Williams har öppnat upp en Tracwebb för deras gemensamma projet SDK, en BSD-licensierad implementation av RFC 2440.

Enligt OpenPGP SDKs webbplats bygger SDK:n på Ubuntu och Fedora samt FreeBSD och Mac OS X.

Öppen utfrågning om IPRED

January 18th, 2009

Riksdagens Näringsutskott anordnar på tidsdag 2009-01-20 (Obama-dagen) en öppen utfrågning om civilrättsliga sanktioner på immaterialrättens område.

Tid: Tisdagen den 20 januari klockan 9.30-12.00
Plats: Skandiasalen, ingång Mynttorget 1

Programmet för utfrågningen ser ut som följer:


09.30 Inledning
näringsutskottets ordförande Karin Pilsäter (fp)

09.35 Presentation av förslagen i propositionen
statssekreterare Magnus Graner, Justitiedepartementet

09.45 Civilrättsliga eller straffrättsliga sanktioner inom immaterialrätten?
professor i civilrätt Jan Rosén, Stockholms universitet

10.05 Straffrättsliga åtgärder mot immaterialrättsliga intrång
kammaråklagare Fredrik Ingblad, City åklagarkammare

10.20 Integritetsaspekter på förslagen
generaldirektör Göran Gräslund, Datainspektionen

10.35 Paus

11.00 Frågestund

12.00 (ca) Utfrågningen avslutas

Utfrågningen kommer även att visas på Riksdagens Webb-TV. Grunden för utfrågningen är Proposition 2008/09:67 Civilrättsliga sanktioner på immaterialrättens område.

rule30 IP-core släppt

January 12th, 2009

I dag släppte vi på InformAsic den cellautomatbaserade slumptalsgenerator byggd på rule30 jag byggt som öppen IP-core. Det tog lite längre tid att få ut den än jag hade hoppats, men nu blev det en bra start på nya arbetsåret.

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.

Återanvändning av AES för SHA-3

January 6th, 2009

Jag har ägnat nåra timmar åt att gå igenom alla specifikationer för de olika SHA-3-kandidaterna. En sak som blev ganska uppenbar är vilken framgång och vilket inflytande AES som krypto och designstrategin i den bakomliggande algoritmen Rijndael har fått.

Av de 55 kandidater som finns listade på ECRYPTs SHA-3-Zoo återanvänder inte mindre än 21 kandidater koncept, komponenter eller tom hela roundfunktionen från AES och Rijndael. Den lista jag slängt ihop ser ut som följer (det blir engelska nu då jag även klippt citat:

  • Abacus: MDS from AES.

  • Arirang: S-box from AES. MDS from AES for some versions of the hash.

  • Aurora: ShiftRows from AES.

  • Cheeta: “Inspired by AES

  • Echo: Stated goal to reuse as much of AES as possible (hence the
    name). Complete AES round reused.

  • Ecoh: AES “key wrap” reused.

  • Gr0stl. S-box and diffusion directly from AES.

  • JH: Differential propagation methodology from AES.

  • LANE: SubBytes, ShiftRows and MixColumns reused from AES.

  • Lesamnta: Reuse of the AES round as function F.

  • Luffa: “Based on Rijndael-like transform”

  • NaSHA: “Improved AES S-box.”

  • SANDstorm: AES S-box,

  • Sarmal: “An AES (or Whirlpool)-like nonlinear subround function g is used.”

  • SHAMATA: “uses one of the AES primitive functions MixColumns to incorporate the message into the internal state and a modified version of the AES round function to mix the internal state.”

  • SHAvite-3: “Iterates a round function based on the AES round.”

  • StreamHash: S-box based on AES S-box.

  • Tangle: Reuse of AES S-box.

  • Twister: MDS concept from Rijndael and S-box from AES. ShiftRows from AES.

  • Vortex: Based on Rijndael rounds.

  • Waterfall: Rijndael S-box.

Jag är inte helt säker på om detta är bra eller inte.

Å ena sidan är AES och dess ingående komponenter några av de mest välanalyserade som går att uppbringa. Detta faktum är något flera av kandidaternas skapare tar upp i sin motivering av sin kandidaters säkerhet. Implementationsmässigt är det dessutom bättre om samma programkod (funktioner) går att använda till flera saker. Speciellt för inbyggda system med hårda krav på liten kodstorlek är detta naturligtvis eftersträvansvärt.

Samtidigt kan jag inte släppa känslan av att vi riskerar att hamna i en monokultur – att säkerheten i alla dess olika delar (konfidentialitet, autenticitet, integritet) bygger på en eller ett fåtal algoritmer eller komponenter. Vad händer om S-boxen i AES faktiskt visar sig väldigt svag?

Vidare var den uttalande tanken från NIST att SHA-3-tävlingen skulle stimulera till nytänkande och uppmuntra till att hitta nya koncept för att bygga hashfunktioner. Att det sker ett rejält brott mot Merkle-Damgård är uppenbart, men nu är det istället AES och Rijndael. Är det bra eller dåligt?

Det verkar dock som de flesta verkligen försökt att tänka i nya banor. I min snabbläsning hittade jag för övrigt att tre kandidater (Abacus, Keccak och Luffa) bygger på de nya (relativt färska 😉 svampfunktionerna. Dessutom såg jag bara tre kandidater (Chi, DynamicSHA, DynamicSHA2) är direkta utökningar av SHA-1 och SHA-2.