Randomized Hashing: Secure Digital Signatures without Collision Resistance

1. Shai Halevi and Hugo Krawczyk IBM Research Randomized Hashing:Secure Digital Signatureswithout Collision Resistance http://www.ee.technion.ac.il/~hugo/rhash/

2. 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

3. 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’

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

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

6. 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

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

8. “Hope for the Best, Plan for the Worst”

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

10. RMX: Preserving Hash-then-Sign M =(m1,…,mL) M =(m1,…,mL) r RMX (r, m1r,,…,mLr( HASH HASH SIGN SIGN

11. 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

12. From MarketingtoTechnicalities… 15-18’

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

14. 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

15. 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   

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

17. 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

18. 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

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

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

21. RMX: Preserving Hash-then-Sign M =(m1,…,mL) M =(m1,…,mL) r RMX (r, m1r,,…,mLr( HASH HASH TCR X SIGN SIGN

22. 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 ● ● ●

23. 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

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

25. Adoption by NIST • RMX: SP 800-106 (2nd draft) • eTCR: requirement for new hash function (competition)

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

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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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..

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

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

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

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