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
November » 2008 » Kryptoblog

Archive for November, 2008

Vad hände med IPETEE?

November 30th, 2008

I somras var det en del uppmärksamhet om ett förslag till opportunistisk kryptering kallad IPETEE - “Transparent end-to-end encryption for the internets ” skapat av nÃ¥gra frÃ¥n The Pirate Bay (TPB). Bland annat var det en del diskussioner mellan Matt Blaze (inlägg ett och inlägg tvÃ¥) och en av skaparna av förslaget (Olle B).

Själva IPETEE-förslaget bodde på en Wiki på webbplatsen tfr.org. Men då jag i samband med att jag kollade status för strömkryptot Salsa 20, vilket skulle användas i IPETEE försökte jag kolla in webbplatsen. Men där möts man av en 404:a. Över huvud taget verkar tfr.org inte må speciellt bra.

Är det någon som vet vad som hände med IPETEE? Blev det helt enkelt nedlagt?

Svenska Linuxföreningens yttrande om e-legitimation

November 30th, 2008

Svenska Linuxföreningen har kommit med ett yttrande angående Finansdepartementets slutrapport om säkert elektroniskt informationsutbyte och säker hantering av elektroniska handlingar. I sitt yttrande påpekar föreningen vikten av att e-legitimationen bygger på en öppen standard. Föreningen skriver:


Statens lösningar för e-legitimation har under lång tid inte alls fungerat bra. De stängda lösningar man valt har under olika perioder inte alls fungerat för användare av flera olika operativsystem. Skall en e-legitimation fungera för alla så krävs det att den är baserad på en öppen standard så att alla nuvarande och kommande plattformar kan klara av att implementera stöd för en svensk elektronisk legitimation.

Låser man fast sig i dagens system så riskerar man att få en lösning som inte är framtidssäker och där kostnaderna blir högre än genom att använda en öppen standard som befrämjar konkurrensen och leder till att många leverantörer slåss på marknaden för att erbjuda lösningar till kostnadseffektiva prisnivåer.

Jag hittar inte rapporten hos finansdepartementet, däremot hittar jag en rapport med samma titel hos Verva.

Jag håller helt med Svenska Linuxföreningen i sitt yttrande, och det av två skäl:

  1. Jag tror att öppna standarder, med ökade möjligheter till genomlysning och analys ger oss säkrare och därmed bättre standarder.

  2. En proprietär standard riskerar att ställa krav pÃ¥ användarna och meborgarna – exempelvis vilka typer av system och program som används. Därmed riskerar en proprietär standard att att stänga ute medborgare frÃ¥n att kunna kommunicera säkert pÃ¥ ett sätt jag inte tror att man riskerar fÃ¥ med en öppen standard

Jag tycker att det är bra att organisationer som Svenska Linuxföreningen engagerar sig i den demokratiska processen på det sätt de gör och hjälper till att driva fram bättre lösningar.

Säker kommunikation från förr

November 29th, 2008

På Boingboing dök det upp en länk till en sida med en helt fantastisk bild på en utrustning för att fixa säker röstkommunikation från förr:

Kryptotelefon från förr

Man förstår att hon ser så glad ut när man får använda en sån fräck pryl. Och bara 275 USD! Vad är väl Sectras Tigertelefoner mot detta?.

Maskinen verkar vara portabel då den har egen matning. Uppenbarligen används någon slags symmetrisk skramlingsteknik då maskinen behöver paras ihop med en annan maskin för att skapa en säker förbindelse. Att döma av annonsen är det Delcon Division, en gammal del av HP som sätter koden/nyckeln i maskinen. Notera att dom påpekar att koden är inlåst i deras valv.

Sökte lite på Delcon Division och fick bland annat upp länkar till gamla nummer av HP Journal från 1967 med artiklar om ultraljudsutrustning skrivet av folk från Delcon Division.

En ny implementation av J-PAKE

