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.

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.

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.

No related posts.

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

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.

No related posts.

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

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.

No related posts.

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