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

Archive for December, 2008

Tekniken bakom Microsofts BitLocker

December 31st, 2008

För ett några månader sedan postade jag om NISTs föreslagna kryptomod XTS. I en kommentar till den postningen satte Blackadder mig på spåret (stort tack!) på Micrsofts diskkryptering BitLocker och dess diffusor Elephant.

Kryptering av ett block med BitLocker.
Bitlockers olika delar med en blocknyckelgenerator, diffosorer och CBC-AES.

Jag har tid efter annan postat om olika artiklar och ibland ondgjort mig över hur dåliga en de artiklar är. Ett sådan exempel var artikeln om fysiskt unika funktioner som ett sätt att skydda FPGA-konstruktioner.

Därför är det kul att kunna peka på en i mitt tycke riktigt bra artikel nämligen Niels Fergusons artikel den tekniska beskrivningen av kryptosystemet i BitLocker.

Det finns flera anledningar till att Fergusons artikel är så bra. Bland annat är den tydlig i sin beskrivning av den hotbild som BitLocker är tänkt att skydda emot och användningsfallen för BitLocker. Utifrån detta följer en ordentlig genomgång av olika befintliga lösningar och varför de på olika sätt inte fungerade utifrån kravbilden. Slutligen en beskrivning av resultatet och vilka avvägningar som gjorts. Dessutom är artikeln ovanligt välskriven och lättläst.

Som läsare blir det enkelt att följa med och artikeln visar även hur säkerhetsmekanismen i ett system som BitLocker designats så att information om hur det är konstruerat (och varför) inte kortsluter säkerheten, utan istället öppnar upp för analys och förtroende för mekanismen. Att Microsoft valt att gå den här vägen är mycket positivt.

Det finns även en läsvärd artikel om BitLocker på gamla hederliga programmeringstidningen Dr Dobb’s webbsida.

Jag hade naturligtvis tänkt att posta om Elephant och BitLocker redan i September, men hösten har varit mer än lovligt upptagen. Förhoppningsvis blir det mer tid för kryptostudier och postningar på Kryptoblog. Vi ses på andra sidan nyår – Gott nytt år!

Lite SHA-3-status

December 31st, 2008

Aktiviteterna med SHA-3 rullar på även under jul och nyår.

Randall Farmer har publicerat en ny version av Skein som använder SSE2-instruktioner i 32-bitmod för att accelerera algoritmen. Den nya koden når 23 cykler/byte. Jag testade lite snabbt att kompilera och köra koden på min Macbook.

Koden kompilerade utan några som helst problem och med O3optimering fick jag följande timingresultat (2 GHz Intel Core 2 Duo med 4 MByte cache och 2 GByte RAM kompilerad med i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5488)):

#/usr/bin/time ./skein
75.32 real 74.89 user 0.17 sys

Jean-Philippe Aumasson har publicerat en ny, hårdbantad version av BLAKE-32. Den nya koden är på ca 200 rader, ca 6 kByte källkod inkl kommentarer. Denna kod är dock ej avsedd för att nå hög prestanda.

Vad gäller analysstatus har följade kandidater så här långt fallit:


Boole
DCH
EnRUPT
HASH 2X
MCSSHA-3
NKS2D
Ponic
Sgàil
Spectral Hash
Vortex
WaMM
Waterfall

Notera att NIST än så länge inte eliminerat dessa från kandidatlistan, utan det är på maillistan sha-forum och webbsidor som Skeins Engineering Comparison och ECRYPTs SHA-3 Zoo denna information kommer ifrån.

I vissa fall har skaparen av hashfunktionen (Waterfall och WaMM) officiellt dragit tillbaka sin kandidat, men i andra fall (EnRUPT) pågår diskussioner om att försöka hitta modifieringar för att reparera kandidaterna mot upptäckta problem.

Implementation av Keccak i FPGA-teknologi

December 17th, 2008

Jag har precis lagt upp en artikel kallad Implementation of the Keccak Hash Function in FPGA Devicessidan med artiklar och dokument.

Artikeln beskriver en del försök jag gjort med att implementera en av SHA-3-kandidaterna, Keccak i olika FPGA-kretsar. Som utgångspunkt har jag använt de referensimplementationer i VHDL som skaparna av Keccak har tagit fram.

Att döma av resultatet verkar Keccak vara en hashfunktion som lämpar sig väl att implementera i FPGA:er. Jag gillar att den går att skala så mycket som den gör. Den minimala low_area_copro-implementationen är verkligen mycket liten ocg ger trots det bra prestanda.

