Cryptography Lecture 11

Midterm exam Exam is 1 week from today May try to find an overflow room Will post information on Piazza Covers material up to and including today’s lecture Open book/notes No electronic devices Practice midterm posted

(Basic) CBC-MAC m1 m2 ml   … Fk Fk Fk t

Security of (basic) CBC-MAC? If F is a pseudorandom function with block length n, then for any fixed l basic CBC-MAC is a secure MAC for messages of length l·n The sender and receiver must agree on the length parameter l in advance Basic CBC-MAC is not secure if this is not done! See Exercise 4.13

CBC-MAC extensions Several ways to handle variable-length messages One of the simplest: prepend the message length before applying (basic) CBC-MAC

CBC-MAC l m1 m2 ml    … Fk Fk Fk Fk t

CBC-MAC extensions Several ways to handle variable length messages One of the simplest: prepend the message length before applying (basic) CBC-MAC Can also be adapted to handle messages whose length is not a multiple of the block length

Back to secrecy…

So far… In the context of encryption (privacy), we have been considering only a passive, eavesdropping attacker

c1  Enck(m1) … ct  Enck(mt) ... k k ct m1, …, mt c1  Enck(m1) … ct  Enck(mt)

So far… What if the attacker can be active? Modifying what is sent over the channel Injecting traffic on the channel

