shai halevi and hugo krawczyk ibm research l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Randomized Hashing: Secure Digital Signatures without Collision Resistance PowerPoint Presentation
Download Presentation
Randomized Hashing: Secure Digital Signatures without Collision Resistance

Loading in 2 Seconds...

play fullscreen
1 / 37

Randomized Hashing: Secure Digital Signatures without Collision Resistance - PowerPoint PPT Presentation


  • 463 Views
  • Uploaded on

Shai Halevi and Hugo Krawczyk IBM Research Randomized Hashing: Secure Digital Signatures without Collision Resistance http://www.ee.technion.ac.il/~hugo/rhash/ The Problem (summary) Cryptography in crisis:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Randomized Hashing: Secure Digital Signatures without Collision Resistance


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
shai halevi and hugo krawczyk ibm research
Shai Halevi and Hugo Krawczyk

IBM Research

Randomized Hashing:Secure Digital Signatureswithout Collision Resistance

http://www.ee.technion.ac.il/~hugo/rhash/

the problem summary
The Problem (summary)
  • Cryptography in crisis:
    • Two main components of cryptographic systems (MD5 and SHA1 hash functions) have been broken or severely weakened
    • Attack against the collision resistance*of these ubiquitous cryptographic hash functions [Wang et al 2004-2006]
    • Standard digital signatures fully rely on collision resistance and hence are seriously endangered
      • Digital signatures crucial to electronic security (PK certificates, code signing, e-commerce)
  • Must design stronger hash functions (but do we know how?)
  • Or build systems that do not rely on collision resistance
digital signatures and hash functions
Digital signatures and hash functions
  • Cryptographic signature
    • Msg M, signer’s key  signature (unique to signer and msg) outputs pair: M, sign(M)
    • But signature operation expensive: needs to “compress” M before applying a signature
    • Instead of signing M, one signs H(M) (a fixed length string) outputs pair: M, sign(H(M)) “hash-then-sign”
    • Fine if it is hard to find M’ such that H(M)=H(M’)
    • Otherwise: a signature on M is equivalent to a signature on M’
an example
An example
  • Remember that we sign H(M) rather than M, that is, signature on M = sign(H(M))
  • Attack: find two messages M'M s.t. H(M)=H(M')
    • Get signature on M you also have a signature on M’ !
    • For example: M = “I’ll pay Hugo $0000100 – ref. 21245376”

M'= “I’ll pay Hugo $1000000 – ref. 63598621”

    • You sign M, I go to court claiming M’(note: ref # helps attack)
  • A hash function for which it is hard to find M'M s.t. H(M)=H(M') is called collision resistant

(CRHF)

collision resistance endangered
Collision Resistance Endangered
  • Crucial for security of digital signatures
    • Digital signatures crucial to electronic security
  • Unfortunately, recent attacks broke/threatened collision resistance of the two standard hash functions (MD5, SHA-1)
  • NIST standardized new functions (SHA2) and is running a public competition for new hash function
    • But confidence is low. What if new functions broken in 10 years?
achieving collision resistance is hard
Achieving Collision Resistance is Hard
  • Attacker works off-line(find M,M’, H(M)=H(M’), no key, no secret)
    • Can use state-of-the-art cryptanalysis, as much computation power as it can gather, and without being detected !!
  • Helped by birthday attack: 280 vs 2160(a brute force shortcut)
    • From 280 to 260 it is only a 20-bit improvement!
  • Worth the effort
    • Especially for forging digital signatures:

one collision  many msgs, any signer

what can we do

Provably

What Can We Do?
  • Build new hash functions: But do we know how?
    • SHA-1 was considered safe before Wang attacks (though seeds in 98)
    • SHA2 built on same “SHA-1 technology”before these attacks
    • Attacks taught us to be cautious but not necessarily how to build new functions
    • Yet, new hash functions are needed (NIST competition)
  • In addition (in parallel):
    • Design applications to rely as little as possible on collision resistance
    • Trust the math, not the cryptographers…

