1. CMSC 414 Computer and Network Security Lecture 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. Definitions? kk c = Enc k (m) I know the message m is either m a or m b, but which one? Ciphertext-only attack m1m1 Enc k (m 1 ) m2m2 Enc k (m 2 ) Chosen-plaintext attackChosen-ciphertext attack c’ Dec k (c’) In all cases, a bounded adversary should be unable to determine (with probability much better than ½) whether m a or m b was encrypted

5. Chosen-plaintext security  Is the definition too strong? Voters c Enc k (Obama) Enc k (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 = F K (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 = (K 1, K 2 ); |K| = 112 –Still has the short block length  The “new” block cipher is just: –E K1,K2 (m) = DES K1 (DES -1 K2 (DES K1 (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 –2 128 is a huge number Number of seconds since big bang (estimate): ~2 58 Number of nanoseconds since big bang: ~2 90  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 m 1, …, m n  ECB –C i = F K (m i ); the ciphertext is (C 1, …, C n )  CBC –IV; C i = F K (m i  C i-1 ); the ciphertext is (IV, C 1, …, C n )  OFB (stream cipher mode) –IV; z i = F K (z i-1 ); C i = z i  m i ; the ciphertext is (IV, C 1, …, C n )  CTR (stream cipher mode) –IV; z i = F K (IV+i); C i = z i  m i ; the ciphertext is (IV, C 1,.., C n )  Others…

15. Security?  ECB should not be used –Why?

16. The effect of ECB mode originalencrypted 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. mm’

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: –MAC K (m) = t (we call t the “tag”) –Vrfy K (m, t) = 0/1 (“1” = “accept” / ”0”=“reject”) –Correctness…

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

23. K K MAC usage

24. Defining security  Attack model: –A random key k is chosen –Attacker is allowed to obtain t 1 = MAC k (m 1 ), …, t n = MAC k (m n ) for any messages m 1, …, m n of its choice  “Break” of security Attacker “breaks” the scheme if it outputs a forgery; i.e., (m, t) with: m ≠ m i for all i Vrfy K (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 = F k (m)  Vrfy k (m, t): output 1 iff t = F k (m)  Why is this secure?

28. (Informal) sketch of security  Replace F k with a random permutation f –Can do this since F is a block cipher  Seeing f(m 1 ), …, f(m t ) does not help (much) to predict f(m) for any m  {m 1,…,m t } –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