Slutspurt i eSTREAM

April 17th, 2008 by Joachim Strömbergson Leave a reply »

(Uppdaterat med ett citat till från Response to ‘On the Salsa20 core function’. Tack Martin!)

Det är nu ungefär en månad kvar i eSTREAM-tävlingen. Den stora konferensen Fast Software Encryption (FSE) 08 är över och alla workshops är avklarade. Endast målrakan är kvar.

ECRYPT-logga

Daniel J Bernstein har satt samman ett par dokument som försöker summera läget för algoritmerna. (Jag försökte göra något liknande här på Kryptoblog, men DJB:s sammanställning är naturligtvis mycket mer genomarbetad och seriös.).

Artikeln Which phase-3 eSTREAM ciphers provide the best software speeds? försöker bedöma kandidaterna utifrån prestanda. Bernstein skriver:


This paper compares the software speeds of 128-bit 10-round AES, 256-bit 14-round AES, 256-bit CryptMT v3, 256-bit Dragon, 128-bit HC-128, 256-bit HC-256, 128-bit LEX v2, 128-bit NLS v2, 128-bit Rabbit, 256-bit RC4, 256-bit Salsa20/8, 256-bit Salsa20/12, 256-bit Salsa20/20, 256-bit SNOW 2.0, 256-bit Sosemanuk, and 80-bit TRIVIUM.

Artikeln är uppdelad i 10 underkapitel, en för respektive CPU som Bernstein har kört sina prestandatester på (en av dessa är PowerPC-kärnan PPE i Playstation 3). Till stöd för testerna har han använt det ramverk för tester som togs fram i början av eSTREAM och de olika användningfall (trafikfall) som används är:


• “long”: Encrypt one long stream.
• “agility”: Encrypt many parallel streams in 256-byte blocks.
• “1500”: Set up a nonce and encrypt a 1500-byte packet.
• “576”: Set up a nonce and encrypt a 576-byte packet.
• “40”: Set up a nonce and encrypt a 40-byte packet.
• “40k”: Set up a key, set up a nonce, and encrypt a 40-byte packet.

Det som mäts i testerna är cykler/Byte, vilket innebär att ju lägre värde desto bättre. Av kandidaterna verkar Salsa20/8, Trivium, LEX och Rabbit vara de kandidater som mest frekvent ger bäst prestanda. Strömkryptot SNOW 2.0 som används som referens ligger också bra till.

Tyvärr innehåller artikeln ingen bra sammanfattning, utan vi som läsare får själva bläddra igenom kapitlen och försöka skapas oss en bild av vilka kandidatalgoritmer som verkar bra. Det som finns som sammanfattning är kapitel 0.1 Should some ciphers be discarded? som listar säkerhetsmässiga och licensmässiga skäl till att välja bort en del kandidater.

Bernsteins andra artikel är Which eSTREAM ciphers have been broken? som går igenom status för de olika kandidaterna utifrån de säkerhetsanalyser som utförts. Bernstein skriver:


This paper summarizes the impact of known attacks on the stream ciphers submitted to eSTREAM. This paper focuses on “software phase 3” ciphers and “hardware phase 3” ciphers, but it also discusses the eSTREAM submissions that did not advance to phase 3.

En titt artikeln ger att CryptMT, HC, Rabbit, MICKEY-128 v2 är de som klarat sig bäst vad gäller publicerade svagheter. Sedan artikeln publicerades har det kommit en artikel om Grain kallad Cryptanalysis of Grain using Time/Memory/Date Tradeoffs.

I sin artikel har DJB även en länk till en sida på sin webbplats där han försöker samla attackstatus för kända strömkrypton, inte bara för eSTREAM-kandidater. Värd att titta på även om man inte är intresserad av eSTREAM.

Att eSTREAM nu avgörs innebär att några forskningsgrupper och företag får uppleva att det man kämpat för under flera år kröns med framgång. En vinst, få sin kandidat utsedd till eSTREAM-krypto innebär antagligen inte bara prestigemässig vinst, utan antagligen även ekonomisk vinst (exempelvis i form av anslag). Och det här verkar leda att vi befinner oss i något som liknar silly season där skaparna av olika kandidater med mer eller mindre väl underbyggda argument försöker försvara sina skötebarn.

Eli Biham och Jennifer Seberry, skaparna av Py, en kandidat som sållades bort vid slutet av fas två, har publicerat en artikel kallad The Truth on TPy. I artikeln skriver författarna:


In this note we refer to the security of the Py and TPy families, as discussed in several papers in recent years. We investigate the published attacks, and show that no attacks on TPy, TPypy and TPy6 have ever been published, whose complexities are within the bounds set by the security claims of these ciphers.

Also, only a single attack on Py was published which may be considered within the scope of the security claims — as a response to this attack the Py family was tweaked to TPy, TPypy and TPy6.

We conclude that the TPy family of ciphers is highly secure, and recommend using them in applications that require secure stream ciphers.

FSE 2008 publicerades två separata artiklar om svagheter hos Daniel J Bernsteins eSTREAM-kandidat Salsa20. New Features of Latin Dances: Analysis of Salsa, ChaCha, and Rumba samt On the Salsa20 Core Function som enligt sammanfattningen beskriver.


