Det pågår även flera forskningsprojekt där man bygger upp ramverk för att på olika sätt jämföra implementationer (SW och HW) av olika kryptografiska funktioner – krypton, hashfunktioner etc. Ett sådan projekt är Athena-projektet som fokuserar på hårdvaruimplementationer. Ett annat projekt är ECRYPTs eBASH som mer tittar på SW-implementationer över ett stort antal processorarkitekturer.

Ett bekymmer med alla olika HW-implementationer är att det finns så många design- och teknologimässiga frihetsgrader. Är en given implementation optimerad för maximal prestanda eller minimal storlek? Är målteknologin en ASIC-process (och i så fall vilken processnod) eller en FPGA? Vilka teknologispecifika funktioner utntyttjas etc. Det är lätt att det blir en jämförelse mellan äpplen och päron, och kanske äpplen och köttfärslimpa.

I höstas kom artikeln Artikeln High-Speed Hardware Implementations of BLAKE, Blue Midnight Wish, CubeHash, ECHO, Fugue, Gr{o}stl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD, and Skein där man försökt hantera detta. Genom att välja samma målteknologi, samma verktygsflöde, samma metodik och implementationstategi har man försökt skapa implementationer av kandidater som skall gå att jämföra med varandra.

Rapporten ger en bra översiktlig beskrivning av samtliga HW-implementationer som skapats. Målteknologi är en 180nm Standard Cell-process (ASIC) från Faraday och man har tagit design genom syntes ned till nätlista och där gjort prestandaskattningar.

Utifrån ren prestanda når Keccak 21 Gbit/s och vinner med bred marginal:

En mer intressant blir det om man tittar på prestanda kontra storlek på implementationen:

Det verkar som de flesta kandidater ligger inom 40-60 kGates och där återfinns de fem snabbaste kandidaterna. I diagrammet ser man även hur Keccak och Luffa sticker ut prestandamässigt. Vidare är det värt att notera hur mycket mer komplexa de största kandidaterna är, och att det iaf inte ger någon prestandafördel. Om man skulle gå på dessa siffror (och utgår ifrån att säkerheten är lika hög hos alla kandidater) borde Keccak och Luffa ligga bra till samt att BMW och SIMD samt Skein sitta sämre till.

Det jag saknar nu är en bra jämförelse med SW-implementationer, ex från eBASH samt vad andra får fram för resultat av HW-implementationer (ex Athena). Visserligen riskerar det att bli äpplen och köttfärslimpa, men jag tror att den samlade bilden är viktig.

No related posts.

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

We are looking for implementations of Keccak on exotic platforms!

We offer a prize for the most interesting implementation of Keccak on: – Graphic cards/GPU
– Embedded processors, (e.g. ARM, Cell processor…)
– any other analog/digital computing device

