Transcript A Single-Key Domain Extender for Privacy

Message authentication codes,
modes of operation, and
indifferentiability
Kan Yasuda (NTT, Japan)
ASK 2011
Aug. 31, Singapore
1
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
2
Introduction
3
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
4
Examples
CBC-MAC
data
data
Mekle-Damgård
data
data
data
f
f
data
data
f
f
5
Provable security
Want to prove:


Our construction is secure (in some sense) if
the underlying small primitive is secure (in
some sense)
Steps

1.
2.
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
6
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 MerkleDamgård hash function is also collisionresistant
7
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
8
“A new variant of PMAC:
Beyond the birthday bound”
(CRYPTO 2011)
9
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.)
10
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)
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)
This work
12
Blockcipher-based MACs
(2 types of iteration)
CBC
data
data
data
PMAC
data
data
data
mask
mask
mask
Mask needs to be updated at each iteration 13
CBC vs. PMAC
CBC
PMAC
Sequential
Parallelizable
Only XOR
Requires mask
update and XOR
14
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
15
Intuition behind the choice
$
data
data
data
$
$
$
Order of execution does matter
data
mask
$
data
mask
$
data
mask
$
$
Can be executed in any order
Easier to manipulate events and to evaluate probabilities
16
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.
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.
PRF-based MACs are “standard”
18
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
19
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
20
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
21
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)
22
ISO 9797 – sum of two CBC MACs

Requires 2 encryptions to process a block
Different keys
Block i
Block i+1
Block i+2
Block i
Block i+1
Block i+2
23
Solution – basic idea
Want rate-1 construction;
only 1 encryption per block . . .
24
Solution – basic idea
Want rate-1 construction;
only 1 encryption per block . . .
Double everything but block cipher calls
25
Original PMAC
data
mask
data
mask
data
mask
finalization
tag
26
Doubling the masking
data
data
data
mask0
mask0
mask0
mask1
mask1
mask1
finalization
tag
27
Doubling the state
data
data
data
mask0
mask0
mask0
mask1
mask1
mask1
finalization
tag
mult. by 2
mult. by 2
28
Doubling the finalization
data
data
data
mask0
mask0
mask0
mask1
mask1
mask1
finalization
tag
mult. by 2
mult. by 2
29
The new construction
data
data
data
mask0
mask0
mask0
mask1
mask1
mask1
finalization
tag
mult. by 2
mult. by 2
30
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
31
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
32
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
33
Ristenpart, Shacham and Shrimpton:
“Careful with composition:
Limitation of
indifferentiability and …”
(Eurocrypt 2011)
34
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
35
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
36
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
37
“Counterexample” (Ristenpart et
al. Eurocrypt 2011)
Hash-based storage auditing

1.
2.

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
38
chopMD―Indifferentiable hash
X[1]
X[2]
X[3]
X[m]
d bits
IV
f
f
n bits
(d > n)
f
f
Hash
value
Truncated to
n/2 bits
Proven by Coron, Dodis, Malinaud and Puniya
at CRYPTO 2005
39
“Counterexample” (again)
Hash-based storage auditing

1.
2.

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
40
How to cheat Hash(M|C) -> Z
The server can:
-forget M, store Y instead
-on challenge C, return f(Y,C) (truncated)
C
M
We have f(Y,C) (truncated) = Z
d bits
f
IV
f
n bits
(d > n)
Y
Z
Truncated to
n/2 bits
chopMD insecure?
41
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
42
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
43
Some thoughts on MACs
and on
indifferentiability
44
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
45
MACs: Provable security
Assumptions about
block cipher /
compression function
MAC construction
MAC-secure
PRF construction
Goals of MAC scheme
MAC-secure
PRF
PRF / PRP
Indifferentiable
construction
Indifferentiable
46
Some observations
PRF construction
Most PRF constructions are
-efficient, and
-insecure if state values leaked
Gap?
Connection?
MAC
Indifferentiable
construction
construction
-Many common constructions
-Only inefficient ones known
-“transparent”―some security
against side-channel attacks
47
Conclusion


The application of indifferentiability
is not limited to keyless hash
functions
Indifferentiability might be related to
MAC security (unforgeability) in some
way
48
Thank you
49