Loading in 2 Seconds...

Randomized Hashing: Secure Digital Signatures without Collision Resistance

Loading in 2 Seconds...

473 Views

Download Presentation
## Randomized Hashing: Secure Digital Signatures without Collision Resistance

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -

**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)**• 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**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**• 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**M =(m1,…,mL) M =(m1,…,mL) r RMX (r, m1r,,…,mLr( HASH HASH SIGN SIGN**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 TCR TCR « 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)**RMX: Preserving Hash-then-Sign**M =(m1,…,mL) M =(m1,…,mL) r RMX (r, m1r,,…,mLr( HASH HASH TCR X SIGN SIGN**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**• 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 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)