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.

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.

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.

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.

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.

No related posts.

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

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.

No related posts.

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

Ä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 2^{32 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 2}32 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:

(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årdvara – ASIC 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.

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.

No related posts.

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

Först ut var Ron Rivest och hans kollegor som presenterade hashfunktionen MD6, även kallad Pumpkin Hash. MD6 är ett relativt stort steg från den struktur nuvarande SHA-algoritmerna har. MD6 bygger upp en komplext träd med många subnoder. Trädet processas sedan nerifrån och upp – på något sätt. Det ser komplicerat och kostsamt ut. Men enligt Rivest & Co skall det gå att enkelt serialisera processningen för att köra på små processorer, och samtidigt parallellisera för hög prestanda på multicore-maskiner och i hårdvara.

I dag presenterades en annan kandidat kallad Skein. Skein är skapad av Niels Ferguson, Stefan Lucks, Bruce Schneier, Doug Whiting m.fl. Enligt en postningen om Skein på Schneiers webbplats är hafunktionen byggd på ett blockkrypto kallad Threefish (vilket borde betyda släktskap med Blowfish och Twofish). Bruce skriver:

Skein is fast. Skein-512—our primary proposal—hashes data at 6.1 clock cycles per byte on a 64-bit CPU. This means that on a 3.1 GHz x64 Core 2 Duo CPU, Skein hashes data at 500 MBytes/second per core—almost twice as fast as SHA-512 and three times faster than SHA-256…

Skein is secure. Its conservative design is based on the Threefish block cipher. Our current best attack on Threefish-512 is on 25 of 72 rounds, for a safety factor of 2.9…

Skein is simple. Using only three primitive operations, the Skein compression function can be easily understood and remembered. The rest of the algorithm is a straightforward iteration of this function.

Skein is flexible. Skein is defined for three different internal state sizes—256 bits, 512 bits, and 1024 bits—and any output size. This allows Skein to be a drop-in replacement for the entire SHA family of hash functions. A completely optional and extendable argument system makes Skein an efficient tool to use for a very large number of functions: a PRNG, a stream cipher, a key derivation function, authentication without the overhead of HMAC, and a personalization capability.

Jag planerar att komma med mer detaljerad information när kandidaterna officiellt publicerat. Men det börjar dra ihop sig och det börjar se spännande ut.

No related posts.

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