The price consists in a Himitsu-Bako (secret box, http://en.wikipedia.org/wiki/Himitsu-Bako).

Who wins the prize will be decided by consensus in the Keccak team. We will internally use a system of points. Some hints: – Fast implementation get more points – Uncommon devices get more points

We give freedom in the way Keccak is used. It is allowed to implement, for instance, tree hashing or batch hashing (several messages hashed in parallel), instead of plain sequential hashing, to take advantage of parallel computing and get better performance.

The results and source code must be publicly available on an URL that is sent to |keccak| /-at-/ |noekeon| /-dot-/ |org| before June 30, 2010 at 12:00 GMT+2. No specific licensing condition is requested (pick up the one you like!) We reserve the right to extend this deadline in the absence of interesting results. Otherwise, the winner will be announced during the Rump session of the second SHA-3 candidate conference in Santa Barbara.

Priset de pratar om är en sådan här:

En implementation i Erlang kanske vore något (LinusN, Alu)?

No related posts.

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

Sidan om kretsen innehåller en hel del info om hur chippet är uppbyggt. Bland annat är kretsen uppdelad i 8 separata regioner som var för sig kan ha olika spänningsnivå. Kretsen är byggd i konservativ 45nm-teknik (läs: Dom har inte använt experimentella kommande processnoder för att realisera kretsen.). Dessutom är det oklart hur kraftfull en enskild core är, bara att dom är IA-kompatibla.

Ron Rivest har pekat på kretsen som ett argument för att den algoritm som väljs av NIST till hashfunktionen SHA-3 är kapabel till parallellism. Om inte den är det riskerar den att inte skala med resten av applikationernas prestandaökning.

No related posts.

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

När tävlingen startade begärde NIST in kandidater och fick totalt in 64 stycken kandidater. Av dessa kandidater ansåg NIST att 51 uppfyllde minimikraven och accepterades som kandidater i slutet av oktober 2008. Det senaste året har dessa kandidater undersökts och attackerats av såväl NIST som kryptosamfundet i stort. För den som är intresserad listar SHA-3 Zoo status för alla kandidater vad gäller attacker.

En av de saker rapporten beskriver är vilka kriterier NIST har satt upp för att bedöma de olika kandidaterna. Dessa är uppdelade i tre kategorier:

1. Säkerhet. Den nya hashfunktionen måste vara minst lika säker som SHA-2-funktionerna.
2. Prestanda och kostnad. Ett problem med SHA-2 är att dessa funktioner är väldigt mycket långsammare än SHA-1 och den nya funktionen måste därför vara snabbare än SHA-2. Prestandan mäts både på referensplattformen Intel Core 2 Duo i 32- och 64-bitarsmod, men man tittar även på 8-bitplattformar och HW-implementationer. Kostnaden handlar om mängd program- och dataminne samt storlek vid HW-implementationer.
3. Algoritm och implementation. Detta kriterie handlar mer om ifall algoritmen är mer eller mindre flexibel, kan utnyttja nya arkitekturer som SIMD-instruktioner eller AES-instruktioner, går att parallellisera samt om algoritmen är enkel eller invecklad.

Utifrån sina egna bedömningar och andras analyser vad gäller säkerhet och prestanda (exemeplvis eBASH-projektets prestandamätningar) har NIST valt ut 14 algoritmer som går vidare till andra omgången. Dessa är:

BLAKE, BLUE MIDNIGHT WISH (BMW), CubeHash, ECHO, Fugue, Grøstl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD, Skein

Rapporten innehåller en kortfattad beskrivning av varje kandidatalgoritm där NIST beskriver grundläggande idé och struktur, hur olinjäritet skapas i algoritmen, vad NIST ser som det unika med algoritmen, prestanda samt säkerhetsläget. Utifrån dessa beskrivningar kan man göra några enklare observationer:

• Tre grundläggande idéer/strukturer återkommer hela tiden. Tre är baseade på HAIFA, sex är olika varianter och utökningar av Merkele-Damgård (MD) och övriga fem är baserade på de relativt nya svampfunktionerna (Sponge functions). Det är skönt att se att det inte bara är MD-baserade kandidater kvar, utan att det finns kandidater med rejält olika utgångspunkt kvar i tävlingen.
• Fyra av kandidaterna använder på något sätt AES som en del av sin funktionalitet. Vissa återanvänder S-boxen, andra återanvänder delar eller hela round-funktionen från AES.
• Flera av kandidaterna behöver väsentligen implementeras med SIMD- eller AES-specialiserade instruktioner för att ge riktigt bra prestanda.
• Antalet kandidater med substitutionstabeller är ganska få, och dessa är förhållandevis små. Detta kan antagligen ses som ett resultat av de senaste årens uppmärksammade problem med att göra implementationer utan sidoeffekter av algoritmer med S-boxar.
• Förhållandevis många kandidater bygger på att använda enkla funktioner (XOR, modulär addition, skiftoperationer) som upprepas ett stort antal gånger, gärna med möjlighet till parallellism. Ingen verkar använda multiplikationer eller andra typer av mer avancerade transformer, ex FFT som en av de andra kandidaterna använde.

NISTs förhoppning är att det begränsade antalet kandidater i andra omgången skall göra att samtliga kandidater blir rejält genomlysta. NIST noterar i sin beskrivning av kandidaterna att det skiljer ganska väsentligt i hur mycket analys som skett av de olika kandidaterna så här långt.

Den andra omgången är planerad att pågå i ett år och hösten 2010 avser NIST att välja ut fyra-fem stycken av de 14 kandidaterna som finalistkandidater. Detta innebär att tävlingen pågått i två år och kommer att hålla på i ett, troligen två år till. Det tar tid att skaka fram en hashfunktion.

No related posts.

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

Jag begriper för lite av den kortfattade presentationen för att avgöra hur mycket bättre deras resultat är en den bästa kända attacken med 26 related keys, 2**114 data och 2**173 time. Enligt en kommentar på Cryptography-listan hävdade författarna vid sin presentation att det nu finns praktisk möjlighet att bryta hashfunktioner byggda på round-funktionen i AES. Detta gör resultatet intressant för den pågående SHA-3-tävlingen då flera av kandidaterna lånar delar av eller hela round-funktionen.

Författarnas artikel om sin nya attack är tydligen godkänd för CRYPTO 2009, så om inte förr så vet vi mer i slutet av Augusti.

No related posts.

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

Den nya attacken presenterad av Cameron McDonald, Philip Hawkes och Josef Pieprzyk har en komplexitet på 2**52 (operationer). Som forskarna påpekar är detta en stor förbättring gentemot tidigare bästa resultat, 2**63. Jämför man exempelvis med de DES-knäckare (ex COPACOBANA som byggts för att klara DES komplexitet på 2**56 är detta i samma härad och attacker är för den som har budget och tillräcklig vilja/behov möjliga att genomföra.

COPACOBANA-prototyp med FPGAer.

Det finns ännu ingen riktig artikel publicerad så det går inte att verifiera resultatet. Vidare finns det ingen egentlig skala, dvs 2**52 av vad behöver man genomföra för att knäcka SHA-1. Dock är forskarna bakom kända som seriösa forskare som tidigare publicerat ett antal artiklar och bidrag till fältet.

Om resultatet visar sig stämma är det ett signifikant resultat. För vissa typer av applikationer av SHA-1, exempelvis certifikat (beroende på hur de beräknas) skulle attacken göra det möjligt att generera falska certifikat. (Enl uppgift sätter Verisign serienumret helt slumpmässigt vilket gör det klart svårare att generera ett falskt certifikat.)

Om det inte sagts tidigare är det hög tid att (iaf för vissa användningar) migrera bort från SHA-1 och det presenterade resultatet understrycker även vikten av att NISTs SHA-3 tävling leder till minst en (den NIST antar) familj av nya hashfunktioner.

No related posts.

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

Sphlib innehåller implementationer i C och i Java av följande hashfunktioner:

haval128_3 HAVAL, 128-bit output, 3 passes
haval128_4 HAVAL, 128-bit output, 4 passes
haval128_5 HAVAL, 128-bit output, 5 passes
haval160_3 HAVAL, 160-bit output, 3 passes
haval160_4 HAVAL, 160-bit output, 4 passes
haval160_5 HAVAL, 160-bit output, 5 passes
haval192_3 HAVAL, 192-bit output, 3 passes
haval192_4 HAVAL, 192-bit output, 4 passes
haval192_5 HAVAL, 192-bit output, 5 passes
haval224_3 HAVAL, 224-bit output, 3 passes
haval224_4 HAVAL, 224-bit output, 4 passes
haval224_5 HAVAL, 224-bit output, 5 passes
haval256_3 HAVAL, 256-bit output, 3 passes
haval256_4 HAVAL, 256-bit output, 4 passes
haval256_5 HAVAL, 256-bit output, 5 passes
md2 MD2
md4 MD4
md5 MD5
panama Panama
radiogatun32 RadioGatun[32]
radiogatun64 RadioGatun[64]
ripemd RIPEMD (original function)
ripemd128 RIPEMD-128 (revised function, 128-bit output)
ripemd160 RIPEMD-160 (revised function, 160-bit output)

rmd RIPEMD (original function)
rmd128 RIPEMD-128 (revised function, 128-bit output)
rmd160 RIPEMD-160 (revised function, 160-bit output)

sha0 SHA-0 (original SHA, withdrawn)
sha1 SHA-1
sha224 SHA-224
sha256 SHA-256
sha384 SHA-384
sha512 SHA-512

shabal192 SHABAL-192
shabal224 SHABAL-224
shabal256 SHABAL-256
shabal384 SHABAL-384
shabal512 SHABAL-512

tiger Tiger
tiger2 Tiger2 (Tiger with a modified padding)

whirlpool Whirlpool (2003, current version)
whirlpool0 Whirlpool-0 (2000)
whirlpool1 Whirlpool-1 (2001)

Det går även att köra sphsum för att köra de olika funktionerna för att beräkna en hash av givet indata.

Enligt webbplatsen är licensen för biblioteket MIT-lik och BSD-lik. Verkar det förvirrat? Författarna förklarar licensen så här:

Licensing is specified in the LICENSE.txt file. This is an MIT-like, BSD-like open-source license. Basically, we will get the fame but not the blame. If you reuse our code in your own projects, and distribute the result, then you should state that you used our code and that we always disclaimed any kind of warranty, and will continue to do so in the foreseeable future, and beyond. You have no other obligation such as disclosing your own source code. See the LICENSE.txt file for the details in a lawyer-compatible language.

Jag har inte testat att bygga sphlib på min maskin än. Återkommer när jag gjort det.

No related posts.

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

Förväntningarna från konferensen är att det skall trilla ut 10 till 15-16 kandidater (Ron Rivest har föreslagit 16 kandidater där två tas ut genom ett wildcard-system) utifrån det 50-tal kandidater som NIST fick in och accepterade vid tävlingens start. Förhoppningsvis kommer information om vilka kandidater som gått vidare inom några få dagar.

No related posts.

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

Fortify har använt sitt verktyg Fortify SCA, en linter speciellt utvecklad för att hitta kodmässiga svagheter som buffertöverskrivningar etc. (Det hade antagligen gått bra att använda splint eller liknande säkerhetsinriktade lintverktyg för att hitta svagheterna.)

Vad Fortify upptäckt är att ett antal av SHA-3-kandidaterna har mer eller mindre allvarliga svagheter i sin implementation, mer specifikt i Blender, Crunch, FSB, MD6, Vortex. Några typiska fel är att koden tillåter buffertöverskrivningar, att den läser utanför gränserna i en buffert (indexeringsfel) och minnesläckage. Som ett exempel tar Fortify upp MD6:

One of the projects with buffer issues was MD6, the implementation provided Professor Ron Rivest and his team. All of the problems came back to the hashval field of the md6_state struct:

unsigned char hashval[ (md6_c/2)*(md6_w/8) ];

The buffer size is determined by two constants:

#define w md6_w /* # bits in a word (64) */ #define c md6_c /* # words in compression output (16) */

At several points, this buffer is read or written to using a different bound:

if (z==1) /* save final chaining value in st->hashval */ { memcpy( st->hashval, C, md6_c*(w/8) ); return MD6_SUCCESS; }

Further analysis showed that ANSI standard layout rules would make incorrect behavior unlikely, but other compilers may have allowed it to be exploited. The MD6 team has doubled the size of the vulnerable buffer, which eliminated the risk. In this case, Fortify SCA found an issue that would have been difficult to catch otherwise.

The other buffer overflow was found in the Blender implementation, from Dr. Colin Bradbury. This issue was a classic typo:

DataLength sourceDataLength2[3];// high order parts of data length ... if (ss.sourceDataLength < (bcount | databitlen)) // overflow if (++ss.sourceDataLength2[0] 0) // increment higher order count if (++ss.sourceDataLength2[1] 0) // and the next higher order ++ss.sourceDataLength2[3]; // and the next one, etc.

The developer simply mistyped, using 3 instead of 2 for the array access. This issue was probably not caught because it would not be exposed without a very large input. The other issues we found were memory leaks and null dereferences from memory allocation.

Att den här typen av programmeringsfel kan få betydelse för SHA-3-tävlingen är uppenbart, och illustreras tydligt med MD6. Dess internbuffert behövde dubbleras i storlek. Detta gör att implementationer av MD6 för inbyggda system kommer att kräva mer minnesresurser än vad tidigare angetts. En av styrkorna med MD6 enligt dess skapare är att den skalar extremt bra ner till mycket små implementationer, och det argumentet fick sig nu nog en liten törn.

Ett annat skäl till varför jag tycker att Fortifys undersökning är bra är att referensimplementationer ofta används i applikationer. Antingen direkt eller som bas (funktionell referens) för en ny implementation. Därmed riskerar svagheter i referensimplementationen att sprida sig. Fortify tar själva upp ett exempel från en svaghet i referensimplementationen av RSA som lett till buggar i olika SSL-implementationer.

I fallet SHA-3, med dess fokus på prestanda, vilket gjort att skaparna av kandidater slitit och sliter med att optimera ut varenda cykel de kan ur sin kod, tror jag att referensimplementationer kommer att få stor användning i applikationskod.

No related posts.

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

Tydligen finns det en tysk standard för slumptalsgeneratorer kallas AIS 31. Tydligen är det en myndighet/organisation kallad Bundesamt für Sicherheit in der Informationstechnik (BSI) som specat AIS 31. Det som är intressant är att det för AIS 31 skett en del utveckling av (i mitt tycke) bra metoder för att testa och utvärdera generatorerna (även i system). Det finns en bra presentation från BSI som förklarar AIS 31 och hur de utvärderar slumptalsgeneratorer (Powerpoint-presentation).

Infineon har publicerat en artikel om hur de designat AIS 31-generatorer som är testbara generatorer och går att implementera på chip.

Den här (väldigt tyska) webbsidan innehåller en hel del information om hemmasnickrade slumptalsgeneratorer, varav en del möter AIS 3. Sättet att uppnå NISTs FIPS 140-klassificering gör att maskinerna ser lite hemliga ut:

Hur jag sprang på AIS 31? ZK Crypt, en av kandidaterna till SHA-3-tävlingen är skapad av ett företag kallad Fortress GB, och dom har tydligen även AIS 31-produkter.

No related posts.

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