Strengthening Digital Signatures via Randomized Hashing Shai Halevi

Strengthening Digital Signatures via Randomized Hashing Shai Halevi and Hugo Krawczyk IBM Research 1

Coping with Collisions n Post-Wang Trauma (collision attacks): ¨ A healthy reminder of our “shaky foundations” n Applications threatened by collisions: mainly signatures n What to do: avoid patches, build stronger hash funct’s ¨ But do we know how? n Our approach: “Hope for the Best, Plan for the Worst” n BUILD APPLICATIONS ON AS WEAK AS POSSIBLE ASSUMPTIONS ON THE UNDERLYING HASH FUNCTIONS 2

Our Contribution We randomize the signature processing such that: n n n Signatures remain secure even if off-line collision attacks against hash are successful Attacker needs to be able to mount a variant of the much harder “second-preimage attack” (on compr. f. ) Off-line attacks useless: Per-signature attack (on line!) ¨ n Attack can start only when per-signature randomness revealed HASH FUNCTION AND SIGNING ALG UNCHANGED!! 3

Too Good To Be True? n Simple message randomization scheme n Provable reduction to “second preimage resistance” n NIST: SP 800 -106 ! ¨ Internet Draft is coming (see our website) 4

RMX: Message Randomization Scheme n From SIGN( Hash( M ) ) to SIGN( Hash( RMX(r, M) )) n RMX(r, M) : M=(m 1, m 2, …, m. L), r (r, m 1 r, m 2 r, …, m. L r) n In signatures: M=(m 1, m 2, …, m. L), mi and r of block r length (eg 512) H(r, m 1 r, m 2 r, …, m. L r) r chosen by signer at random w/each sig . . SIGN, r Input to signing algorithm (r transmitted with sig) 5

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

m 1 Merkle. Damgard. IV Hash H m 2 h r (one-pass blockwise processing) IV h h m. L h ● ● ● m 1 r The RMX Scheme m. L-1 r h ● ● ● h Hash(M) m. L r h h ~ H(r, M) 7

Practical ¨ 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 n (e. g. , certificate issuing vs verifying) 128 bits of randomness (up to a block, 512) Transporting r: application-dependent (like IV in CBC); E. g. , X. 509: r as a parameter under Algorithm. Identifier Implementations: certificate signing (openssl, NSS/Firefox[B&S]) XML: next (note: RMX can be applied to multilevel signing) Documented by NIST: SP 800 -106 (Internet Draft coming) 8

Secure n Substantial security increase for digital signatures ¨ A fundamental shift in attack scenario: Off-line vs. On-line n ¨ n In particular: no inherent birthday, shorter outputs (truncation) A much harder cryptanalytical task (~SPR of compression function) Notes ¨ Randomization never weakens: A SAFETY NET ¨ Likely extension of useful life of hash functions, may prevent or mitigate catastrophic failure, more planning time upon weaknesses ¨ Much like HMAC for MAC functions (btw, is HMAC good as RMX? ) 9

http: //www. ee. technion. ac. il/~hugo/rhash/ n Paper (Crypto’ 06) n Implementation experience n Internet Draft 10

Randomized Hashing Implementation n Java JCE Provider for java. security. Signature ¨ n No set. Param for java. security. Message. Digest Apache XML Security library extensions ¨ Signature n ¨ Salt parameter passed as child of Signature. Method Transform n Salt parameter passed as child of Transform 13

XML Signature Example Test Data JYo. VX 6 Pqdc/z/1 k… d. S 1 m. E 6 FG 5 Iikiz. QEJKafg 6 k. VChc= x. E/1 o. Rdq+7 z 3 KDAj 9 qh/GY/6 SWQ= f. DDeknd. St. Uhk 8 wvf. PJNe 8 pj 0 T 2 ZHPx 4 ZJ 06 s 4 k. Oh. Sv. Yuc. QCy. NKUQr. Ad. SQds… heaz. CYHw. ZC 5 ki. GI 6 e. O 3 ZSLjypfdge. Xu 3 u. XJo. N/VYl. Wr. P 51 No. J 5 w. R 9 NOnz. Ax. Chuf. T 5 qi 0… AQAB 14

Adding Support for New Signature. Method or Digest. Method n Adding new JCE Signature Provider ¨ Add one class derived from base; specify: n n n Underlying Signature Provider (e. g. DSA) Associated Message. Digest block size (e. g. SHA 1 = 20 bytes, MD 5 = 16 bytes, etc. ) Adding new Transform ¨ Add one class derived from base; specify: n Underlying Message. Digest Provider 15