what if new CRHF broken after 5 years

our proposal randomized hashing
Our Proposal: Randomized Hashing
  • Avoid collision resistance all together (in digital signatures)
    • Build digital signatures that do not require collision resistance
    • Without having to invent (and deploy) new signature algorithms
    • Without even having to change existing (and future) hash functions
  • Achieved by simple randomization of msg to be signed
    • Preserves existing “machinery” (algorithms, hardware, security libraries, object code, applications)
    • Requires simple changes in signature-related standards for msg pre-processing (though changes to standards never too simple)
rmx preserving hash then sign
RMX: Preserving Hash-then-Sign

M =(m1,…,mL)

M =(m1,…,mL)

r

RMX

(r, m1r,,…,mLr(

HASH

HASH

SIGN

SIGN

randomized hashing and signatures
Randomized Hashing and Signatures
  • From SIGN(H(m)) to SIGN(H(RMX(r,M))
  • Frees signatures from its reliance on collision resistance
  • … and with a proof of security:
    • We formally prove that much weaker requirements from hash functions suffice (e.g., current attacks on SHA-1 do not apply)

 A safety net for digital signatures:remain secure well after collision-resistance is gone! (also: on-line vs. off-line)

  • Note: collision resistance may be needed for other applications
signatures w o crhf ny 89

same r (because r is explicitly signed)

Signatures w/o CRHF [NY’89]
  • Abstract randomized hashing ( H(r,M) )
    • Signer chooses random r with each M, signs SIGN( r || H(r,M) )
    • Attack scenario (collision game):
      • Attacker chooses M, M’
      • Signer chooses random r,
      • Attacker needs to find M'M, s.t. H(r,M) = H(r,M')
  • Called TCR Hashing: target collision resistance
    • a.k.a universal one-way hash functions (UOWHF)
    • Naor-Yung’89, Rompel’90, BellareRogaway’97, Shoup’00, Mironov’01, …

X

Requires a per signature collision (on-line attack)

tcr target collision resistant hashing
TCR (Target Collision Resistant) Hashing
  • Still a collision game but a much harder one (for the attacker)
  • Requires a per signature collision
    • Unpredictable r per signature
    • On-line vs Off-line attack!
    • NO generic birthday attack (280 vs. 2160)
    • Probability of success (say 2-50) is per-signature
building tcr hashing
Building TCR Hashing
  • [NY,R] From OWFs, provable but not practical
  • [BR,Shoup] Based on regular hash functions (MD5, SHA1)

 Under weaker-than-CR assumptions!

 Require changes to the hash internals (e.g.,re-keying the IV between Merkle-Damgard iterations),

 Non-constant r: more random bits, longer signatures

 Signing r  must change existing signature schemes to include r under sig (e.g., DSS can’t even accommodate r “under sig”)

  • Our work: from    to   
our approach
Our Approach
  • Build TCR functions out of standard M-D functions
  • Do not change hash or hash internals, nor signature alg’s
  • Preserve existing integrated hash-then-sign modules
  • Proof under much weaker than CR assumption (SPR)
  • Only change: randomize msg before inputting to hash
    • From SIGN( Hash( M ) ) to SIGN( Hash( randomize(r,M) ) )
    • Short randomness (constant) sent with signature
    • BONUS: r is not signed !!

“Second Preimage Resistance”

How? “enhanced TCR”

etcr enhanced tcr
TCR Collision Game:

attacker chooses M,

random r is chosen,

attacker wins if it finds:

M'M, s.t. H(r,M) = H(r,M')

(same r!)

eTCR Collision Game:

attacker chooses M,

random r is chosen,

attacker wins if it finds:

M'M & r’s.t. H(r,M) = H(r’,M')

(r’≠r allowed - chosen by attacker!)

eTCR: enhanced TCR

TCR « eTCR « CR