c c’ k k c  Enck(m) m’ := Deck(c')

Malleability (Informal:) A scheme is malleable if it is possible to modify a ciphertext and thereby cause a predictable change to the plaintext Malleability can be dangerous! E.g., encrypted bank transactions

Malleability All the encryption schemes we have seen so far are malleable! E.g., the one-time pad...

c1c2…cn c1c2…c’n k k c := (m1m2…mn)k m1m2…m’n := (c1c2…c’n)k

Malleability All the schemes we have seen so far are malleable! E.g., the one-time pad... Perfect secrecy does not imply non-malleability! Similar attacks (and sometimes others) on all the encryption schemes we have seen so far

Chosen-ciphertext attacks Models settings in which the attacker can influence what gets decrypted, and observe the effects I.e., interact with the receiver (who decrypts) in addition to the sender (who encrypts)

c k k c  Enck(m) m’ := Deck(c') c’ m’

Chosen-ciphertext attacks Models settings in which the attacker can influence what gets decrypted, and observe the effects How to model? Allow attacker to submit ciphertexts of its choice* to the receiver, and learn the corresponding plaintext In addition to being able to carry out a chosen-plaintext attack! *With one restriction, described next

CCA-security Define a randomized exp’t PrivCCAA,(n): k  Gen(1n) A(1n) interacts with an encryption oracle Enck(·), and a decryption oracle Deck(·), and then outputs m0, m1 of the same length b  {0,1}, c  Enck(mb), give c to A A continues to interact with Enck(·) and Deck(·), but may not request decryption of c A outputs b’; A succeeds if b = b’, and experiment evaluates to 1 in this case

CCA-security  is secure against chosen-ciphertext attacks (CCA-secure) if for all PPT attackers A, there is a negligible function  such that Pr[PrivCCAA,(n) = 1] ≤ ½ + (n)

Chosen-ciphertext attacks and malleability If a scheme is malleable, then it cannot be CCA-secure Modify c, submit modified ciphertext c’ to the decryption oracle and determine (information about) the original message based on the result CCA-security implies non-malleability So we will focus on CCA-security

CCA-security In the definition of CCA-security, the attacker can obtain the decryption of any ciphertext of its choice (besides the challenge ciphertext) Is this realistic? We show a scenario where: One bit about decrypted ciphertexts is leaked The scenario occurs in the real world! It can be exploited to learn the entire plaintext

CBC-mode encryption m1 m2 ml IV    … Fk Fk Fk c0 c1 c2 cl

CBC-mode decryption m1 m2 ml    … Fk-1 Fk-1 Fk-1 c0 c1 c2 cl

Observation If an attacker modifies ci-1, this causes a predictable change to mi

Arbitrary-length messages? Message  encoded data  ciphertext PKCS #5 encoding: Assume message is an integral # of bytes Let L be the block length (in bytes) of the cipher Let b ≥ 1 be # of bytes that need to be appended to the message to get length a multiple of L 1 ≤ b ≤ L; note b  0 Append b (encoded in 1 byte), b times I.e., if 3 bytes of padding are needed, append 0x030303

Decryption? Use CBC-mode decryption to obtain encoded data Say the final byte of encoded data has value b If b=0 or b > L, return “error” If final b bytes of encoded data are not all equal to b, return “error” Otherwise, strip off final b bytes of the encoded data, and output what remains as the message

Example (L=8) AB 01 4F 21 00 7C 02 02 AB 01 4F 21 00 7C 02 02

c k k c  Enck(m) Deck(c') c’ error? Padding oracle!

Padding oracles Padding oracles are frequently present in, e.g., web applications Even if an error is not explicitly returned, an attacker might be able to detect differences in timing, behavior, etc.

Main idea of the attack Consider a two-block ciphertext IV, c Encoded data = Fk-1(c)  IV Goal is to learn the encoded data Main observation: If an attacker modifies (only) the ith byte of IV, this causes a predictable change (only) to the ith byte of the encoded data

 = Fk-1(c): IV: “Success” “Error” XX XX XX XX XX XX XX XX 98 AB 01 4F 0x9E  0x06 Fk-1(c): XX XX XX XX XX XX XX XX 98  IV: AB 01 4F 21 00 7C 02 9E = Encoded data: XX XX XX XX 06 XX 06 06 XX XX 06 XX 06 “Success” “Error”

 plaintext byte = XX  0x01 = 0x47 Fk-1(c): XX XX XX XX XX XX XX 98  0x02  0x06  0x07 0x98  0x07 IV: AB 00 41 01 01 02 4E 4F 20 21 01 00 7D 7C 02 03 9F 9E = Encoded data: XX XX 07 07 06 06 07 07 06 06 07 06 07 06 07 XX  0x41 = 0x07  XX = 0x41  0x07  plaintext byte = XX  0x01 = 0x47 “Success!”

Attack complexity? ≤ L tries to learn the # of padding bytes ≤ 28 = 256 tries to learn each plaintext byte

CCA-security: a summary Chosen-ciphertext attacks are a significant, real-world threat Modern encryption schemes are designed to be CCA-secure None of the schemes we have seen so far is CCA-secure

A CCA-secure scheme Idea: combine encryption with integrity Use a CPA-secure encryption scheme to encrypt the message Use a MAC to prevent the ciphertext from being modified! “Encrypt-then-authenticate”

Encrypt then authenticate c, t k1, k2 k1, k2 m c  Enck1(m) t = Mack2(c) Vrfyk2(c, t) = 1? m = Deck1(c)

Security? If the underlying encryption scheme is CPA-secure and the MAC is secure (with unique tags) then the combination is a CCA-secure encryption scheme Note: independent keys must be used!

Authenticated encryption

Secrecy + integrity? We have shown primitives for achieving secrecy and integrity in the private-key setting What if we want to achieve both? Against active attackers

Authenticated encryption An encryption scheme that achieves both secrecy and integrity Secrecy notion: CCA-security Integrity notion: unforgeability Adversary cannot generate any ciphertext that decrypts to a previously unencrypted message This is not implied by CCA-security

Authenticated encryption Encrypt-then-authenticate works! If the underlying encryption scheme is CPA-secure and the MAC is secure (with unique tags) then the combination is an AE scheme This is the recommended generic approach to constructing an AE scheme “Generic” = using any CPA-secure scheme and any secure MAC

Other generic constructions? Encrypt and authenticate Authenticate-then-encrypt

Encrypt and authenticate c, t k1, k2 k1, k2 m c  Enck1(m) t = Mack2(m) m = Deck1(c) Vrfyk2(m, t) = 1?

Problems The tag t might leak information about m! Nothing in the definition of security for a MAC implies that it hides information about m So the combination may not even be EAV-secure If the MAC is deterministic (as is CBC-MAC), then the tag leaks whether the same message is encrypted twice I.e., the combination will not be CPA-secure

Authenticate-then-encrypt k1, k2 k1, k2 m t = Mack2(m) c  Enck1(m | t) m | t = Deck1(c) Vrfyk2(m, t) = 1?

Problems Padding-oracle attack still works (if possible to distinguish padding failure from MAC failure) Other counterexamples are also possible The combination may not be CCA-secure

Authenticated encryption Encrypt-then-authenticate is the preferred generic approach for building an AE scheme

Direct constructions Other, more-efficient constructions have been proposed and are an active area of research and standardization E.g., OCB, CCM, GCM Active competition: https://competitions.cr.yp.to/caesar.html