1. 1 Message authentication codes, modes of operation, and indifferentiability Kan Yasuda (NTT, Japan) ASK 2011 Aug. 31, Singapore

2. 2 Outline Introduction to modes of operation and to provable security Recent work on MAC (CRYPTO 2011) Recent work on indifferentiability (Eurocrypt 2011) Some thoughts on MACs and on indifferentiability

3. 3 Introduction

4. 4 Modes of operation (domain extension type) We only have “small” primitive (block cipher, compression function) Small primitives have fixed-length input To process large data, we need to iterate our small primitives in some way Modes of operation are constructions that specify how to iterate our small primitives

5. 5 Examples data CBC-MAC data fff f Mekle-Damgård

6. 6 Provable security Want to prove:  Our construction is secure (in some sense) if the underlying small primitive is secure (in some sense) Steps 1. Make an assumption about the security of the small primitive (The notion of security depends on the definition) 2. Reduce the security of the entire construction to that of the underlying primitive

7. 7 Examples CBC-MAC  If the underlying block cipher is a secure pseudo-random permutation, then its CBC-MAC mode is a secure MAC Merkle-Damgård construction  If the underlying compression function is collision-resistant, then the entire Merkle- Damgård hash function is also collision- resistant

8. 8 Outline Introduction to modes of operation and to provable security Recent work on MAC (CRYPTO 2011) Recent work on indifferentiability (Eurocrypt 2011) Some thoughts on MACs and on indifferentiability

9. 9 “A new variant of PMAC: Beyond the birthday bound” (CRYPTO 2011)

10. 10 Introduction MAC (Message Authentication Code)  Symmetric-key primitive  Input: a secret key and (possibly large) data  Output: a fixed-length value (called tag)  Used for integrity check of data data (message) secret key Tag (64-bit, 128-bit, etc.)

11. 11 4 ways to make a MAC 1. design from scratch (dedicated MAC) 2. use a cryptographic hash function (e.g., HMAC) 3. use a universal hash function 4. use a block cipher (e.g., CMAC, PMAC)

12. 12 4 ways to make a MAC 1. design from scratch (dedicated MAC) 2. use a cryptographic hash function (e.g., HMAC) 3. use a universal hash function 4. use a block cipher (e.g., CMAC, PMAC) This work

13. 13 Blockcipher-based MACs (2 types of iteration) data CBC data PMAC data mask Mask needs to be updated at each iteration

14. 14 CBC vs. PMAC CBCPMAC SequentialParallelizable Only XORRequires mask update and XOR

15. 15 Why PMAC? PMAC seems to have a structure easier to analyze (for security proofs) In fact, some of the proof techniques are not applicable to CBC iteration

16. 16 Intuition behind the choice data mask $ $$$ $$$$ Order of execution does matter Can be executed in any order Easier to manipulate events and to evaluate probabilities

17. 17 MAC security Unforgeability  Adversary (without knowing the key) should not be able to produce a valid tag for a new message Pseudo-random  Randomness implies unforgeability  If a MAC is a secure PRF (pseudo-random function), then it is also a secure MAC.

18. 18 MAC security Unforgeability  Adversary (without knowing the key) should not be able to produce a valid tag for a new message Pseudo-random  Randomness implies unforgeability  If a MAC is a secure PRF (pseudo-random function), then it is also a secure MAC. PRF-based MACs are “standard”

19. 19 Birthday problems Ordinary MACs usually provide security only half the block size (n bit) of the underlying cipher For n-bit cipher, only 2^(n/ 2) security For n = 64, 2^32 blocks = 32GBytes 64-bit block ciphers? Triple-DES, HIGHT, PRESENT, LED,... n-bit security 0.5n-bit security

20. 20 2 diffenent birthday problems exist for block-cipher-based MACs Birthday attacks on iterated MACs  Existential forgery is possible on any iterated MACs after 2^(n/2) queries (n the state size)  For CBC-type MACs, even universal forgery is possible PRP – PRF switching lemma  PRP – pseudo-random permutation  A (pseudo-random) permutation can be considered as a function only up to 2^(n/2) queries

21. 21 Security result The new construction achieves 2^(2n/3) security  For n = 64, 2^42.7 blocks = 51TBytes The new MAC is a secure PRF based on the assumption that the underlying block cipher is a secure PRP  Avoid using PRP-PRF switching lemma

22. 22 ISO 9797 (The only) previous construction that achieves security beyond the birthday bound  Achieves (Slightly worse than) 2^(2n/3) security  Rate-1/2 construction, twice as slow (as CMAC, PMAC)

23. 23 ISO 9797 – sum of two CBC MACs Requires 2 encryptions to process a block Block iBlock i+1Block i+2 Block iBlock i+1Block i+2 Different keys

