1. CMSC 414 Computer and Network Security Lecture 5 Jonathan Katz

2. Administrative announcements  Midterm I –March 6  GRACE accounts set up –Need to have a glue account –HW submission done using GRACE submit script  Finding a partner –Email TA with “partner-414” in subject line

3. Message integrity

4. 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? –Lack of integrity can lead to lack of secrecy –Almost always, integrity is needed in addition to secrecy

5. Message authentication codes (MACs)  In the private-key setting, the correct tool for achieving message integrity is a MAC  Functionality: –MAC K (m) = t (“tag”) –Vrfy K (m, t) = 0/1 (“1” = “accept” / ”0”=“reject”) –Correctness…  Security?

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

7. 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 ) –Note that length of the tag 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?!

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

9. Hash functions  A (cryptographic) hash function H maps arbitrary length inputs to a fixed-length output  Main goal is collision resistance: –Hard to find distinct x, x’ such that H(x) = H(x’) –Birthday attacks show that output length of H is critical  Other goals –Second pre-image resistance: given x, hard to find x’ ≠ x with H(x) = H(x’) Weaker than collision resistance –“Random-looking output”: I.e., “acts like a random oracle” Controversial

10. Hash functions in practice  MD5 –128-bit output –No longer collision resistant (as of 2004) Still second pre-image resistant (for now…) –Still widely deployed…  SHA-1 –160-bit output –No collisions known (yet), but theoretical attacks exist  SHA-2 –256-/512-bit outputs  Competition to design new hash standard has just begun…

11. Hash-and-MAC  Say we have a secure MAC for “short” messages –How to extend it for longer messages?  Hash and MAC –Hash message to short “digest” –MAC the digest  Not used in practice for MACs –But used extensively for signatures (see later) –Similar ideas used in practical MAC constructions HMAC M H(M) K t

12. MACs in practice  CBC-MAC –Can be constructed from any block cipher –Directly handles long messages (without hashing) –“Standard” variant is insecure if used on messages of different lengths Known fixes for variable-length messages – make sure to use!  HMAC –Constructed from a hash function –Directly handles long messages (hashing done as part of construction)

13. Encryption + integrity  In most settings, confidentiality and integrity are both needed –How to obtain both?  Three “natural” possibilities: –Encrypt-and-authenticate –Authenticate-then-encrypt –Encrypt-then-authenticate  Only the latter is problem-free…  Can also use dedicated mode of encryption

15. Toward public-key crypto…

16. Sharing keys?  Secure sharing of a key is necessary for private- key crypto –How do parties share a key in the first place?  One possibility is a secure physical channel –E.g., in-person meeting –Dedicated (un-tappable) phone line –USB stick via courier service  Another possibility: key exchange protocols –Parties can agree on a key over a public channel –This is amazing! (And marked a revolution in crypto…)

17. Diffie-Hellman key exchange  Modular arithmetic, Z N, Z N *  Diffie-Hellman protocol  Security? –Secure against passive eavesdropping only  We will cover stronger notions of security for key exchange in much more detail later in the semester

18. The Diffie-Hellman protocol prime p, element g  Z p * h A = g x mod p h B = g y mod p K AB = (h B ) x K BA = (h A ) y

19. Security?  Consider security against a passive eavesdropper  Under the computational Diffie-Hellman (CDH) assumption, hard for an eavesdropper to compute K AB = K BA –Not enough for security! –Can hash the key before using  Under the decisional Diffie-Hellman (DDH) assumption, the key K AB looks random to an eavesdropper

20. Technical notes  p and g must be chosen so that the CDH/DDH assumptions hold –Need to be chosen with care –Details in CMSC456  Can also use other groups –Elliptic curves are also popular  Modular exponentiation can be done quickly (in particular, in polynomial time) –But the naïve algorithm does not work!

21. Security against active attacks?  The basic Diffie-Hellman protocol we have shown is not secure against a ‘man-in-the-middle’ attack  In fact, impossible to achieve security against such an attacker unless some information is shared in advance –E.g., private-key setting –Or public-key setting (next)