1 message authentication codes, modes of operation, and indifferentiability kan yasuda (ntt, japan)...
TRANSCRIPT
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
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
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
mult. by 2mult. by 2
The new construction
data data data
mask0 mask0 mask0
tag
finalization
mask1 mask1 mask1
31
Open problem: 1-key construction
mult. by 2mult. by 2
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
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
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
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
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