Cryptanalysis vs.

Reality
Jean-Philippe Aumasson

1 / 54

Cryptanalysis is the study of methods for

obtaining the meaning of encrypted information
without access to the secret information that is normally required to do so. Wikipedia

2 / 54

Cryptanalysis is the study of methods for

obtaining the meaning of encrypted information
without access to the secret information that is normally required to do so. Wikipedia

3 / 54

The fundamental goal of a cryptanalyst is to

violate one or several security notions

for algorithms that claim, implicitly or explicitly, to satisfy these security notions.
Antoine Joux, Algorithmic Cryptanalysis

4 / 54

Reality noun (pl. realities) 1. the state of things as they actually exist, as opposed to an idealistic or notional idea of them. 2. a thing that is actually experienced or seen. 3. the quality of being lifelike. 4. the state or quality of having existence or substance.
Compact Oxford English Dictionary

5 / 54

Cryptanalysis relies on an ATTACKER MODEL = assumptions on what the attacker can and cannot do All models are in simulacra, that is, simplied reections of reality, but, despite their inherent falsity, they are

nevertheless extremely useful

G. Box, N. Draper, Empirical Model-Building and Response Surfaces

6 / 54

Cryptanalysis usually excludes methods of attack that do not primarily target weaknesses in the actual cryptography, such as bribery, physical coercion,

burglary, keystroke logging, and social engineering, although these types of attack are an
important concern and are often more effective
Wikipedia

7 / 54

Cryptanalysis used to be tightly connected to reality

8 / 54

But times have changed

9 / 54

10 / 54

11 / 54

Broken in a model does not imply broken in reality!

12 / 54

Models language overlaps with real-world language: attacks, broken have multiple meanings

Has cryptanalysis lost connection with reality?

13 / 54

Cryptography is usually bypassed. I am not

aware of any major world-class security system employing cryptography in which the hackers penetrated the system by actually going through the cryptanalysis. (. . . ) Usually there are much simpler ways of penetrating the security system.
Adi Shamir, Turing Award lecture, 2002

14 / 54

Is cryptanalysis relevant at all??

15 / 54

Remainder of this talk PART 1: PHYSICAL ATTACKS Bypass and misuse Side channels PART 2: ALGORITHMIC ATTACKS State-of-the-ciphers Why attacks arent attacks Cognitive biases What about AES?

CONCLUSIONS

REFERENCES
16 / 54

PART 1: PHYSICAL ATTACKS Bypass and misuse Side channels

17 / 54

HTTPS protection uses (say) 2048-bit RSA to authenticate servers, and to avoid MitM attacks