November 29th, 2008

I somras bloggade jag om en ny metod för lösenordsbaserat nyckelutbyte kallad J-PAKE. J-PAKE erbjuder flera ördelar jämfört med andra metoder. Dock har det fram till nu bara funnits en Java-implementation.

Googles kryptoninja och OpenSSL-utvecklaren Ben Laurie har implementerat nyckelutbytesalgoritmen J-PAKE i C som en en modul i OpenSSL. Detta gör att den som vill testa J-PAKE (givet att man har den nya modulen) nu kan använda J-PAKE direkt i OpenSSL. Ben skriver:


So, this weekend I implemented J-PAKE as a proper OpenSSL module. Plus support in s_server and s_client. You can test it like this:


openssl s_server -jpake secret
openssl s_client -jpake secret

If you want to use two different machines, as required by Mr. Churlish, then you’ll need to use the -connect option to s_client.

If you want to use it yourself, you can find example code in apps/apps.c. Look for the functions jpake_client_auth() and jpake_server_auth().

Ben Laurie har även en utmärkt blogg väl värd att läsa om man är intresserad av krypto och IT-säkerhet.

Ben Laurie
Ben Laurie från hans sida med publikationer på Google Research.

Vad Riksdagens IT-avdelning pysslar med

November 24th, 2008

Det har varit en del rabalder de senaste dagarna om Rick Falkvinges postning om att Riksdagens IT-avdelning tittar på ledamöternas trafik.

Enligt artikeln använder IT-avdelningen en proxy som trafiken måste gå igenom. Proxyn terminerar trafiken och sätter sedan upp en ny förbindelse mot de riktiga målmaskinerna. Därmed kan avdelningen titta på trafiken även om den är krypterad.

För att detta skall fungera borde det krävas att ledamöterna ställt in proxyn i sina system. Vidare borde ledamöternas webb- mail- och chatt-verktyg (etc) skrika i högan sky när inte certifikaten matchar längre stämmer. Rent tekniskt är det möjligt att göra, men det borde inte vara sÃ¥ j-kla osynligt. (Rick Falkvinge har skrivit en SÃ¥ fungerar riksdagsledamöterna-text där han tar upp att det inte behöver vara en proxy och att ledamöternas system inte behöver ändras. Men certifikaten borde larma – om ledamöterna använder vettiga verktyg)

Det dyker upp flera frÃ¥gor när jag funderar pÃ¥ detta, ingen av dom har egentligen med tekniken att göra. För det första undrar jag varför man tycker att detta krävs? Hur ser hotbilden ut och vad är det man tror sig lösa? En annan frÃ¥ga är naturligtvis pÃ¥ vilka sätt systemet kan fallera och leda till problem – och har det utvärderats när man valde att ta in lösningen? Men sedan kommer det hela ner till det alla organisationer borde ha: IT-policy.

Jag kan pÃ¥ tok för lite förvaltning för att bedöma vad som gäller – är riksdagsledamöterna att betrakta som anställda av riksdagen? Finns det en IT-policy och/eller en IT-säkerhetspolicy som ledamöterna skrivit pÃ¥? Vad stÃ¥r det i den/de dokumenten och är dom offentlig handling?

Är det sÃ¥ att ledamöterna är att betrakta som anställda, har läst och godkänt en (drakonisk) policy som ger riksdagens IT-avdelning och de dom rapporterar till att läsa och pilla pÃ¥ deras trafik är det bara att köpa läget. Men om det inte finns en policy – dÃ¥ är det dags att sparka bakut för snyggt är det inte.

Mer om HDCP, DRM och media på nätet

November 20th, 2008

Nyheten om att Apple infört HDCP, vilket jag bloggade om i går, har i dag uppmärksammats av Cory Doctorow på Boingboing. Inte mycket nytt förutom att Doctorow påpekar att med HDCP kan tidigare fungerande enheter, exempelvis skärmar kan klassas om osäkra och spärras för att användas att spela upp media. Doctorow skriver:


