AESbased primitives LUX, Cheetah

1
AES-based primitivesLUX, Cheetah

• Alex Biryukov
• University of Luxembourg
• 2009

2
Contents

• Design of Cheetah
• Design of LUX
• Speed vs Security discussion
• (see the last slide)

3
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)

4
Cheetah
5
Cheetah Compression
6
Cheetah Round

• Just a Rijndael-256 Round

7
Cheetah Message Expansion
8
Security

• Trunc-Differential attacks not possible (analysis
  to appear at CT-RSA09)
• Generic attacks HAIFA
• Length extension final permutation
• (Hirose at al Asiacrypt07)

9
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.

10
Speed

• Intel 2 Core Duo. Standard AES-code.
• Can be further optimised. One of the fastest.

11
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

12
LUX
13
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.

14
Security
15
Security
16
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.

17
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

18
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.

19
Speed vs Security

• Observable universe 3 1052 kg
• 5 of total mass. Total mass only 2179
• E MC2
• so if we burn the universe in order to power our
  computers we can perform O(2235 )
  computations.

20
Speed vs Security

• Observable universe 3 1052 kg
• 5 of total mass. Total mass only 2179
• E MC2
• so if we burn the universe in order to power our
  computers we can perform O(2235 )
  computations.
• Forget about attacks that have complexities
  higher than 2256.
• (Reversible computation ????)

21
Speed vs Security

• Parallel or sequential attacks?
• For attacks with complexities above 2256 it
  doesnt matter. They dont exist in this world
  anyway.
• Number of computations is a simple standard
  measure of attack complexity.
• In the price of the parallel computer dont
  forget about the electricity bill.

22
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.

23
The End