SLIDE 1 Cryptographic Hash Functions Cryptographic Hash Functions
and their many applications and their many applications Shai Halevi Shai Halevi – – IBM Research IBM Research
USENIX Security USENIX Security – – August 2009 August 2009
Thanks to Charanjit Jutla and Hugo Krawczyk
SLIDE 2 What are hash functions? What are hash functions?
Just a method of compressing strings Just a method of compressing strings
– – E.g., H : {0,1}* E.g., H : {0,1}* {0,1} {0,1}160
160
– – Input is called Input is called “ “message message” ”, output is , output is “ “digest digest” ”
Why would you want to do this? Why would you want to do this?
– – Short, fixed Short, fixed-
- size better than long, variable
size better than long, variable-
size
True also for non True also for non-
crypto hash functions
– – Digest can be added for redundancy Digest can be added for redundancy – – Digest hides possible structure in message Digest hides possible structure in message
SLIDE 3 Typically using Typically using Merkle Merkle-
Damgå ård rd iteration: iteration: 1.
Start from a “ “compression function compression function” ”
– – h: {0,1} h: {0,1}b+n
b+n
{0,1} {0,1}n
n
2.
Iterate it
How are they built? How are they built?
=160 bits |M|=b=512 bits 160 bits
…
M1 M2 ML-1 ML IV=d0 d1 d2 dL-1 dL d=H(M)
But not always…
SLIDE 4 What are they good for? What are they good for?
“ “Request for Candidate Algorithm Nominations Request for Candidate Algorithm Nominations” ”, ,
NIST, November 2007
“Modern, collision resistant hash functions were designed to create small, fixed size message digests so that a digest could act as a proxy for a possibly very large variable length message in a digital
signature algorithm, such as RSA or DSA. These hash functions
have since been widely used for many other “ancillary” applications, including hash-based message authentication codes, pseudo
random number generators, and key derivation functions.”
SLIDE 5 Some examples Some examples
Signatures: Signatures: sign(M sign(M) = RSA ) = RSA-
1( H(M) )
( H(M) ) Message Message-
authentication: tag= tag=H(key,M H(key,M) ) Commitment: Commitment: commit(M commit(M) = H(M, ) = H(M,… …) ) Key derivation: Key derivation: AES AES-
key = H(DH-
value) Removing interaction Removing interaction [Fiat-Shamir, 1987]
– – Take interactive identification protocol Take interactive identification protocol – – Replace one side by a hash function Replace one side by a hash function
Challenge = Challenge = H(smthng H(smthng, context) , context)
– – Get non Get non-
- interactive signature scheme
interactive signature scheme
smthng challenge response A B smthng, response
SLIDE 6 Part I: Random functions Part I: Random functions
- vs. hash functions
- vs. hash functions
SLIDE 7 Random functions Random functions
What we really want is H that behaves What we really want is H that behaves “ “just like a random function just like a random function” ”: :
Digest d=H(M) chosen uniformly for each M Digest d=H(M) chosen uniformly for each M – – Digest d=H(M) has no correlation with M Digest d=H(M) has no correlation with M – – For distinct M For distinct M1
1,M
,M2
2,
,… …, digests , digests d di
i=
=H(M H(Mi
i) are
) are completely uncorrelated to each other completely uncorrelated to each other – – Cannot find collisions, or even near Cannot find collisions, or even near-
collisions – – Cannot find M to Cannot find M to “ “hit hit” ” a specific d a specific d – – Cannot find fixed Cannot find fixed-
points (d = H(d H(d)) )) – – etc. etc.
SLIDE 8 The The “ “Random Random-
Oracle paradigm” ”
1.
- 1. Pretend hash function is really this good
Pretend hash function is really this good 2.
- 2. Design a secure cryptosystem using it
Design a secure cryptosystem using it
Prove security relative to a Prove security relative to a “ “random oracle random oracle” ”
[Bellare-Rogaway, 1993]
SLIDE 9 The The “ “Random Random-
Oracle paradigm” ”
[Bellare-Rogaway, 1993]
1.
- 1. Pretend hash function is really this good
Pretend hash function is really this good 2.
- 2. Design a secure cryptosystem using it
Design a secure cryptosystem using it
Prove security relative to a Prove security relative to a “ “random oracle random oracle” ”
3.
- 3. Replace oracle with a hash function
Replace oracle with a hash function
Hope that it remains secure Hope that it remains secure
SLIDE 10 The The “ “Random Random-
Oracle paradigm” ”
1.
- 1. Pretend hash function is really this good
Pretend hash function is really this good 2.
- 2. Design a secure cryptosystem using it
Design a secure cryptosystem using it
Prove security relative to a Prove security relative to a “ “random oracle random oracle” ”
3.
- 3. Replace oracle with a hash function
Replace oracle with a hash function
Hope that it remains secure Hope that it remains secure
Very successful paradigm, many schemes Very successful paradigm, many schemes
– – E.g., OAEP encryption, FDH,PSS signatures E.g., OAEP encryption, FDH,PSS signatures
Also all the examples from before Also all the examples from before… …
– – Schemes seem to Schemes seem to “ “withstand test of time withstand test of time” ”
[Bellare-Rogaway, 1993]
SLIDE 11 Random oracles: rationale Random oracles: rationale
is some crypto scheme (e.g., signatures), is some crypto scheme (e.g., signatures), that uses a hash function H that uses a hash function H proven secure when H is random function proven secure when H is random function Any attack on real Any attack on real-
world must use must use some some “ “nonrandom property nonrandom property” ” of H
We should have chosen a better H We should have chosen a better H
– – without that without that “ “nonrandom property nonrandom property” ”
Caveat: how do we know what Caveat: how do we know what “ “nonrandom nonrandom properties properties” ” are important? are important?
SLIDE 12 This rationale isn This rationale isn’ ’t sound t sound
Exist signature schemes that are: Exist signature schemes that are:
- 1. Provably secure
- 1. Provably secure wrt
wrt a random function a random function
- 2. Easily broken for EVERY hash function
- 2. Easily broken for EVERY hash function
Idea: hash functions are computable Idea: hash functions are computable
– – This is a This is a “ “nonrandom property nonrandom property” ” by itself by itself
Exhibit a scheme which is secure only Exhibit a scheme which is secure only for for “ “non non-
computable H’ ’s s” ”
– – Scheme is (very) Scheme is (very) “ “contrived contrived” ”
[Canetti-Goldreich-H 1997]
SLIDE 13 Contrived example Contrived example
Start from any secure signature scheme Start from any secure signature scheme
– – Denote signature algorithm by SIG1 Denote signature algorithm by SIG1H
H(key,msg)
(key,msg)
Change SIG1 to SIG2 as follows: Change SIG1 to SIG2 as follows:
SIG2 SIG2H
H(key,msg):
(key,msg): interprate interprate msg msg as code as code Π Π – – If If Π Π(i (i)= )=H(i H(i) for i=1,2,3, ) for i=1,2,3,… …,| ,|msg msg|, then output key |, then output key – – Else output the same as SIG1 Else output the same as SIG1H
H(key,msg)
(key,msg)
If H is random, always the If H is random, always the “ “Else Else” ” case case If H is a hash function, attempting to sign If H is a hash function, attempting to sign the code of H outputs the secret key the code of H outputs the secret key
Some Technicalities
SLIDE 14
Cautionary note Cautionary note
ROM proofs may not mean what you think ROM proofs may not mean what you think… …
– – Still they give valuable assurance, rule out Still they give valuable assurance, rule out “ “almost all realistic attacks almost all realistic attacks” ”
What What “ “nonrandom properties nonrandom properties” ” are important are important for OAEP / FDH / PSS / for OAEP / FDH / PSS / … …? ? How would these scheme be affected by a How would these scheme be affected by a weakness in the hash function in use? weakness in the hash function in use? ROM may lead to careless implementation ROM may lead to careless implementation
SLIDE 15 Merkle Merkle-
Damgå ård rd vs. random functions
Recall: we often construct our hash functions Recall: we often construct our hash functions from compression functions from compression functions
– – Even if compression is random, hash is not Even if compression is random, hash is not
E.g., E.g., H( H(key key|M |M) subject to extension attack ) subject to extension attack
– – H(key H(key | M|M | M|M’ ’) = h( ) = h( H(key|M H(key|M), M ), M’ ’) )
– – Minor changes to MD fix this Minor changes to MD fix this
But they come with a price (e.g. prefix But they come with a price (e.g. prefix-
free encoding)
Compression also built from low Compression also built from low-
level blocks
– – E.g., Davies E.g., Davies-
Meyer construction, h(c,M h(c,M)= )=E EM
M(c)
(c) c c – – Provide yet more structure, can lead to attacks Provide yet more structure, can lead to attacks
- n provable ROM schemes [H
- n provable ROM schemes [H-
- Krawczyk
Krawczyk 2007] 2007]
…
SLIDE 16
Part II: Using hash functions Part II: Using hash functions in applications in applications
SLIDE 17 Using Using “ “imperfect imperfect” ” hash functions hash functions
Applications should rely only on Applications should rely only on “ “specific specific security properties security properties” ” of hash functions
– – Try to make these properties as Try to make these properties as “ “standard standard” ” and and as weak as possible as weak as possible
Increases the odds of long Increases the odds of long-
term security
– – When weaknesses are found in hash function, When weaknesses are found in hash function, application more likely to survive application more likely to survive – – E.g., MD5 is badly broken, but HMAC E.g., MD5 is badly broken, but HMAC-
MD5 is barely scratched barely scratched
SLIDE 18 Security requirements Security requirements
Deterministic hashing Deterministic hashing
– – Attacker Attacker chooses M, d=H(M) chooses M, d=H(M)
Hashing with a random salt Hashing with a random salt
– – Attacker Attacker chooses M, then good guy chooses M, then good guy chooses public salt, d= chooses public salt, d=H( H(salt salt,M ,M) )
Hashing random messages Hashing random messages
– – M random, d=H(M) M random, d=H(M)
Hashing with a secret key Hashing with a secret key
– – Attacker Attacker chooses M, d= chooses M, d=H( H(key key,M ,M) )
Stronger Weaker
SLIDE 19 Deterministic hashing Deterministic hashing
Collision Resistance Collision Resistance
– – Attacker cannot find M,M Attacker cannot find M,M’ ’ such that H(M)=H(M such that H(M)=H(M’ ’) )
Also many other properties Also many other properties
– – Hard to find fixed Hard to find fixed-
points, near-
collisions, M M s.t s.t. H(M) has low Hamming weight, etc. . H(M) has low Hamming weight, etc.
SLIDE 20 Hashing with public salt Hashing with public salt
Target Target-
Collision-
Resistance (TCR)
– – Attacker chooses M, then given random Attacker chooses M, then given random salt salt, , cannot find M cannot find M’
’ such that
such that H(salt,M H(salt,M)= )=H( H(salt salt,M ,M’
’)
)
enhanced TRC ( enhanced TRC (eTCR eTCR) )
– – Attacker chooses M, then given random Attacker chooses M, then given random salt salt, , cannot find cannot find M M’
’,
,salt salt’
’ s.t
s.t. . H( H(salt salt,M ,M)= )=H( H(salt salt’
’,M
,M’
’)
)
SLIDE 21 Hashing random messages Hashing random messages
Second Second Preimage Preimage Resistance Resistance
– – Given random M, attacker cannot find M Given random M, attacker cannot find M’
’
such that H(M)=H(M such that H(M)=H(M’
’)
)
One One-
wayness
– – Given d=H(M) for random M, attacker cannot Given d=H(M) for random M, attacker cannot find M find M’ ’ such that H(M such that H(M’ ’)=d )=d
Extraction* Extraction*
– – For random For random salt salt, high , high-
entropy M, the digest d= d=H( H(salt salt,M ,M) is close to being uniform ) is close to being uniform
* Combinatorial, not cryptographic
SLIDE 22 Hashing with a secret key Hashing with a secret key
Pseudo Pseudo-
Random Functions
– – The mapping The mapping M M H( H(key key,M ,M) for secret ) for secret key key looks random to an attacker looks random to an attacker
Universal hashing* Universal hashing*
– – For all M For all M M M’
’,
, Pr Prkey
key[
[ H( H(key key,M ,M)= )=H( H(key key,M ,M’
’) ]<
) ]<ε ε
* Combinatorial, not cryptographic
SLIDE 23 Application 1: Application 1: Digital signatures Digital signatures
Hash Hash-
then-
sign paradigm
– – First shorten the message, d = H(M) First shorten the message, d = H(M) – – Then sign the digest, s = Then sign the digest, s = SIGN(d SIGN(d) )
Relies on collision resistance Relies on collision resistance
– – If H(M)=H(M If H(M)=H(M’ ’) then s is a signature on both ) then s is a signature on both
Attacks on MD5, SHA Attacks on MD5, SHA-
1 threaten current signatures signatures
– – MD5 attacks can be used to get bad CA cert MD5 attacks can be used to get bad CA cert
[ [Stevens Stevens et al. 2009] et al. 2009]
SLIDE 24 Collision resistance is hard Collision resistance is hard
Attacker works off Attacker works off-
line (find M,M’ ’) )
– – Can use state Can use state-
the-
- art cryptanalysis, as much
art cryptanalysis, as much computation power as it can gather, without computation power as it can gather, without being detected !! being detected !!
Helped by birthday attack (e.g., 2 Helped by birthday attack (e.g., 280
80 vs
vs 2 2160
160)
) Well worth the effort Well worth the effort
– – One collision One collision forgery for any signer forgery for any signer
SLIDE 25 Use randomized hashing Use randomized hashing
– – To sign M, first choose fresh random To sign M, first choose fresh random salt salt – – Set Set d= d= H( H(salt salt, M) , M), , s= SIGN( s= SIGN( salt salt || d ) || d )
Attack scenario (collision game): Attack scenario (collision game):
– – Attacker chooses M, M Attacker chooses M, M’ ’ – – Signer chooses random salt Signer chooses random salt – – Attacker must find M' Attacker must find M' s.t s.t. . H(salt,M H(salt,M) = ) = H(salt,M H(salt,M') ')
Attack is inherently on Attack is inherently on-
line
– – Only rely on target collision resistance Only rely on target collision resistance
Signatures without CRHF Signatures without CRHF
[ [Naor Naor-
Yung 1989, Bellare Bellare-
Rogaway 1997] 1997]
SLIDE 26 TCR hashing for signatures TCR hashing for signatures
Not every randomization works Not every randomization works
– – H(M| H(M|salt salt) may be subject to collision attacks ) may be subject to collision attacks
when H is when H is Merkle Merkle-
Damgå ård rd
– – Yet this is what PSS does (and it Yet this is what PSS does (and it’ ’s provable in the ROM) s provable in the ROM)
Many constructions Many constructions “ “in principle in principle” ”
– – From any one From any one-
way function
Some engineering challenges Some engineering challenges
– – Most constructions use long/variable Most constructions use long/variable-
size randomness, don don’ ’t preserve t preserve Merkle Merkle-
Damgå ård rd
Also, signing salt means changing the underlying Also, signing salt means changing the underlying signature schemes signature schemes
SLIDE 27 Use Use “ “stronger randomized hashing stronger randomized hashing” ”, , eTCR eTCR
– – To sign M, first choose fresh random To sign M, first choose fresh random salt salt – – Set Set d = d = H( H(salt salt, M) , M), , s = SIGN( d ) s = SIGN( d )
Attack scenario (collision game): Attack scenario (collision game):
– – Attacker chooses M Attacker chooses M – – Signer chooses random Signer chooses random salt salt – – Attacker needs Attacker needs M M‘ ‘, ,salt salt’ ’ s.t s.t. . H( H(salt salt,M ,M)= )=H( H(salt salt',M ',M') ')
Attack is still inherently on Attack is still inherently on-
line
[H [H-
Krawczyk 2006] 2006]
Signatures with enhanced TCR Signatures with enhanced TCR
SLIDE 28 Randomized hashing with RMX Randomized hashing with RMX
Use simple message Use simple message-
randomization
– – RMX: M=(M RMX: M=(M1
1,M
,M2
2,
,… …,M ,ML
L), r
), r (r, M (r, M1
1⊕
⊕r r,M ,M2
2⊕
⊕r r, ,… …,M ,ML
L⊕
⊕r r) )
Hash( Hash( RMX(r,M RMX(r,M) ) is ) ) is eTCR eTCR when: when:
– – Hash is Hash is Merkle Merkle-
Damgå ård rd, , and and – – Compression function is ~ 2 Compression function is ~ 2nd
nd-
preimage-
resistant
Signature: [ r, SIGN( Hash( Signature: [ r, SIGN( Hash( RMX(r,M RMX(r,M) )) ] ) )) ]
– – r r fresh per signature, one block (e.g. 512 bits) fresh per signature, one block (e.g. 512 bits) – – No change in Hash, no signing of No change in Hash, no signing of r r
[H [H-
Krawczyk 2006] 2006]
SLIDE 29
…
⊕…⊕ …
Preserving hash Preserving hash-
then-
sign
SLIDE 30
Application 2: Application 2: Message authentication Message authentication
Sender, Receiver, share a secret key Sender, Receiver, share a secret key Compute an Compute an authentication tag authentication tag
– – tag tag = = MAC( MAC(key key, , M M) )
Sender sends ( Sender sends (M M, , tag tag) ) Receiver verifies that Receiver verifies that tag tag matches matches M M Attacker cannot forge tags without key Attacker cannot forge tags without key
SLIDE 31 Authentication with HMAC Authentication with HMAC
Simple key Simple key-
prepend/append have problems /append have problems when used with a when used with a Merkle Merkle-
Damgå ård rd hash hash
– – tag= tag=H( H(key key | M) subject to extension attacks | M) subject to extension attacks – – tag=H(M | tag=H(M | key key) relies on collision resistance ) relies on collision resistance
HMAC: Compute tag = HMAC: Compute tag = H(key H(key | | H(key H(key | M)) | M))
– – About as fast as key About as fast as key-
prepend for a MD hash for a MD hash
Relies only on PRF quality of hash Relies only on PRF quality of hash
– – M M H(key|M H(key|M) looks random when key is secret ) looks random when key is secret
[Bellare Bellare-
Canetti-
Krawczyk 1996 1996]
SLIDE 32 Authentication with HMAC Authentication with HMAC
Simple key Simple key-
prepend/append have problems /append have problems when used with a when used with a Merkle Merkle-
Damgå ård rd hash hash
– – tag= tag=H( H(key key | M) subject to extension attacks | M) subject to extension attacks – – tag=H(M | tag=H(M | key key) relies on collision resistance ) relies on collision resistance
HMAC: Compute tag = HMAC: Compute tag = H(key H(key | | H(key H(key | M)) | M))
– – About as fast as key About as fast as key-
prepend for a MD hash for a MD hash
Relies only on PRF property of hash Relies only on PRF property of hash
– – M M H(key|M H(key|M) looks random when key is secret ) looks random when key is secret
[Bellare Bellare-
Canetti-
Krawczyk 1996 1996]
As a result, barely affected by collision attacks on MD5/SHA1
SLIDE 33 Carter Carter-
Wegman authentication authentication
Compress message with hash, t=H( Compress message with hash, t=H(key key1
1,M)
,M) Hide t using a PRF, tag = t Hide t using a PRF, tag = t PRF( PRF(key key2
2,nonce)
,nonce)
– – PRF can be AES, HMAC, RC4, etc. PRF can be AES, HMAC, RC4, etc. – – Only applied to a short nonce, typically not a Only applied to a short nonce, typically not a performance bottleneck performance bottleneck
Secure if the PRF is good, H is Secure if the PRF is good, H is “ “universal universal” ”
– – For M For M M M’
’,
,∆ ∆, , Pr Prkey
key[
[ H( H(key key,M) ,M) H( H(key key,M ,M’
’)=
)=∆ ∆ ]< ]<ε ε) ) – – Not cryptographic, can be very fast Not cryptographic, can be very fast
[Wegman Wegman-
Carter 1981,… …]
SLIDE 34 Fast Universal Hashing Fast Universal Hashing
“ “Universality Universality” ” is combinatorial, provable is combinatorial, provable
no need for no need for “ “security margins security margins” ” in design in design
Many works on fast implementations Many works on fast implementations
From inner From inner-
product, Hk1,k2
k1,k2(M
(M1
1,M
,M2
2)=(
)=(K K1
1+M
+M1
1)
)· ·( (K K2
2+M
+M2
2)
)
[H [H-
Krawczyk’ ’97, Black et al. 97, Black et al.’ ’99, 99, … …] ]
From polynomial evaluation H From polynomial evaluation Hk
k(M
(M1
1,
,… …,M ,ML
L)=
)=Σ Σi
i M
Mi
i k
ki
i
[Krawczyk [Krawczyk’ ’94, Shoup 94, Shoup’ ’96, Bernstein 96, Bernstein’ ’05, McGrew 05, McGrew-
Viega’ ’06, 06,… …] ]
As fast as 2 As fast as 2-
3 cycle-
per-
byte (for long M’ ’s) s)
– – Software implementation, contemporary CPUs Software implementation, contemporary CPUs
SLIDE 35
Part III: Part III: Designing a hash function Designing a hash function
Fugue: IBM Fugue: IBM’ ’s candidate for the s candidate for the NIST hash competition NIST hash competition
SLIDE 36 Design a compression function? Design a compression function?
PROs PROs: modular design, reduce to the : modular design, reduce to the “ “simpler simpler problem problem” ” of compressing fixed
- f compressing fixed-
- length strings
length strings
– – Many things are known about transforming Many things are known about transforming compression into hash compression into hash
CONs CONs: : compression compression hash hash has its problems has its problems
– – It It’ ’s not free (e.g. message encoding) s not free (e.g. message encoding) – – Some attacks based on the MD structure Some attacks based on the MD structure
Extension attacks ( rely on Extension attacks ( rely on H(x|y H(x|y)= )=h(H(x),y h(H(x),y) ) ) ) “ “Birthday attacks Birthday attacks” ” (herding, (herding, multicollisions multicollisions, , … …) ) …
SLIDE 37 Find many off Find many off-
line collisions
– – “ “Tree structure Tree structure” ” with ~2 with ~2n/3
n/3 d
di,j
i,j’
’s s – – Takes ~ 2 Takes ~ 22n/3
2n/3 time
time
Publish final d Publish final d Then for any prefix P Then for any prefix P
– – Find Find “ “linking block linking block” ” L L s.t s.t. H(P|L) in the tree . H(P|L) in the tree – – Takes ~ 2 Takes ~ 22n/3
2n/3 time
time – – Read off the tree the suffix S to get to d Read off the tree the suffix S to get to d
Show an extension of P Show an extension of P s.t s.t. H(P|L|S) = d . H(P|L|S) = d
Example attack: herding Example attack: herding
[Kelsey-Kohno 2006]
d2,1
d
M1,1 M1,2 M1,3 M1,4 M2,1 M2,2
d1,1 d1,2 d1,3 d1,4 d2,2
SLIDE 38 The culprit: small intermediate state The culprit: small intermediate state
With a compression function, we: With a compression function, we:
– – Work hard on current message block Work hard on current message block – – Throw away this work, keep only n Throw away this work, keep only n-
bit state
Alternative: keep a large state Alternative: keep a large state
– – Work hard on current message block/word Work hard on current message block/word – – Update some part of the big state Update some part of the big state
More flexible approach More flexible approach
– – Also more opportunities to mess things up Also more opportunities to mess things up
SLIDE 39 The hash function The hash function Grindahl Grindahl
State is 13 words = 52 bytes State is 13 words = 52 bytes Process one 4 Process one 4-
byte word at a time
– – One AES One AES-
- like mixing step per word of input
like mixing step per word of input
After some final processing, output 8 words After some final processing, output 8 words Collision attack by Collision attack by Peyrin Peyrin (2007) (2007)
– – Complexity ~ 2 Complexity ~ 2112
112 (still better than brute
(still better than brute-
force)
Recently improved to ~ 2 Recently improved to ~ 2100
100 [
[Khovratovich Khovratovich 2009] 2009]
– – “ “Start from a collision and go backwards Start from a collision and go backwards” ”
[Knudsen Knudsen-
Rechberger-
Thomsen 2007]
SLIDE 40 The hash function The hash function “ “Fugue Fugue” ”
Proof Proof-
driven design
– – Designed to enable analysis Designed to enable analysis Proofs that Proofs that Peyrin Peyrin-
- style attacks do not work
style attacks do not work
State of 30 4 State of 30 4-
byte words = 120 bytes Two Two “ “super super-
mixing” ” rounds per word of input rounds per word of input
– – Each applied to only 16 bytes of the state Each applied to only 16 bytes of the state – – With some extra linear diffusion With some extra linear diffusion
Super Super-
mixing is AES-
like
– – But uses stronger MDS codes But uses stronger MDS codes
[H-Hall-Jutla 2008]
SLIDE 41 Initial State (30 words) Process New State M1 Mi Final Processing Output 8 words = 256 bits Iterate State
Fugue Fugue-
256
SLIDE 42 Initial State (30 words) Process New State ∆M1 ∆Mi Final Processing ∆ = 0 Iterate State
Collision attacks Collision attacks
∆ State = 0?
∆ State = 0 Internal collision ∆ State 0 External collision
Collision means that ∆Mi’s are not all zero
Think of M1, …,ML and M’1,…,M’L
SLIDE 43 Initial State (30 words) Process New State Final Stage Iterate State Process M1 SMIX M1 Repeat 2-4 once more
Processing one input word Processing one input word
- 1. Input one word
- 2. Shift 3 columns to right
- 3. XOR into columns 1-3
- 4. “super-mix” operation
- n columns 1-4
This is where the crypto happens
SLIDE 44 SMIX in Fugue SMIX in Fugue
Similar to one AES round Similar to one AES round
– – Works on a 4x4 matrix of bytes Works on a 4x4 matrix of bytes – – Starts with S Starts with S-
box substitution
Byte b, S[256] = {...}; Byte b, S[256] = {...}; ... ... b = b = S[b S[b]; ];
– – Does linear mixing Does linear mixing
Stronger mixing than AES Stronger mixing than AES
– – Diagonal bytes as in AES Diagonal bytes as in AES – – Other bytes are mixed into both column and row Other bytes are mixed into both column and row
SLIDE 45 SMIX in Fugue SMIX in Fugue
In algebraic notation: In algebraic notation: M generates a good linear code M generates a good linear code
– – If all the b If all the bi
i’
’ bytes but 4 are zero bytes but 4 are zero then then ≥ ≥ 13 of the 13 of the S[b S[bi
i] bytes must be nonzero
] bytes must be nonzero – – And other such properties And other such properties
b16
= M16x16
×
b2 b1
'
' '
S[b2] S[b1]
S[b16]
SLIDE 46
Analyzing internal collisions* Analyzing internal collisions*
SMIX ∆ After last input word: ∆State=0 before input word: ∆10 ≤4 nonzero byte diffs before SMIX: ∆1-40 still ∆1-40 now ∆28-10 3 columns * a bit oversimplified
SLIDE 47
Analyzing internal collisions* Analyzing internal collisions*
SMIX ∆ after input word: ∆State=0 before input word: ∆10 before SMIX: ∆1-40 still ∆1-40 now ∆28-10 3 columns SMIX ∆28-40 ∆28-40 3 columns ∆25-10 ≤4 nonzero byte diffs * a bit oversimplified
SLIDE 48
Analyzing internal collisions* Analyzing internal collisions*
SMIX ∆ after input word: ∆State=0 before input word: ∆10 before SMIX: ∆1-40 still ∆1-40 now ∆28-10 3 columns SMIX ∆28-40 ∆28-40 3 columns ∆25-10 ∆ ∆ ∆ ∆’ before input: ∆1=?, ∆25-300 * a bit oversimplified
SLIDE 49
The analysis from previous slides was upto here Many nonzero byte differences before the SMIX operations
SLIDE 50
SLIDE 51 Analyzing internal collisions Analyzing internal collisions
What does this mean? Consider this attack: What does this mean? Consider this attack:
– – Attacker feeds in random M Attacker feeds in random M1
1,M
,M2
2,
,… … and M and M’ ’1
1,M
,M’ ’2
2,
,… … – – Until Until State StateL
L
State State’ ’L
L = some
= some “ “good good ∆ ∆” ” – – Then it searches for suffixed (M Then it searches for suffixed (ML+1
L+1,
,… …,M ,ML+4
L+4),
), (M (M’ ’L+1
L+1,
,… …,M ,M’ ’L+4
L+4) that will induce internal collision
) that will induce internal collision
Theorem Theorem* *: For any fixed : For any fixed ∆ ∆, , Pr[ Pr[ ∃ ∃ suffixes that induce collision ] < 2 suffixes that induce collision ] < 2-
150
* Relies on a very mild independence assumptions * Relies on a very mild independence assumptions
SLIDE 52
Analyzing internal collisions Analyzing internal collisions
Why do we care about this analysis? Why do we care about this analysis? Peyrin Peyrin’ ’s s attacks are of this type attacks are of this type All differential attacks can be seen as All differential attacks can be seen as (optimizations of) this attack (optimizations of) this attack
– – Entities that are not controlled by attack are Entities that are not controlled by attack are always presumed random always presumed random
A known A known “ “collision collision trace trace” ” is as close as we is as close as we can get to understanding collision resistance can get to understanding collision resistance
SLIDE 53 Fugue: concluding remarks Fugue: concluding remarks
Similar analysis also for external collisions Similar analysis also for external collisions
– – “ “Unusually thorough Unusually thorough” ” level of analysis level of analysis
Performance comparable to SHA Performance comparable to SHA-
256
– – But more amenable to parallelism But more amenable to parallelism
One of 14 submissions that were selected One of 14 submissions that were selected by NIST to advance to 2 by NIST to advance to 2nd
nd round of the
round of the SHA3 competition SHA3 competition
SLIDE 54 Morals Morals
Hash functions are very useful Hash functions are very useful We want them to behave We want them to behave “ “just like random just like random functions functions” ”
– – But they don But they don’ ’t really t really
Applications should be designed to rely on Applications should be designed to rely on “ “as weak as practical as weak as practical” ” properties of hashing properties of hashing
– – E.g., TCR/ E.g., TCR/eTCR eTCR rather than collision rather than collision-
resistance
A taste of how a hash function is built A taste of how a hash function is built
SLIDE 55
Thank you! Thank you!