Buying an Apple computer? Get ready to throw away your monitor, over and over again. New Apple hardware is shipping with “HDCP” anti-copying technology that prevents showing some video on “non-compliant” monitors. Best part: the list of “compliant” monitors will change over time: the monitor you buy today can be “revoked” tomorrow and stop working.

Doctorow har skrivit mycket om DRM-system och upphovsrätt samt hur artister och författare skall agera i en digital verklighet. Doctorow har samlat texterna i boken Content.

Content

Jag läste boken förra veckan och tycker att den var mycket bra, även om den i mÃ¥ngt och mycket upprepade samma argument flera gÃ¥nger. Doctorow som den författare han är fokuserar dessutom mycket pÃ¥ just böcker, inte lika mycket pÃ¥ film och musik. Men en sak Doctorow gör är att han vÃ¥gar stÃ¥ för sina Ã¥sikter och därför finns hans böcker att tillgängliga pÃ¥ nätet – CC-licensierade. SÃ¥ tag inte min uppfattning som sanning – läs boken själv.

En annan intressant sak som kommit på Boingboing är att det faktiskt finns de inom musikindustrin som verkar ha sett ljuset och argumenterar mot DRM-system, mot att behandla sina kunder som skurkar och att fokusera på musik, inte CD-försäljning. Ian Rogers som bland annat skapat Topspin höll en keynote-presentation väl värd att titta närmare på.

Ian Rogers

Några som definitvt verkar ha sett ljuset är Monty Python:

Kolla in fantastiska Monty Python-kanalen på YouTube.

Monty Python Channel

Förhoppningsvis går det bra med Pythons satsning på nätet. Funkar det för dom kanske fler vågar kanske fler artister och skapare följa efter.

Utveckling av och säkerhet i Mac OS X

November 19th, 2008

På Macrumors kom det i dag en länk till en intressant presentation av FreeBSD-grundaren Jordan Hubbard (JKH), numera Director of UNIX Technology hos Apple, om utvecklingen av och säkerheten i Mac OS X. Jordans presentation innehåller en hel del information om de olika releaserna som kommit av OS:et, hur mekanismer som kodsignering, Sandboxing och andra skyddsmekanismer som introducerats.

Presentationen tar även upp lite om kommande mekanismer i Snow Leopard, speciellt stödet för GPU-accelererade beräkningar, multicore och OpenCL.

En detalj som uppmärksammades pÃ¥ Macrumors är att Jordans presentation ser ut att precisera när Mac OS X 10.6 – Snow Leopard kommer att släppas – första kvartalet 2009.

Releasedatum.

I en annan nyhet på Macrumors berättas det att det verkar som att Apple har integrerat stöd för DRM-systemet HDCP i de nya MacBook och MacBook Pro-modellerna som kom för några veckor sedan. Tydligen är det en användare som plötsligt fick upp en ruta om att han inte fick spela upp sin film på med syn nya laptop:

Blockerad film.

Tråkigt att se att Apple verkar ha valt att gå den här vägen.

Lite SHA-3-nyheter

November 18th, 2008

NIST meddelade för några dagar sedan att de fått in 64 kandidater och att det kommer att dröja till i början av december innan NIST presenterar vilka kandidaterna är. Även om antalet kandidater är mindre än de minst 80 kandidater Bruce Schneier gissade på är det väldigt många.

Även om inte NIST publicerat listan med kandidater finns det en Wikisida kallad The SHA-3 Zoo som listar 28 stycken av kandidaterna inklusive länkar till artikel, webbplatser samt kandidaternas status vad gäller attacker. För attacker och kryptanalysresultat har redan börjat dyka upp.

