AES-based 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-RSA’09) • Generic attacks – HAIFA • Length extension – final permutation (Hirose at al Asiacrypt’07)

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

20. 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 ????)

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

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