Jag hade dock en del strul med referensimplementationerna vilket till största delen beror på hur VHDL-koden är skriven. Om Keccak skulle bli vald till SHA-3 kommer det att behövas en hel del uppstädning för att få koden till att bli en riktigt bra referensimplementation.

Notera att jag inte i det här läget tar ställning till säkerheten hos Keccak, utan detta är enbart ett försök att utvärdera hur effektivt det går att implementera Keccak i FPGA:er.

Jag tar mycket gärna emot kommentarer och tips.

Faran med minnesbaserade hårddiskar

December 15th, 2008

För ett tag sedan bloggade jag om en IDG-artikel som tog upp säkehetsproblemet med minnesbaserade hårddiskar. Då handlade det om huruvida det är svårare eller enklare att komma åt information som är lagrad på hårddisken.

I går kom det ett par inlägg på Cryptography-listan som satte fingret på ett helt annat, och mycket intressant problem: Att hårddiskar används som entropikälla för att driva slumptalsgeneratorer (PRNG) i operativsystem.

James A Donald skrev i ett inlägg om entropikällor för slumptalsgeneratorer:


If one uses a higher resolution counter – sub microsecond – and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true
random.

Ett inlägg Damien Miller svarade på med:


Until someone runs your software on a SSD instead of a HDD. Oops.

Japp, Oops är helt rätt. Hur många OS använder hårddiskens accesstider som entropikälla, och hur många tänker på att entropikällornas beteende ändras när man byter teknik som det här? Jag har iaf inte tänkt på det innan.

En annan sådan källa som förekommer är tid mellan inkommande frames på Ethernetportar. Min magkänsla säger att trenden mot att skapa virtuella nätverk mellan virtualiserade servrar borde göra att den källan till entropi blir mindre värd att lita på. Över huvud taget borde virtualisering innebära problem för entropikällor då poängen med virtualisering är att ersätta fysisk hårdvara med programimplementationer.

Vad tror du?

NIST publicerar lista på alla SHA-3-kandidater

December 10th, 2008

NIST postade för några minuter sedan till den maillista som finns för SHA-3-tävlingen att det nu finns en sida med alla kandidater man accepterat. NISTs Bill Burr skriver om kandidaterna:


NIST received 64 SHA-3 candidate hash function submissions. Overall, NIST is very pleased with the obvious high quality of many of the submissions, as well as the general range of designs. NIST has accepted 51 first round candidates as meeting our minimum acceptance criteria. They are now posted on the NIST website

Den publicerade listan med kandidater ser ut så här:


Abacus
ARIRANG
AURORA
BLAKE
Blender
Blue Midnight Wish
BOOLE
Cheetah
CHI
CRUNCH
CubeHash
DCH
Dynamic SHA
Dynamic SHA2
ECHO
ECOH
EDON-R
EnRUPT
ESSENCE
FSB
Fugue
Gröstl (New spelling: Grøstl)
Hamsi
JH
Keccak
Khichidi-1
LANE
Lesamnta
Luffa
LUX
MCSSHA-3
MD6
MeshHash
NaSHA
SANDstorm
Sarmal
Sgàil
Shabal
SHAMATA
SHAvite-3
SIMD
Skein
Spectral Hash
StreamHash
SWIFFTX
Tangle
TIB3
Twister
Vortex
WaMM
Waterfall

I listan som NIST publiceras visas bara namnet på en av skaparna av respektive kandidat, men att döma av den listan finns det inget svenskt bidrag. Jag skall gå igenom listan mer i detalj och återkommer.

NIST skriver i sin postning lite mer om planerna för tävlingen:


We will review these first round candidates at the first SHA-3 Candidate Conference on February 25-28, 2009 at Leuven. During the summer of 2009 we plan to select about 15 second round candidates for more focused review at the Second SHA-3 Candidate Conference, tentatively scheduled for August, 2010. Following that second conference we expect to select about 5 third round candidates (or “finalists”). At our third conference we will review the finalists and select a winner shortly thereafter. At each stage we will do our best to explain our choices.

The Federal Register announcement specified minimum acceptability requirements for “complete and proper submissions.” These requirements included provisions for reference and optimized C code implementations, known answer tests, a written specification and required intellectual property statements.

NIST har uppenbarligen haft en del bestyr med att få ordning på kandidaterna, och har en del kommentarer om kod, specifikationer etc. Problem på dessa punkter var anledningen till att en del kandidater ej kom med. NIST skriver:


