AES-based primitivesLUX, Cheetah

Alex Biryukov

University of Luxembourg

2009

Contents

• Design of Cheetah

• Design of LUX

• Speed vs Security discussion

(see the last slide)

Cheetah

• 256-bit state

• 1024-bit message

• 16 Rijndael 256-bit rounds

• 3 rounds of 1024-bit Rijndael in the keyschedule

• MD-HAIFA construction (128-bit optional salt is treated as part of the message)

Cheetah

Cheetah Compression

Cheetah Round

• Just a Rijndael-256 Round

Cheetah Message Expansion

Security

• Trunc-Differential attacks not possible (analysis to appear at CT-RSA’09)

• Generic attacks – HAIFA

• Length extension – final permutation

(Hirose at al Asiacrypt’07)

External Cryptanalysis

• Length extension (Gligorsky)Need to fix the permutation to avoid fixed points

(make IV non-zero, adding a constant, output transform?)

• 8.5/12 round for 512-bit version(Schläffer et al)

Resume: scratched but not broken. We encourage more cryptanalysis of the

compression function and the mode.

Speed

• Intel 2 Core Duo. Standard AES-code.

• Can be further optimised. One of the fastest.

LUX

• Stream cipher-like (sponge-like) design• Round trasform based on 256-bit AES• Wide-pipe design• Belt: 16 words (512-bits)• Mill: 8 words (256-bits)• Message XORed 32-bits at a time to both

Belt and Mill• 32-bit feedback from Belt to Mill

LUX

LUX

• 16 Blank rounds at the end

• 8 filter rounds (32-bit outputs, each round)

• Constant XORed each round to break symmetry

• Supports Salt (128-bits), treated the same way as the message.

Security

Security

LUX External Cryptanalysis

• Free-start collision, free-start preimage (Wu, Feng, Wu).

• This a 768-bit “free” start, works for any sponge-like hash.

• Length extension slide attack (Peyrin)

• needs salt size to be equal to 31 (mod 32) bits. Salt size is fixed to 128-bits in LUX.

Speed

• 32/64-bit Intel Core 2 Duo, • Intel compiler 10.1, Windows XP

• 1.2 times faster than standard AES implementation on the same platform.

• Should be possible to bring below 10 cpb

Speed vs Security

• Many AES-based constructions.

• Many very concervative constructions. Slow but secure approach.

• Users need fast hashes, reluctant to switch even from MD5.

• Ideally we need hash that is not slower than AES and has tunable number of rounds. Much faster than SHA-256.

Speed vs Security

• Observable universe: 3 × 10^52 kg

• 5% of total mass. Total mass only: 2^179

• E = MC^2

• so if we burn the universe in order to power our computers we can perform O(2^235 ) computations.

Speed vs Security

• Observable universe: 3 × 10^52 kg• 5% of total mass. Total mass only: 2^179• E = MC^2• so if we burn the universe in order to

power our computers we can perform O(2^235 ) computations.

• Forget about attacks that have complexities higher than 2^256.

(Reversible computation ????)

Speed vs Security

• Parallel or sequential attacks?

• For attacks with complexities above 2^256 it doesn’t matter. They don’t exist in this world anyway.

• Number of computations is a simple standard measure of attack complexity.

• In the price of the parallel computer don’t forget about the electricity bill.

Possible Scenario

• Allow to tweak #rounds, other trivial tweaks by the end of round 1.

• Select 15 fastest still unbroken (or even unscratched) candidates.

• Let cryptanalysts do the work.

The End