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

2. 2 The Problem Broken/Injured Hash Functions (MD5, SHA-1)  Applications affected in different ways and to different degrees of severity One main application: Digital signatures  Rely on collision resistance of hash function: hash-then-sign (where one signs a hash value not the data itself)  Critical for non-repudiation and certificates (many other uses where adversary can control part of the signed msg) It applies also to ephemeral authentication scenarios (e.g. IKE) but in a less critical way

3. 3 Saving Our Signatures Short-term patches: per-application (e.g., randomize s/n), algorithmic (e.g. hash(M||M) ), pragmatic (e.g., “ don ’ t care ” ) We are interested in long-term structural solutions  Search for the best next-generation hash function (NIST)  At the same time, develop smarter ways to use hash functions in digital signatures  “ smarter ” : rely as little as possible on collision resistance Designing collision resistance is HARD and our knowledge limited An insurance policy against collisions (present and future)  Much like what HMAC did for MAC and PRF functions

4. 4 Our Proposal: Randomized Hashing Simple * randomization of a message before hash & sign * simple but careful: not all randomizations work! Dispenses of collision resistance (for digital signatures)  Signatures remain secure even if off-line collision attacks against the hash function are successful  Raises the bar for the attacker: “ second preimage ” attacks much harder to mount (formal proof) We call our randomization technique RMX … (see next)

5. 5 HASH SIGN r HASH SIGN RMX M =(m 1, …,m L ) (r, m 1  r,, …,m L  r( M =(m 1, …,m L ) RMX: Preserving Hash-then-Sign signature( signature, r )

6. 6 RMX What ’ s good?  Preserves the hash-then-sign paradigm  Preserves signature algorithms (RSA, DSA)  Applicable to existing and future hash functions  Preserves existing “ machinery ” (algorithms, hardware, security libraries, object code, applications) What ’ s the price?  Generation and transmission of a random string by the signer What ’ s the prize?  Signatures without collision resistance

7. 7 RMX in Signatures: SIGN( Hash( RMX(r,M) )) Message M=(m 1, …,m L ) set (with partial or total control by attacker) Signer: chooses unpredictable r, Computes h = RMX(r,M) = H(r, m 1  r,m 2  r, …,m L  r) Produces signature σ = Sign(h) Transmits σ and r Verifier: receives M, σ, and r, Computes h = RMX(r,M) = H(r, m 1  r,m 2  r, …,m L  r) Verifies signature σ

8. 8 Note on randomness Only signer chooses randomness (verifier receives it)  For example: CA chooses r but certificate verifiers receive r with certificate: do not need a source of randomness r is the length of a block (or any established size) – does not need to be fully random just unpredictable *  For example: can set r = r ’ ||r ’ ||r ’ ||r ’ where r ’ is of length 128 thus only need to transmit r ’ * Unpredictable means unguessable by the attacker until the msg is fixed Randomness from signature (e.g., DSA) can be reused  As long as it remains unknown until the signature is issued

9. 9 RMX: simple front-end to existing hash-then-sign modules  No change to hash functions or signature algorithms  Compatible with block-wise processing of M-D functions  Random generation by signer only (short randomness) Transporting r: application level (like IV in CBC) but some standardization desirable  E.g., X.509: r as a parameter under AlgorithmIdentifier  SHOULD be considered as part of “ hash agility ” support For example: Accommodate specification of SHA-256-RMX Implementation

10. 10 Security Substantial security increase for digital signatures  From collision resistance to second-preimage resistance  Much harder cryptanalytical task  Security proof for M-D hash functions A fundamental shift in attack scenario: Off-line vs. On-line  No off-line birthday attacks, no use for off-line collisions 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  Much like HMAC for MAC functions

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

12. 12 Towards Standardization Everyone should support “ hash agility ” and this should include support for randomization (note: SHA3 requirement)  Necessary with any randomization technique  Provision for randomness advisable even in WG ’ s (e.g., TLS) where randomized hashing is less crucial Consider support for randomized hashing in specific Working Groups (e.g., PKIX, S/MIME, DKIM, PGP, … ) Note: NIST ’ s SP 800-106 draft documents RMX  Also: randomization as a requirement for SHA3 competition

13. 13 More information http://www.ee.technion.ac.il/~hugo/rhash/ http://www.ee.technion.ac.il/~hugo/rhash/ Detailed paper (including analysis and proofs) Implementation experience  Certificate signing and XML signatures  Openssl, NSS/Firefox [Boneh-Shao], XML (McIntosh) Expired Internet Draft (cfrg) ready to be resurrected  Welcome volunteers to define scheme at the “ format level ” (e.g. X.509 identifiers) Feedback, suggestions, comments, all welcome