100-bit security (see http://www.keylength.com/)

2100 ops to break RSA by factoring the modulus

18 / 54

HTTPS protection uses (say) 2048-bit RSA to authenticate servers, and to avoid MitM attacks

100-bit security (see http://www.keylength.com/)

2100 ops to break RSA by factoring the modulus

Or 233 using a quantum computer implementing Shors algorithm

18 / 54

HTTPS protection uses (say) 2048-bit RSA to authenticate servers, and to avoid MitM attacks

100-bit security (see http://www.keylength.com/)

2100 ops to break RSA by factoring the modulus

Or 233 using a quantum computer implementing Shors algorithm

Or 20 by compromising a CA. . .

18 / 54

19 / 54

AES-256 provides 256-bit security (does it really?) FIPS 140-2 is supposed to inspire condence. . .
Yet secure USB drives by Kingston, SanDisk, Verbatim were easily broken

The aw: password validation on host PC + static unlock code

20 / 54

How NOT to use decent cryptographic primitives:

21 / 54

How NOT to use decent cryptographic primitives: ECDSA signing with a constant instead of a random number
to nd SONY PS3s private key

21 / 54

How NOT to use decent cryptographic primitives: ECDSA signing with a constant instead of a random number
to nd SONY PS3s private key

RC4 stream cipher with part of the key public and predictable (as found in the WEP WiFi protection)

21 / 54

How NOT to use decent cryptographic primitives: ECDSA signing with a constant instead of a random number
to nd SONY PS3s private key

RC4 stream cipher with part of the key public and predictable (as found in the WEP WiFi protection)

TEA block cipher in hashing mode to perform boot code authentication

Equivalent keys lead to collisions

21 / 54

Software side-channel attacks

Practical attacks exploiting non-constant-time AES implementations

Breaking the secure AES of OpenSSL 0.9.8n:

Breaking AES on ARM9:

22 / 54

23 / 54

Hardware side-channel attacks

Power analysis (SPA/DPA) Electromagnetic analysis Glitches (clock, power supply, data corruption) Microprobing Laser cutting and fault injection Focused ion beam surgery, etc.

24 / 54

PART 2: ALGORITHMIC ATTACKS State-of-the-ciphers Why attacks arent attacks What about AES? Cognitive biases

25 / 54

ALGORITHMIC ATTACKS = attacks targetting a cryptographic function seen as an algorithm and described as algorithms rather than physical
procedures
ALGORITHMIC ATTACKS are thus independent of the implementation of the function attacked

26 / 54

Well focus on symmetric cryptographic primitives: Block ciphers Stream ciphers Hash functions PRNGs MACs
Though thered be a lot to say about public-key encryption/signatures, authentication protocols, etc.

27 / 54

Null- to low-impact attacks (examples)

Block ciphers:

AES GOST (Russian standard, 1970s!) KASUMI (3GPP) Triple DES

Hash functions:

SHA-1 Whirlpool (ISO)

28 / 54

Medium- to high-impact attacks (examples)

Block cipher: DES (56-bit key): practical break by. . . bruteforce Stream cipher: A5/1 (GSM): attacks on GSM facilitated Hash function: MD5: famous rogue certicate attack PoC

29 / 54

Unattacked primitives (examples)

Block ciphers

CAST5 (default cipher in OpenPGP) IDEA (1991!) IDEA-NXT (aka FOX) Serpent (AES nalist) Twosh (AES nalist)
Stream ciphers:

Grain128a (for hardware) Salsa20 (for software)

Hash functions: SHA-2 (SHA-256, . . . , SHA-512) RIPEMD-160 (ISO)
30 / 54

Despite the large amount of research and new techniques, breaks almost never happen:

Why?

31 / 54

High-complexity attacks
Example: preimage attack on MD5 with time complexity

2123.4
against 2128 ideally High-complexity attacks do not matter as long as the effort is obviously unfeasible, or overwhelms the cost of other attacks
Yet MD5 can no longer be sold as 128-bit security hash

32 / 54

The difference between 80 bits and 128 bits of keysearch is like the difference between a mission to Mars and a mission to Alpha Centauri. As far as I can see, there is

*no* meaningful difference between 192-bit and 256-bit keys in terms of practical brute force attacks; impossible is impossible.
John Kelsey (NIST)

33 / 54

Back-to-reality interlude

2 GHz CPU

1 sec = 2 109 233 clocks

1 year 258 clocks 1000 years 268 clocks since the Big-Bang 2116 clocks

34 / 54

The encryption doesnt even have to be very strong to be useful, it just must be stronger than the other weak links in the system. Using any standard commercial risk management model, cryptosystem failure is orders of magnitude below any other risk.
Ian Griff, Peter Gutmann, IEEE Security & Privacy 9(3), 2011

35 / 54

Attacks on building blocks

Example: 296 collision attack on the compression function of the SHA-3 candidate LANE Did not lead to an attack on the hash Invalidates the security reduction compression hash Disqualied LANE from the SHA-3 competition!

36 / 54

Attacks on building blocks

Example: 296 collision attack on the compression function of the SHA-3 candidate LANE Did not lead to an attack on the hash Invalidates the security reduction compression hash Disqualied LANE from the SHA-3 competition!

How to interprete those attacks?

1. We attacked something crypto must be weak! 2. We failed to attack the full function crypto must be strong!

36 / 54

Strong models: ex of related-key attacks

Attackers learn encryptions with a derived key K = f (K ) One of the rst attacks: when Enigma operators set rotors incorrectly, they sent again with the correct key. . . Modern version introduced by Knudsen/Biham in 1992 Practical on weak key-exchange protocols (EMV, 3GPP?), but unrealistic in most decent protocols

37 / 54

Related-key attacks example

Key-recovery on AES-256 with time complexity

2119
against 2256 ideally! Needs 4 related keys. . . actually, related subkeys

attacks are still mainly of theoretical interest and do not present a threat to practical applications using AES
the authors (Khovratovich / Biryukov)

38 / 54

Model from reality: pay-TV encryption

MPEG stream encrypted with CSA Common Scrambling Algorithm, 48b or 64b key

Useful break of CSA needs

Unknown- xed-key attacks Ciphertext-only, partially-known plaintext (no TMTO) Key recovery in <10 seconds (cryptoperiod)
39 / 54

Theres not only time!

Back to our previous examples: MD5: time 2123.4 and 250 B memory (1024 TiB) LANE: time 296 and 293 B memory (253 TiB) AES-256: time 2119 and 277 B memory (237 TiB) Memory is not free! ($$$, infrastructure, latency) Practical cost of access to memory neglected

New attacks should be compared to generic attacks with a same budget

See cracking machines in Understanding bruteforce http://cr.yp.to/papers.html#bruteforce
40 / 54

Distinguishing attacks
aka distinguishers

Used to be statistical biases

Now distinguishers are Known- or chosen-key attacks Sets of input/outputs satisfying some relation Example: differential q-multicollision distinguisher on AES
EK1 (P1 ) EK1 (P1 ) = EK2 (P2 ) EK2 (P2 = EK3 (P3 ) EK3 (P3 ) ) = ...

41 / 54

Distinguishing attacks
aka distinguishers

Used to be statistical biases

Now distinguishers are Known- or chosen-key attacks Sets of input/outputs satisfying some relation Example: differential q-multicollision distinguisher on AES
EK1 (P1 ) EK1 (P1 ) = EK2 (P2 ) EK2 (P2 = EK3 (P3 ) EK3 (P3 ) ) = ...

NO IMPACT ON SECURITY in a large majority of cases

41 / 54

Attacks (high-complexity, strong model, high-memory, distinguishers, etc.) vs. Reality

2 general interpretations: 1. This little thing is a sign of bigger things! 2. This little thing is a sign of no big things!

Why are we biased? (towards 1. or 2.)

42 / 54

43 / 54

Cryptographic Num3rol0gy
The basic concept is that as long as your encryption keys are at least this big, youre ne, even if none of the surrounding infrastructure benets from that size or even works at all
Ian Griff, Peter Gutmann, IEEE Security & Privacy 9(3), 2011

44 / 54

Cryptographic Num3rol0gy
The basic concept is that as long as your encryption keys are at least this big, youre ne, even if none of the surrounding infrastructure benets from that size or even works at all
Ian Griff, Peter Gutmann, IEEE Security & Privacy 9(3), 2011

Choosing a key size if fantastically easy, whereas making the crypto work effectively is really hard
Ibid

45 / 54

Zero-risk bias
= Preference for reducing a small risk to zero over a greater reduction in a larger risk Example: reduce risk from 1% to 0% whereas another risk could be reduced from 50% to 30% at the same cost

46 / 54

Zero-risk bias
= Preference for reducing a small risk to zero over a greater reduction in a larger risk Example: reduce risk from 1% to 0% whereas another risk could be reduced from 50% to 30% at the same cost

Cryptographic numerology (examples) 1% = scary-new attack threat

Move from 1024- to 2048-bit (or 4096-bit!) RSA Cascade-encryption with AES + Serpent + Twosh + Unintended consequences: Crypto is slower less deployed less security

46 / 54

Survivorship bias
We only remember/see the unbroken, deployed and/or standardized, algorithms Not the numerous experimental designs broken

47 / 54

Survivorship bias
We only remember/see the unbroken, deployed and/or standardized, algorithms Not the numerous experimental designs broken Example: of the 56 SHA-3 submissions published 14 implemented attacks (e.g. example of collision) 3 close-to-practical attacks ( 260 ) 14 high-complexity attacks Practical attacks kill ciphers before they are

used and known to the public

47 / 54

What about AES?

48 / 54

What about AES?

Groundbreaking attack bogeyman!

49 / 54

What about AES?

The facts:

AES-128: 2126 complexity, 288 plaintext/ciphertext

against 2128 and 20 for bruteforce

AES-256: 2254 complexity, 240 plaintext/ciphertext

against 2256 and 21 for bruteforce

See Bogdanov, Khovratovich, Rechberger:

http://research.microsoft.com/en-us/projects/ cryptanalysis/aesbc.pdf

50 / 54

What about AES?

The facts:

AES-128: 2126 complexity, 288 plaintext/ciphertext

against 2128 and 20 for bruteforce

AES-256: 2254 complexity, 240 plaintext/ciphertext

against 2256 and 21 for bruteforce

See Bogdanov, Khovratovich, Rechberger:

http://research.microsoft.com/en-us/projects/ cryptanalysis/aesbc.pdf

Reactions heard (from customers, third parties): AES is insecure! Lets use AES with 42 rounds! AES is secure! The attack is far from practical!

50 / 54

CONCLUSIONS

REFERENCES

51 / 54

Conclusions
Algorithmic attacks on deployed schemes are (almost) never a threat to security, due to High complexities, unrealistic models, etc. Weak ciphers are broken earlier and forgotten We dont break ciphers, we evaluate their security
Orr Dunkelman

52 / 54

Conclusions
Algorithmic attacks on deployed schemes are (almost) never a threat to security, due to High complexities, unrealistic models, etc. Weak ciphers are broken earlier and forgotten We dont break ciphers, we evaluate their security
Orr Dunkelman

Beware cryptographic numerology!

52 / 54

Conclusions
Algorithmic attacks on deployed schemes are (almost) never a threat to security, due to High complexities, unrealistic models, etc. Weak ciphers are broken earlier and forgotten We dont break ciphers, we evaluate their security
Orr Dunkelman

Beware cryptographic numerology! AES is ne, weak implementations are the biggest threat

52 / 54

Related works
Leakage-resilience vs. Reality
Leakage Resilient Cryptography in Practice Standaert et al. http://eprint.iacr.org/2009/341

Bruteforce vs. Reality

Using the Cloud to Determine Key Strengths Kleinjung et al. http://eprint.iacr.org/2011/254

Crypto libs vs. Reality

Open-Source Cryptographic Libraries and Embedded Platforms

Junod http://crypto.junod.info/hashdays10_talk.pdf

53 / 54

Thank you for your attention

54 / 54