We asked for reference code and optimized 32 and 64-bit code. Some submissions did not include optimized implementations, so we will use the performance results from the reference implementations in our future deliberations. Some submissions were rejected because C code was not provided. NIST specified a specific API for the C code, and a few submissions did not use that API: these submissions were also rejected. In some cases, we made a number of minor corrections to the submitted code (largely in the include statements) in order to allow it to compile and run, but made no major repairs.

NIST attempted to verify that the submitted C programs gave outputs that corresponded to the submitted known answer test results when compiled and run on our reference platform. In several cases there were discrepancies between the known answer test results NIST got on our reference platform, and the known answer test results provided by the submitters. NIST will notify those submitters, and these discrepancies must be resolved in a timely manner if the submission is to be eligible to become a second round candidate.

We also asked for documentation, including a complete specification of the algorithms, known answer test results, a performance analysis on different platforms and a security analysis. The quality of the submitted documentation varied greatly. For the security and performance analyses, we were very liberal in what we accepted. We had difficulty determining that the algorithm specifications were complete in some cases. In some of these cases necessary information, such as initial values or padding rules, were omitted from otherwise well-written specifications, but we were able to easily determine this information from the code; these specifications were considered acceptable, since independent implementers can find what they need and the specification can be easily fixed. Some written specifications were incomprehensible without a careful examination of the C code; the more extreme cases were rejected. Inevitably, there were cases between the two extremes. There were several submissions which we accepted that required us to rely more on the programming code for clear understanding than we liked.

We expect that the algorithms selected as the SHA-3 finalists will have specifications that will allow independent implementers to program or design hardware that will produce results that match those provided by the submitters for the known answer tests. In the AES competition, Brian Gladman and others provided independent implementations of all the finalists. Marginal, hard to follow specifications may affect whether a submission is selected for the second round.

We reviewed the intellectual property statements for all of the submissions. While there remain minor issues in some of the statements, we believe that all the accepted submissions include IP statements that allow us to continue the evaluation process for those submissions for now. However, any IP statement issues must be fully resolved before a candidate can progress to be a second round candidate.

Slutligen noterar NIST att det pågått och pågår en febril aktivitet med kandidaterna utanför NISTs kontroll och NIST kommenterar SHA-3-Zoo:


Many of the accepted submissions have been posted on the SHA-3 Zoo site for some time, and a number have been analyzed and are claimed to be “broken.” In some cases, the submitters have conceded the break. In other cases, the submitters concede the break, but claim that it can be fixed with trivial changes (e.g. by adding a few rounds). In still other cases, it appears that the breaks are fundamental and cannot be fixed without extensive modifications. NIST does not want to spend time in the upcoming SHA-3 conference on accepted, but broken algorithms, unless the break is disputed, or the fix is truly trivial. On the other hand, there has been considerable discussion about what is considered to be a break, and we expect to continue that discussion in Leuven. We also expect to discuss allowing submitters to use their “tunable parameter” to make changes to their algorithm before the second round candidates are chosen.
We will continue to consider submissions where there is a dispute about whether the submission is in fact broken until we can make a determination about the facts of the case.

Lite om OAuth

December 7th, 2008

Via Googles säkerhetsblogg sprang jag på ett projekt kallat OAuth. Vad är nu OAuth? Google ger en bra förklaring:


This standard is designed to provide a secure and privacy-preserving technique for enabling specific private data on one site to be accessed by another site. One popular reason for that type of cross-site access is data portability in areas such as personal health records (such as Google Health or Microsoft Healthvault), as well as social networks (such as OpenSocial enabled sites).

Eller som OAuth-projektet skriver på sin webbplats:


If you’re building…

* desktop applications * dashboard widgets or gadgets * Javascript or browser-based apps * webpage widgets

OAuth is a simple way to publish and interact with protected data. It’s also a safer and more secure way for people to give you access. We’ve kept it simple to save you time.

If you’re supporting…

* web applications * server-side APIs * mashups

If you’re storing protected data on your users’ behalf, they shouldn’t be spreading their passwords around the web to get access to it. Use OAuth to give your users access to their data while protecting their account credentials.

Googles Gadget-plattform har stöd för OAuth, version 1.0 av specen är spikad och det finns bibliotek för bland annat PHP, Rails, Python, .NET, C, och Perl.

VISA-kort med inbyggd kodgenerator

December 7th, 2008

New York Times skriver om en ny typ av VISA-kort som innehåller en generator för engångskoder. Kortet är utrustat med ett numeriskt tangentbord samt en display.

VISAs kort.

När en kod skall genereras används tangentbordet för att mata in den PIN-kod som autenticierar dig mot kortet. Kortet genererar en engångskod, vilken visas på displayen. Den genererade koden används för att elektroniskt autenticiera kortet.