etcr theorem
eTCR Theorem
  • If H(r,M) is eTCR and SIGN secure on short inputs then SIGN( H(r,M) ) is a secure signature scheme
    • No need to sign r (crucial for easy adoption; can use with DSA)
  • Can we build eTCR from weak assumptions?
  • Yes. We can build eTCR from SPR-like assumptions
rmx message randomization scheme
RMX: Message Randomization Scheme
  • Goal : from SIGN( Hash(M) ) to SIGN( Hash( (r,M) )) .
  • RMX(r,M) : M=(m1,m2,…,mL), r (r, m1r,m2r,…,mLr)

H(r,M) = Hash( RMX(r,M) )

= Hash( r, m1r, m2r,…, mLr )

  • Signature: r fresh per signature, no signing of r

=

RMX

randomize

mi and r of block length (eg 512)

rmx in signatures

Only H(r,M) is signed (eTCR: r sent but not signed)

r chosen by signer at random w/each sig

RMX in Signatures
  • SIGN( Hash(RMX(r,M))): .

M=(m1,m2,…,mL), r H(r, m1r,m2r,…,mLr)  SIGN, r

H(r,m)

rmx preserving hash then sign21
RMX: Preserving Hash-then-Sign

M =(m1,…,mL)

M =(m1,…,mL)

r

RMX

