Message authentication codes, modes of operation, and indifferentiability

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

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

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. Examples data data data CBC-MAC Mekle-Damgård data data data data f f f f

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

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. 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. “A new variant of PMAC: Beyond the birthday bound”(CRYPTO 2011)

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. 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. 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. Blockcipher-based MACs(2 types of iteration) data data data CBC PMAC data data data mask mask mask Mask needs to be updated at each iteration

14. CBC vs. PMAC

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. Intuition behind the choice data data data $ $ $ $ Order of execution does matter data data data mask mask mask $ $ $ $ Can be executed in any order Easier to manipulate events and to evaluate probabilities

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. 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. Birthday problems • Ordinary MACs usually provide security only half the block size (nbit) 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. 2 diffenent birthday problemsexist 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. 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. 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. ISO 9797 – sum of two CBC MACs • Requires 2 encryptions to process a block Block i Block i+1 Block i+2 Block i Block i+1 Block i+2 Different keys

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

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

26. Original PMAC data data data mask mask mask finalization tag

27. Doubling the masking data data data mask0 mask0 mask0 mask1 mask1 mask1 finalization tag

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

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

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

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

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. 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. Ristenpart, Shacham and Shrimpton:“Careful with composition: Limitation of indifferentiability and …”(Eurocrypt 2011)

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

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

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

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

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. 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. Some thoughts on MACs and on indifferentiability

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. MACs: Provable security Assumptions about block cipher / compression function Goals of MAC scheme MAC construction MAC-secure PRF / PRP MAC-secure PRF Indifferentiable PRF construction Indifferentiable construction

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

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. Thank you