CMSC 414 Computer and Network Security Lecture 4

1. CMSC 414Computer and Network SecurityLecture 4 Jonathan Katz

2. Review • If we want perfect secrecy, we face several inherent limitations • Key as long as the message • Key used only once • Not secure against chosen-plaintext attacks • Computational secrecy offers the potential to circumvent these limitations • E.g., the pseudo-one-time pad • Which drawbacks does this address?

3. Attack taxonomy • So far, we have been considering only passive eavesdropping of a single ciphertext • aka, ciphertext-only attack • In practice, stronger attacks need to be considered • Known-plaintext attacks • Chosen-plaintext attacks • Implies security for multiple messages encrypted using the same key • Chosen-ciphertext attacks (by default, encompasses chosen-plaintext attacks)

4. Enck(m2) m2 Definitions? c = Enck(m) Deck(c’) k k Enck(m1) In all cases, a bounded adversary should be unable to determine (with probability much better than ½) whether ma or mb was encrypted c’ m1 I know the message m is either ma or mb, but which one? Chosen-plaintext attack Chosen-ciphertext attack Ciphertext-only attack

5. c Chosen-plaintext security • Is the definition too strong? Voters Enck(Obama) Enck(McCain)

6. Chosen-plaintext security • Is security against chosen-plaintext attacks even possible?? • Deterministic encryption schemes cannot be secure against chosen-plaintext attacks • Nor can they be secure for encrypting multiple messages • To be secure against chosen-plaintext attack, encryption must be randomized • Moral: always use randomized encryption!

7. Minimum requirements • The minimum level of security nowadays is security against chosen-plaintext attacks • But security against chosen-ciphertext attacks (or even stronger) is often necessary for certain applications • Make sure you are aware of this when deploying encryption! • We will revisit this issue after discussing message authentication

8. Block ciphers • Keyed, invertible permutation F • Large key space, large block size • Indistinguishable from a random permutation • A block cipher is not an encryption scheme • A block cipher can be used to build an encryption scheme (and other things as well) • Example – the “trivial” encryption scheme: • C = FK(m) • This is not randomized…

9. Data Encryption Standard (DES) • Developed in 1970s by IBM / NSA / NBS • Non-public design process • 56-bit key, 64-bit input/output • A 64-bit key is derived from 56 random bits • One bit in each octet is a parity-check bit • The short key length is a major concern… • The short block length is also a concern

10. Concerns about DES • Short key length • DES “cracker”, built for $250K, can break DES in days • Computation can be distributed to make it faster • Does not mean “DES is insecure”; depends on desired security • Short block length • Repeated blocks happen “too frequently” • Some (theoretical) attacks have been found • Claimed known to DES designers 15 years before public discovery! • Non-public design process

11. 3DES/triple-DES • Expands the key length • Now, key K = (K1, K2); |K| = 112 • Still has the short block length • The “new” block cipher is just: • EK1,K2(m) = DESK1(DES-1K2(DESK1(m))) • This is a permutation, and invertible • Fairly slow…but widely used in practice

12. AES • Public contest sponsored by NIST in ’97 • 15 candidates submitted • Narrowed to 5 finalists in ’99 • Winner selected in 2000 • Entire contest open; intense cryptanalytic effort • Rijndael selected as the AES • Supports variety of block/key sizes, but defaults to 128-bit key length and 128-bit block length • 2128 is a huge number • Number of seconds since big bang (estimate): ~258 • Number of nanoseconds since big bang: ~290 • Both efficiency and security taken into account • The “most secure” finalist was not the one chosen

13. Other block ciphers? • No compelling reason to use anything but AES • Unless (possibly) you have very severe performance requirements, or are paranoid about security • Even then, think twice • Same goes for stream ciphers (which are essentially PRNGs)

14. Modes of encryption • Used for encrypting a long message m1, …, mn • ECB • Ci = FK(mi); the ciphertext is (C1, …, Cn) • CBC • IV; Ci = FK(mi Ci-1); the ciphertext is (IV, C1, …, Cn) • OFB (stream cipher mode) • IV; zi = FK(zi-1); Ci = zi mi; the ciphertext is (IV, C1, …, Cn) • CTR (stream cipher mode) • IV; zi = FK(IV+i); Ci = zi mi; the ciphertext is (IV, C1, .., Cn) • Others…

15. Security? • ECB should not be used • Why?

16. The effect of ECB mode original encrypted using ECB mode *Images from Wikipedia

17. Security • CBC, OFB, and CTR modes are secure against chosen-plaintext attacks • CBC, OFB, and CTR modes are not secure against chosen-ciphertext attacks *Images from Wikipedia

18. Message integrity

19. Message integrity m m’

20. Encryption does not provide integrity • “Since encryption garbles the message, decryption of a ciphertext generated by an adversary must be unpredictable” • WRONG • E.g., one-time pad, CBC-/CTR-mode encryption • Why is this a concern? • Almost always, integrity is needed in addition to secrecy • Lack of integrity can lead to lack of secrecy • Use message authentication codes (MACs)

21. Message authentication code (MAC) • In the private-key setting, the tool for achieving message integrity is a MAC • Functionality: • MACK(m) = t (we call t the “tag”) • VrfyK(m, t) = 0/1 (“1” = “accept” / ”0”=“reject”) • Correctness…

22. Bob Alice MAC usage m, t k k Vrfyk(m’,t’) ?? t = Mack(m) • Shared key k • Sender computes a tag t on the message m using k • Receiver verifies the message/tag pair using k

23. Bob Bob K K MAC usage

24. Defining security • Attack model: • A random key k is chosen • Attacker is allowed to obtain t1 = MACk(m1), …, tn = MACk(mn) for any messages m1, …, mn of its choice • “Break” of security Attacker “breaks” the scheme if it outputs a forgery; i.e., (m, t) with: • m ≠ mi for all i • VrfyK(m, t) = 1

25. Defining security • A MAC is secure if for all attackers running for some time T (e.g., T=100 years), the probability that the attacker “breaks” the scheme is at most  (e.g.,  = 2-80) • The key length lower-bounds  as always • The tag length also lower-bounds  • Is the definition too strong? • When would an attacker be able to obtain tags on any messages of its choice?! • Why do we count it as a break if the adversary outputs a forgery on a meaningless message?!

26. Replay attacks • A MAC inherently cannot prevent replay attacks • Replay attacks must be prevented at a higher level of the protocol! • (Note that whether a replay is ok is application-dependent.) • Replay attacks can be prevented using nonces, timestamps, etc.

27. A MAC for short messages • Let F be a block cipher with n-bit output • To authenticate m using key k, compute t = Fk(m) • Vrfyk(m, t): output 1 iff t = Fk(m) • Why is this secure?

28. (Informal) sketch of security • Replace Fk with a random permutation f • Can do this since F is a block cipher • Seeing f(m1), …, f(mt) does not help (much) to predict f(m) for any m{m1,…,mt} • If adversary outputs (m, t), the probability that t is correct is roughly 2-n • For n large enough, the probability of forgery is small