In this paper, we point out some weaknesses in the Salsa20 core function that could be exploited to obtain up to 2**31 collisions for its full (20 rounds) version.

Skulle detta resultat stämma skulle Salsa20 vara riktigt illa ute. Och uppenbarligen har den här artikeln retat upp DJB ordentligt och han har publicerat ett svar i form av artikeln Response to ‘On the Salsa20 core function’. Och DJB sparar verkligen inte på krutet. Bernstein skriver bland annat:


The paper describes the observation as a “weakness” and “vulnerability” in the Salsa20 core function. In fact, exactly the opposite is true. The observation has no impact whatsoever on security: it bounces off a wall that was built into the Salsa20 design and that was already explained in the original “Salsa20 security” document.
...
The paper claims that it proves that “Salsa20 is not to be used as-is as a hash function.” What the paper means, apparently, is that the 64-byte-to-64-byte Salsa20 core is not to be used as a collision-resistant compression function. But what kind of idiot would think that a 64-byte-to-64-byte function is meant as a collision-resistant compression function?

I understand that the phrase “hash function” confuses some ignorant people— which is why I switched terminology to “Salsa20 core” in May 2007 and added an explicit warning to http://cr.yp.to/salsa20.html saying “The Salsa20 core . . . is not collision-resistant.”

How can someone write a paper several months later claiming novelty for the observation that the Salsa20 core is not collision- resistant? The paper says that “[Bernstein] acknowledges that the Salsa20 core is not collision-free”; the paper inexplicably fails to say that this “acknowledgment” predates the paper.

Även om DJB har rätt och Julio Cesar Hernandez-Castro, Juan M. E. Tapiador och Jean-Jacques Quisquater har fel är detta ett sätt att uttrycka det på jag aldrig sett förut i en vetenskaplig artikel.

En sista sak jag vill ta upp så här i slutet av eSTREAM är hur det ser ut licensmässigt för finalisterna. Vilka patenträttigheter är de olika kandidaterna belastade med:


CryptMT Free for any use if CryptMT Version 3 is in the eSTREAM final portfolio (otherwise free for non-commrecial use).
DECIM Partly patented, but freely available
Dragon Free for any use
Edon80 Free for any use
F-FCSR Free for any use
Grain Free for any use
HC Free for any use
LEX Free for any use
MICKEY Free for any use
Moustique Free for any use
NLS Free for any use
Pomaranch Free for noncommercial use
Rabbit Patented, but free for noncommercial use
Salsa20 Free for any use
SOSEMANUK Free for any use
Trivium Free for any use

Så, nu är det bara att vänta och se vad de kloka kryptologerna kommer fram till.

No related posts.

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

Advertisement

4 comments

  1. Blaufish says:

    Hehe… Men inte blir du förvånad över att DJB är arg/upprörd och att hans skrifter är ute i gränslandet? För att vara DJB är det där ju riktigt snälla ord, han kan mycket värre. DJB är forskaren som är intelligent men samtidigt älskar sandlådornas krig.

    Se t.ex. bråken kring djbdns vs BIND, där DJB har nästan helt rätt i all sin kritik, men det blir närmast lite löjligt ändå (BIND är det sämsta som någonsin uppfunnits, koden är åt helvete, sluta använd skiten… jo visst, helt sant, men med lite finnes och diplomati hade man kanske uppnått mer än att verka vara smått galen)

    Eller titta på diskussionerna kring Georgi Guninski qmail exploit mot x86-64bit som DJB inte anser vara ett riktigt exploit eftersom det kräver 13GB virtuellt minne. En server som har 8GB RAM kommer ju sannolikt ha 8GB swap och vips så har man 16GB virtuellt minne i en något så när normal server. Förvisso, år 2005 var exploitet lite väl akademiskt (få mailservrar hade 13GB virtuellt minne), men om man diskuterar om ett program är principiellt sätt säkert är det ju bara rent löjligt att säga “exploitet kommer oftast inte fungera, på grund av att maskinerna har för lite RAM”. Det enda rätta vore att DJB hade erkänt Georgi Guninski som vinnare av tävlingen och medgivit att även den odödlige övermänniskan DJB faktiskt kan göra misstag.

    Som sagt, en kul kille DJB, men minst sagt lite speciell.

  2. Martin M says:

    Oj, Berstein skräder verkligen inte orden:
    “The paper claims that it proves that ‘Salsa20 is not to be used as-is as a hash function.’ What the paper means, apparently, is that the 64-byte-to-64-byte Salsa20 core is not to be used as a collision-resistant compression function. But what kind of idiot would think that a 64-byte-to-64-byte function is meant as a collision-resistant compression function?”

    Men även om man överraskas över ordvalet måste man ju hålla med om att kritiken verkar vara ganska ogenomtänkt.

  3. Joachim says:

    Aloha!

    Martin: Bra påpekande, missade den sektionen och tar med den.

    Jag är, precis som du inte säker på att attacken på Salsa20 håller vatten. Samtidigt har den accepterats till FSE08 och då måste ett antal kunniga personer läst och tyckt att den verkar vettig så...

Leave a Reply

You must be logged in to post a comment.