Konstruktionen motsvarar alltså det ex SEB och Swedbank åstadkommer med sina dosor från Vasco, men nu behöver man inte släpa runt på dosan (jag har aldrig upplevt att det är speciellt betungande) då den finns i kortet.

Jag tycker att detta är en mycket smutt lösning. Dock tycker jag att jag sett liknande teknik förut, bland annat från svenska Cypak.

Patetiskt phisingförsök mot LTU

December 5th, 2008

Aloha!

Som gammal student från ypperliga Luleå tekniska universitet (LTU) hamnade följande mail inte momentant i bitrymden:


Bäste Luleå tekniska universitet Webmail ägaren,
Det här meddelandet är från Luleå tekniska universitet för alla
Luleå tekniska universitet Webmail owners.We för närvarande uppgradera vår databas
och Webmail center.We vill ta bort alla oanvända Luleå tekniska universitet Webmail för att skapa mer utrymme för nya.
För att förhindra att ditt konto från att avsluta måste du uppdatera den
nedan så att vi vet att det är en present som används konto.
Bekräfta din e-postadress nedan
E-postadress :..................
Användarnamn :.......................
Lösenord :........................
Server :.........................
Födelsedatum: .................
Land eller område: ..........
Varning! E-ägare som vägrar att uppdatera sin
E-post, inom sju dagar efter mottagandet av denna varning kommer att förlora sin
E-post permanent.
Tack,
Luleå tekniska universitet Team.

Jag hoppas att ingen går på ett sådant taffligt försök. Jag gillar speciellt Bäste Luleå tekniska universitet Webmail ägaren, det härliga användandet av we samt att de vill veta att det är en present(!). Har man inte redan där insett att det är en bluff borde frågor om land eller område få klockorna att ringa.

Trodde inte att phishingförsök fortfarande var så här taffliga, Nästan lite gulligt.

Första SHA-3-konferensen utlyst

December 5th, 2008

NIST har meddelat att den första konferensen om SHA-3-kandidater kommer att arrangeras i anslutning till konferensen Fast Software Encryption (FSE) 2009. Konferensen hålls 22-25 februari i Leuven i Belgien.

Det börjar samtidigt bli allt mer uppenbart att NIST blivit något överväldigad av alla kandidater som dom fått in. Fortfarande har NIST inte ens presenterat en lista över mottagna kandidater och NIST skriver i utlysningen av konferensen att:


It appears that the number of accepted submissions will considerably exceed the number that NIST and the community can analyze thoroughly in a reasonable time period. NIST is considering ways to involve the cryptographic community in quickly reducing the number of submissions to a more manageable number. The process and criteria for this selection will be a major topic of this conference.

Även Bruce Schneier tar upp det stora antalet kandidater i ett inlägg på sin blogg som egentligen handlar om uppdateringar av sin kandidat Skein. I postningen pekar Schneier bland annat på en artikel om kandidaterna och personerna som skapat dessa, bland annat Peter Schmidt-Nielsen, en 15-årig hashfunktionsutvecklare. Peters kandidat Ponic har dock redan knäckts.

Över huvud taget pågår det en febril verksamhet för att knäcka de kandidater som är kända. På den maillista som finns kommer det dagligen flera postningar om attacker, analyser etc. Och återigen känns det inte som om NIST är med i matchen, utan att SHA-3-tävlingen har fått ett eget liv.

Av de nu 36 kända kandidater som finns på SHA-3 Zoo är nio kandidater knäckta och att det finns någon slags kryptanalys av ytterligare 12.

Tor VM, en virtuell Tor-proxy

December 4th, 2008

För några veckor sedan dök det upp en blänkare på Cryptography om ett nytt verktyg – Tor VM.

Tor VM logo.

Tor VM är en transparent proxy för att köra DNS och TCP-trafik genom anonymiseringsnätverket. Men i stället för att ansluta direkt till Tor körs trafiken via proxyn som snurrar i en virtiuell maskin. Vitsen med detta förfarande är enligt Tor VM:s sida:


The major advantage of running Tor VM is the protection you get from IP disclosure attacks that could leak your true IP address.

Du kan bygga Tor VM från källkoden, och det finns färdiga paket för att köra Tor VM fristående. Det finns dessutom färdiga ISO-filer som går att köra i VMware Player.

Tor VM påpekar dock att Tor är en anonymiserat nätverk, men att trafiken i sig inte är skyddad:


Tor VM will not protect you from leaking personal information while in use; please take caution in protecting your personal identity and information by not sending it across the Tor network. The use of encryption (HTTPS) whenever possible is highly recommended.