På den maillista som NIST satt upp är det sedan en tid tillbaka en relativt hög aktivitet med postningar av resultat och diskussioner av hur dessa skall tolkas. Bland annat var några så ivriga att få in ett resultat att de publicerade en attack på kandidaten EnRUPT som är sämre än uttömande sökning. När de sedan fick kritik kom de med följande kommentar som låter väldigt mycket som First Post! på diverse forum:


We started working on the function yesterday. As soon as the paper was finished we sent a message.

Känns inte helt seriöst. Dock gav detta upphov till vad som skall klassificeras som en riktig attack – om attacker som tar längre tid eller kräver mer minne än atomer i hela universum skall anses som allvarliga attacker eller ej. Daniel J Bernstein kom för nÃ¥gra dagar sedan med ett riktigt elegant debattinlägg:

2^185 preimage attack on MD6-256


After the recent flood of attacks on hash functions that I had never heard of before this month, I’m pleased to announce that I’ve found an attack on MD6-256 with time complexity just 2^185.

The attack is a “multiple-preimage attack” that simultaneously attacks 232 legitimate target signatures and successfully forges at least one signed message by finding a preimage of the underlying hash. Surely there will be more than 232 signatures generated using SHA-3, so this
is a realistic attack scenario if MD6 is being considered for SHA-3.

Recall from Rivest’s description of MD6 at Crypto that computing MD6 takes a fraction of a millisecond on a single CPU core. The total time for the attack is under 2^185 milliseconds—-I’m talking about actual wall-clock time, not some simplified model. The attack doesn’t fit on a single PC, but is easily implemented on a large cluster of a billion current Core 2 Quad PCs. Memory consumption per PC is negligible. Special-purpose hardware will be even less expensive.

The attack isn’t guaranteed to succeed; a detailed analysis shows that it has only about 1 chance in 100 of succeeding. However, repeating the attack will increase the success probability, and in any event I think we can agree that 1 chance in 100 is already an unacceptable threat for
SHA-3 users. Can we please kick MD6 out of the hash competition now?
—-D. J. Bernstein

Research Professor, Computer Science, University of Illinois at Chicago

P.S. Preliminary analysis suggests that, astonishingly, Skein and Keccak will both succumb to analogous attacks, and that the attack on Skein will be even faster than the attack on MD6. Who would have imagined that three hash-function designs with such different design principles would share a critical weakness?

Räknar man samman vad Bernsteins attack, som har motsvarande upplägg som några av de attacker som kommit på maillistan, ser ut att klara får man en attack på 2^256, dvs uttömande sökning (brute-force).

Det har kommit ett par ordentliga attacker. En av de första att falla var kandidaten NK2SD som är något så ovanligt som en hashfunktion baserad på en tvådimensionell cellautomat inspirerad av Stephen Wolframs A New Kind of Science:

Cellautomater
(Fina figurer från NK2SD-automater)

Just nu listar SHA-3 Zoo åtta stycken kandidater som i någon variant har attackerats. Dock verkar SHA-3 Zoo, NISTs egen maillista och andra aktiviteter leva ett eget liv utanför NISTs kontroll. NIST har gjort klart att inga kandidater i detta läget är borträknade. En sidoaktivitet som pågår är ECRYPTs eBASH där man kör och presenterar prestandatester av alla kandidater. Att döma av resultaten så här långt, med enbart ett fåtal kandidater är det ingen som framstår som snabbare än SHA-2. Ett problem med SHA-2, och tävlingen är tänkt att lösa är just att SHA-2-algoritmerna är så mycket långsammare än SHA-1.

En annan aktivitet är insamling av information om implementationer av kandidater i hårdvaraASIC eller FPGA. En av snabbaste ser ut att vara Keccak. Keccak har jag bloggat lite om tidigare och även om den svampfunktion som ligger till grund för funktionen. Kul att se att den verkar ge bra prestanda.