(r, m1r,,…,mLr(

HASH

HASH

TCR

X

SIGN

SIGN

slide22

m1

m2

mL-1

mL

Merkle- Damgard . Hash H

h

h

h

h

Hash(M)

IV

● ● ●

m1

mL-1

mL

r

r

r

r

The RMX Scheme

(one-pass

blockwise

processing)

~

h

h

h

h

H(r,M)

IV

● ● ●

properties of the rmx scheme
Properties of the RMX Scheme
  • Any Merkle-Damgard hash
  • Short r (recommended between 128 bit to full block)
  • Black-box treatment of hash, sign, and hash-then-sign
  • Only change: simple message randomization
    • Supports block-by-block randomization (one-pass!)
    • Easy s/w or h/w support
  • Only needs to standardize RMX as a mode of op for hash functions (transport of r at the application level, like IV in CBC)
    • Can also save separate sending of r: re-use of signature randomness
effect on signature standards
Effect on Signature Standards
  • Unchanged
    • Hash functions (preserve implementations and applications)
    • Signature algorithms (eg., RSA, DSA)
    • Integrated Hash-then-Sign module
  • Changes to signing process
    • Choice of random r by signer
    • Compute RMX(r,M) prior to hash-then-sign:
      • M=(m1,m2,…,mL)  (r, m1r,m2 r,…,mL r) H  SIGN
  • Transport r:
    • Application layer: extra bandwidth but changes are minimal (comparable to supporting new hash function; e.g., transporting r as an argument for AlgId)
    • Bandwidth constrained: re-use DSS/PSS randomness (or r under RSA-1)
adoption by nist
Adoption by NIST
  • RMX: SP 800-106 (2nd draft)
  • eTCR: requirement for new hash function (competition)
security of rmx scheme
Security of RMX Scheme
  • Let H be a M-D function built on a compression func h
    • h(c,m): fixed-length function (chain variable c and input block m)
  • h is SPR (second-preimage resistant) if given random c,m it is infeasible to find c’,m’ such that h(c,m)=h(c’,m’)
  • RMX Security is related to the SPR property of h
  • Thm: If h is “e-SPR” then H(RMX(r,M)) is eTCR
  • What is e-SPR?
e spr an spr approximation
e-SPR: an SPR approximation
  • SPR: given random c,m find c’,m’ such that h(c,m)=h(c’,m’)
  • e-SPR:
    • Receive random m, set c=H*(Δ,m) (H* is h-dependent; Δ chosen by attacker before seeing m)
    • Attacker needs to find colliding c’,m’ s.t. h(c,m)=h(c’,m’)
  • An SPR approximation: m is random, c determined via random m, H and Δ.
      • Specifically: Δ=(Δ1,…, Δl), c=H*(Δ,m) H(Δ1m, Δ2 m,…, Δl m)
  • e-SPR and SPR close but formally incomparable (Mix of randomness and structure sometimes harder than pure randomness )
e spr etcr
e-SPR  eTCR
  • Thm: If h is e-SPR then H(RMX(r,M)) is eTCR
  • Corollary: SIG(H(RMX(r,M))) is a secure signature given that SIG is secure on short inputs and h is e-SPR
e spr sufficient for etcr but not necessary
e-SPR: sufficient for eTCR but not necessary
  • Example: MD5 c.f. is not e-SPR and SPR (Lisa Yin)
  • Yet, this attack does not break H(RMX)
    • Uses essentially that attacker can choose any c’
    • In the real eTCR game attacker cannot choose c’ but rather needs to hit c’ via an H output (i.e. find msg P such that c’=H(P))
    • Similar to the difference between pseudo-coll and full collisions
  • e-SPR: significant design criterion, and early alarm if broken
summary
Summary
  • Randomized hashing as mode of operation for hash functns
  • Simple randomization of message to be signed
    • Preserves existing “machinery” (hash-then-sign, algorithms, hardware, security libraries, object code, applications)
    • Change to standardized sig schemes limited to msg pre-processing
  • Substantial security increase for digital signatures
    • A fundamental shift in attack scenario:Off-line vs. On-line
      • In particular: no inherent birthday, shorter outputs (truncation)
    • A much harder cryptanalytical task
  • Security analysis: from eSPR to eTCR
safety net
Safety Net
  • RMX complementssearch for better hash functions
    • Prudent design: search for the strongest hash functions; build schemes that rely on the hashing strength as little as possible
  • Likely extension of useful life of hash functions, may prevent or mitigate catastrophic failure, more planning time upon weaknesses
  • A SAFETY NET for digital signatures (note: CR  eTCR)
    • Much like HMAC for MAC functions
moral beyond this work
Moral Beyond this Work
  • It’s not just about designing a good hash function
  • But also about HOW TO USE IT
    • And many times, the “how to use” is more critical than the basic design (since using it right can afford a weaker function)
  • Analogy: CBC vs ECB
analogy from block ciphers cbc vs ecb
Analogy from block ciphers: CBC vs ECB
  • ECB encrypts each input block independently
  • CBC randomizes encryption to hide repeated blocks
  • But does CBC adds real security?
    • “Come on, how bad it is to leak repeated blocks?”
    • Certainly not too bad for “random” plaintext
  • Well..
ecb vs cbc
ECB vs CBC

Encrypted w/ECB!

Linux Penguin Encrypted w/CBC

  • Isn’t it about how to use it?!
    • Yes. That’s why we need modes of operation
    • Note that the strongest block cipher with ECB is weaker than a weak block cipher (say 40-bit DES) with CBC

Courtesy of wikipedia “modes of operation”

thanks
THANKS

http://www.ee.technion.ac.il/~hugo/rhash/

note can the signer cheat
Note: Can the Signer Cheat?
  • If H is CR then signer cannot find collisions
  • If H(RMX) is eTCR but not CR then the signer (and only the signer) may be able to find collisions
    • That is, find r,r’,M,M’ such that H(RMX(r,M))=H(RMX(r’,M’))
  • But this is no contradiction to non-repudiation
    • Signer is liavle for any message with his/her signature (even if he/she shows two msgs with the same signature!)
    • NO contradiction to standard unforgeability definitions [GMR]
  • Note: in our scheme, as long as H is CRHF then even the signer cannot find collisions (i.e. RMX never weakens, can only help)
slide37

h

h

h

h

H(M)

IV

● ● ●

m1

m2

mL-1

mL

r

m1

m2

mL-1

mL

r

r

r

 u

Our TCR . Scheme

h

h

h

h

Hr(M)

IV

● ● ●

sL-1

s1

sL

s2

Hr,s1,…,sL(M)

Merkle- Damgard . Hash H

Shoup

change hash + longer salt + sign r (log L si masks)