Loading in 2 Seconds...

Randomized Hashing: Secure Digital Signatures without Collision Resistance

Loading in 2 Seconds...

- By
**paul** - Follow User

- 449 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about 'Randomized Hashing: Secure Digital Signatures without Collision Resistance' - paul

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

Download Now

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

Randomized Hashing:Secure Digital Signatureswithout Collision Resistancehttp://www.ee.technion.ac.il/~hugo/rhash/

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

- 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

- 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

- 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

- 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?

- 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

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

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

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

- 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

- [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

- 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”

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 TCRTCR « eTCR « CR

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

- Goal : from SIGN( Hash(M) ) to SIGN( Hash( (r,M) )) .
- RMX(r,M) : M=(m1,m2,…,mL), r (r, m1r,m2r,…,mLr)

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

= Hash( r, m1r, m2r,…, mLr )

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

=

RMX

randomize

mi and r of block length (eg 512)

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, m1r,m2r,…,mLr) SIGN, r

H(r,m)

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

- 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

- 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, m1r,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

- RMX: SP 800-106 (2nd draft)
- eTCR: requirement for new hash function (competition)

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

- 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(Δ1m, Δ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

- 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

- 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

- 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

- 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

- 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

- 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

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

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

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)

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)

Download Presentation

Connecting to Server..