Jag har läst igenom de flesta artiklar som presenterar de (sÃ¥ här lÃ¥ngt kända) kandidaterna. Att presentera resultat om hÃ¥rdvaruimplementationer av sin kandidat verkar vara en trend bland kandidaterna. En annan trend jag tycker mig se är att beskriva skydd mot sidoattacker – Ã¥terigen en implementationsaspekt. BÃ¥de intressant och bra att se att de senaste Ã¥rens sidoattacker börjar slÃ¥ igenom och bli nÃ¥got som beaktas vid design av nya algoritmer.

Sättet som flera av kandidaterna hanterar problematiken med sidoattacker är att gÃ¥ mot enkla grundunktioner – baserade pÃ¥ XOR, rotationer och bitskiftningar samt additioner. Desa grundfunktioner upprepas seda ett (mycket) stort antal gÃ¥nger. Typiskt används inga S-box-liknande strukturer. NÃ¥gra exempel pÃ¥ detta är MD6, Skein (som bygger pÃ¥ Trieefish-kryptofunktionen) och Cubehash.

Påfallande många kandidater försöker även gå ifrån Merkle-Damgård-konstruktionen och mot helt nya principer för att bygga kompressorfunktioner och hashfunktioner. MD6, Keccak och NK2SD är exempel på detta.

Väsentligen alla kandidatbeskrivningar innehÃ¥ller mer eller mindre ordentliga beskrivningar om kandidatens säkerhet och skydd mot olika attacker. Men flera av kandidaterna, bland annat MD6 och Skein innehÃ¥ller bevis – alltsÃ¥ att algoritmen är bevisbart säker. Det skall bli intressant att se huruvida dessa bevis visar sig stämma, och om de antaganden och de villkor under vilka bevisen gäller hÃ¥ller.

Skaparna av kandidaten Skein, skapad av bland andra Bruce Schneier, Niels Ferguson, Stefan Lucks och Doug Whiting, sticker ut för att de har använt ett något annorlunda sätt att argumentera för sin algoritms säkerhet:


Skein was designed by a team of highly experienced cryptographic experts from academia and industry, with expertise in cryptography, security analysis, software, chip design, and implementation of real-world cryptographic systems. This breadth of knowledge allowed them to create a balanced design that works well in all environments.

Är Security by Authority en vettig term för den här typen av säkerhet tro?

Om någon undrar vad Skein betyder är det tydligen ett garnnystan, vilket är en bra liknelse för hur Treefish-funktionernas in- och utdata i Skein slingrar sig runt varandra.

Skein

Jag räknar med att återkomma med mer info om NISTs tävling när de presenterat samtliga 64 kandidater. Sedan lär det dröja några år innan jag får reda på om min gissning stämmer.

Uppdaterad eSTREAM-portfölj och nya attacker

November 17th, 2008

eSTREAM-projektet presenterade sin portfölj med strömkrypton i april i år. Portföljen som då presenterades inkluderade fyra krypton i profil ett avsedda i första hand för SW-implementation och fyra krypton i profil två avsedda för inbyggda system och hårdvaruimplementationer. Dessa krypton var:

Profil ett:

  • HC-128

  • Rabbit

  • Salsa 20/12

  • Sosemanuk

Profil två:

  • F-FCSR-H v2

  • Grain v1

  • Mickey v2

  • Trivium

Sedan april har det hänt en del. Det mest direkta är att eSTREAM-portföljen har uppdaterats med den stora förändringen att F-FCSR-H plockats bort från profil två.

Skälet till detta är att Hell och Johansson skrivit en artikel kallad Breaking the F-FCSR-H stream cipher som tydligen visar en praktiskt genomförbar artikel mot F-FCSR-H. Artikeln skall presenteras på Asiacrypt i december, men tydligen stämmer resultatet då eSTREAM valt att plocka bort F-FCSR-H.

Några andra eSTREAM-krypton som inte ser ut att må speciellt bra är Trivium och Salsa 20, speciellt Trivium ser ut att må dåligt.

