1 Message authentication codes, modes of operation, and indifferentiability Kan Yasuda (NTT, Japan)...

1

Message authentication codes,modes of operation, andindifferentiability

Kan Yasuda (NTT, Japan)ASK 2011Aug. 31, Singapore

2

Outline

Introduction to modes of operation and to provable security

Recent work on MAC (CRYPTO 2011) Recent work on indifferentiability (Eurocrypt 2

011) Some thoughts on MACs and on indifferentiab

ility

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

Examplesdata

CBC-MACdata data

f f f f

data data data dataMekle-Damgård

6

Provable security

Want to prove: Our construction is secure (in some

sense) if the underlying small primitive is secure (in some sense)

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

Examples

CBC-MAC If the underlying block cipher is a secure pseudo-r

andom permutation, then its CBC-MAC mode is a secure MAC

Merkle-Damgård construction If the underlying compression function is collision-r

esistant, then the entire Merkle-Damgård hash function is also collision-resistant

8

Outline




ility

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)

dataCBC

data data dataPMAC

data data

mask mask mask

Mask needs to be updated at each iteration

14

CBC vs. PMAC

CBC PMAC

Sequential Parallelizable

Only XOR Requires mask update and XOR

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 choicedata

data data data

data data

mask mask mask

$ $ $ $

$ $ $ $

Order of execution does matter

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 functio

n), 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 functio

n), 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 (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 security0.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+2Different 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

tag

finalization

27

Doubling the masking

data data data

mask0 mask0 mask0

tag

finalization

mask1 mask1 mask1

28

Doubling the state

data data data

mask0 mask0 mask0

tag

finalization

mask1 mask1 mask1

mult. by 2 mult. by 2

29

mult. by 2mult. by 2

Doubling the finalization

data data data

mask0 mask0 mask0

tag

finalization

mask1 mask1 mask1

30


The new construction

data data data

mask0 mask0 mask0

tag

finalization

mask1 mask1 mask1

31

Open problem: 1-key construction


data data data

mask0 mask0 mask0

tag

finalization

mask1 mask1 mask1These 2 keys can be made the same

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




ility

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 t

o 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 (instanti

ated) 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

1. Client sends a random challenge C to the server2. Server proves possession of the file M by comput

ing and sending Z <- Hash(M|C)

Secure if Hash is a random oracle

39

chopMD―Indifferentiable hash

Proven by Coron, Dodis, Malinaud and Puniya at CRYPTO 2005

IV

X[1] X[2] X[3] X[m]

Hashvalue

d bits

n bitsTruncated to

n/2 bits(d > n)

f f f f

40

“Counterexample” (again)

Hash-based storage auditing1. Client sends a random challenge C to the server2. Server proves possession of the file M by comput

ing and sending Z <- Hash(M|C)

Insecure if Hash is chopMD

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 bitsTruncated to

n/2 bits(d > n)Y

f f

chopMD insecure?

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




ility

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 securityAssumptions aboutblock cipher / compression function

MAC-secure

PRF / PRP

Goals of MAC scheme

MAC-secure

PRF

Indifferentiable

MAC construction

PRF construction

Indifferentiable construction

47

Some observationsPRF construction

MAC constructio

n

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

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

1 Message authentication codes, modes of operation, and indifferentiability Kan Yasuda (NTT, Japan)...

Documents

Transcript of 1 Message authentication codes, modes of operation, and indifferentiability Kan Yasuda (NTT, Japan)...