24. 24 Solution – basic idea Want rate-1 construction; only 1 encryption per block...

25. 25 Solution – basic idea Want rate-1 construction; only 1 encryption per block... Double everything but block cipher calls

26. 26 Original PMAC data mask tag finalization

27. 27 Doubling the masking data mask0 tag finalization mask1

28. 28 Doubling the state data mask0 tag finalization mask1 mult. by 2

29. 29 mult. by 2 Doubling the finalization data mask0 tag finalization mask1

30. 30 mult. by 2 The new construction data mask0 tag finalization mask1

31. 31 Open problem: 1-key construction mult. by 2 data mask0 tag finalization mask1 These 2 keys can be made the same by tweaking here (e.g., mult. by 2)... But still a 2-key construction

32. 32 Open problem: Full 2^n security Tripling everything instead of doubling  Possibly 2^(3n/4) security, but not 2^n  4 times, 5 times,... would result in 2^(4n/5), 2^(5n/6) security (at best)  May call them still rate-1, but more and more inefficient The 2^(2n/3) bound may not be tight  No attacks (of this complexity) known  The proofs may be improved

33. 33 Outline Introduction to modes of operation and to provable security Recent work on MAC (CRYPTO 2011) Recent work on indifferentiability (Eurocrypt 2011) Some thoughts on MACs and on indifferentiability

34. 34 Ristenpart, Shacham and Shrimpton: “Careful with composition: Limitation of indifferentiability and …” (Eurocrypt 2011)

35. 35 Indifferentiability Introduced by Maurer, Renner, and Holenstein (TCC2004) Notion of security stronger than indistinguishability / pseudo-randomness The adversary has oracle access to (internal) small components as well as the entire scheme

36. 36 Indifferentiability and (keyless) hash functions The indifferentiability framework was applied to modes of operation for keyless hash functions Coron, Dodis, Malinaud and Puniya CRYPTO 2005 Secure (indifferentiable) hash constructions:  If the compression function is ideal (random), then so is the entire hash function

37. 37 Composability Suppose you have a cryptographic system which is secure in the random oracle model (Interpretation) Composability says:  The random oracle can be safely replaced (instantiated) with an indifferentiable hash function  The system with the indifferentiable hash must be secure if the internal compression function is ideal

38. 38 “Counterexample” (Ristenpart et al. Eurocrypt 2011) Hash-based storage auditing 1. Client sends a random challenge C to the server 2. Server proves possession of the file M by computing and sending Z <- Hash(M|C) Secure if Hash is a random oracle

39. 39 chopMD―Indifferentiable hash Proven by Coron, Dodis, Malinaud and Puniya at CRYPTO 2005 IV X[1]X[2]X[3]X[m] Hash value d bits n bits Truncated to n/2 bits (d > n) ffff

40. 40 “Counterexample” (again) Hash-based storage auditing 1. Client sends a random challenge C to the server 2. Server proves possession of the file M by computing and sending Z <- Hash(M|C) Insecure if Hash is chopMD

41. 41 The server can: -forget M, store Y instead -on challenge C, return f(Y,C) (truncated) We have f(Y,C) (truncated) = Z How to cheat Hash(M|C) -> Z IV M C Z d bits n bits Truncated to n/2 bits (d > n) Y ff chopMD insecure?

42. 42 What is going on? Ristenpart et al. showed that the composability of indifferentiability may not hold true for security notions with multistage adversaries Seems quite difficult to find a “good” solution to fix the problem Limitation of the indifferentiability framework

43. 43 Outline Introduction to modes of operation and to provable security Recent work on MAC (CRYPTO 2011) Recent work on indifferentiability (Eurocrypt 2011) Some thoughts on MACs and on indifferentiability

44. 44 Some thoughts on MACs and on indifferentiability

45. 45 MACs: Three notions of security Unforgeable (minimum requirement) MAC-secure pseudo-random (“standard”) PRF (pseudo-random function) Indifferentiable (strongest)  The notion makes perfect sense in the secret-key setting  Indifferentiability is not only for keyless hash functions

46. 46 MACs: Provable security Assumptions about block cipher / compression function MAC-secure PRF / PRP Goals of MAC scheme MAC-secure PRF Indifferentiable MAC construction PRF construction Indifferentiable construction

47. 47 Some observations PRF construction MAC construction Indifferentiable construction Most PRF constructions are -efficient, and -insecure if state values leaked -Many common constructions -Only inefficient ones known -“transparent”―some security against side-channel attacks Connection? Gap?

48. 48 Conclusion The application of indifferentiability is not limited to keyless hash functions Indifferentiability might be related to MAC security (unforgeability) in some way

49. 49 Thank you