I höstas kom Adi Shamirs kubattack som i artikeln innehåller en allvarlig attack mot Trivium. Under hösten har även kommit ett par andra attacker mot Trivium.

I oktober kom artikeln Transforming chosen IV attack into a key differential attack: how to break TRIVIUM and similar designs med en komplexitet på 2**68.

En annan artikel, Slid Pairs in Salsa20 and Trivium, som attackerar både Trivium och Salsa 20 kom i slutet av september. Författarna Deike Priemuth-Schmid och Alex Biryukov skriver:


The stream ciphers Salsa20 and Trivium are two of the finalists of the eSTREAM project which are in the final portfolio of new promising stream ciphers. In this paper we show that initialization and key-stream generation of these ciphers is slidable, i.e. one can find distinct (Key, IV) pairs that produce identical (or closely related) key-streams.

There are 2**256 and more then 2**39 such pairs in Salsa20 and Trivium respectively. We write out and solve the non-linear equations which describe such related (Key, IV) pairs. This allows us to sample the space of such related pairs efficiently as well as detect such pairs in large portions of key-stream very efficiently.

We show that Salsa20 does not have 256-bit security if one considers general birthday and related key distinguishing and key-recovery attacks

Det ser allvarligt ut, men läser man Daniel J Bernsteins svar verkar det inte vara en attack som är bättre än brute force:


These claims are entirely without merit. The “attacks” on Salsa20 are vastly more expensive than the standard brute-force attacks discussed in the original Salsa20 documentation.

Vad gäller Trivium, med tre olika attacker på kort tid, skulle jag inte bli förvånad om den åker ut ur eSTREAM-portföljen och jag skulle vara försiktg att använda den.

Det som gör mig en aning bekymrad är att flera attacker alltsÃ¥ dykt upp strax efter att eSTREAM-projektet avslutats och porföljen presenterats – efter fyra Ã¥r av utvärderingar.

Om man vore lite konspiratoriskt lagd skulle man kunna fÃ¥ för sig att det är mer prestige och publiceringsvärde i att attackera accepterade och utvalda algoritmer snarare än kandidater. Detta är naturligtvis rent trams, men om det skulle vara sÃ¥ vore det bekymmersamt för forskningen och andra försök att ta fram bra algoritmer – exempelvis för NISTs SHA-3-tävling.

En sista sak om eSTREAM värd att notera är att kryptot Rabbit, enligt en postning av Erik Zenner på eSTREAM-forumet, har fått ändrad licens:


On behalf of Cryptico A/S, the company who designed the Rabbit stream cipher, I’m happy to relay the following:

“Rabbit has been released into the public domain and may be used freely for
any purpose.”

So in retrospect, I think that it was a good decision not to make patent issues a key criterion for the eStream portfolio: The patent status can change, the algorithmic properties can’t.

Tyvärr är inte detta det mest officiella av uttalanden, och dessutom saknar jag information om hur Cryptico avser att agera vad gäller sina patent relaterade till Rabbit. Jag har letat på Cryptico A/S webbplats för att hitta ett mer officiellt uttalande, men där finns inte mycket nyheter.

Jag har kontaktat Erik Zenner för att se om det går att få ett mer officiellt uttalande. Hör jag något publicerar jag det här. eSTREAM-projektets text om licensen för Rabbit har i alla fall inte uppdaterats:


Cryptico A/S currently has patents pending on Rabbit. The algorithm is provided royalty-free for non-commectical use. Licenses for commercial use may be obtained from Cryptico A/S.

Om jag själv skall välja krypton från eSTREAM skulle jag i första hand gå på HC-128 och kanske Salsa 20. I profil två skulle jag välja Grain och Mickey, men då använda versionerna med 128 bit nycklar som inte kostar mer i implementation (bortsett från sex Bytes längre nyckel). Inbyggda system förtjänar lika bra skydd som PC-system.

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.