From 7e411f4b302e01f36626ca3476bdbac225383410 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Sat, 2 May 2009 11:52:38 -0500 Subject: [PATCH] Initial division of SHA1 uses by collision/preimage needs. More thought is needed on each collision opportunity to figure out how exploitable it is. --- .../proposals/ideas/xxx-what-uses-sha1.txt | 53 ++++++++++++++++++- 1 file changed, 51 insertions(+), 2 deletions(-) diff --git a/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt b/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt index 3112aee1f0..b0be567a4a 100644 --- a/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt +++ b/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt @@ -60,35 +60,81 @@ Why now? one look silly. +Triage + + How severe are these problems? Let's divide them into these + categories: + PREIMAGE -- A SHA-1 usage that only depends on preimage + resistance + COLLISION -- A SHA-1 usage that depends on collision + resistance, but the only party who could mount a + collision-based attack is already in a trusted role + (like a distribution signer or a directory authority). + COLLISION -- A SHA-1 usage that depends on collision resistance + and doesn't need the attacker to have any special keys. + + There is no need to put much effort into fixing PREIMAGE usages in + the near-term: even _MD5_ is still preimage resistant. To fix + COLLISION usages is not too important either, since + anyone who has the key to sign the code can mount far worse + attacks. It would be good to fix COLLISION usages, + since we try to resist. The COLLISION usages are the most + important to fix. + + Additionally, we need to consider the impact of a successful attack + in each of these cases. SHA-1 collisions are still expensive even + if recent results are verified, and anybody with the resources to + compute one also has the resources to mount a decent Sybil attack. + + Let be pessimistic, and not assume that producing collisions of a given + format is actually any harder than producing collisions at all. + What Tor uses hashes for today: 1. Infrastructure. A. Our X.509 certificates are signed with SHA-1. + COLLSION B. TLS uses SHA-1 (and MD5) internally to generate keys. + PREIMAGE? C. Some of the TLS ciphersuites we allow use SHA-1. + PREIMAGE? D. When we sign our code with GPG, it might be using SHA-1. + COLLISION E. Our GPG keys might be authenticated with SHA-1. + COLLISION F. OpenSSL's random number generator uses SHA-1, I believe. + PREIMAGE 2. The Tor protocol A. Everything we sign, we sign using SHA-1-based OAEP-MGF1. + PREIMAGE? B. Our CREATE cell format uses SHA-1 for: OAEP padding. + PREIMAGE? C. Our EXTEND cells use SHA-1 to hash the identity key of the target server. + COLLISION D. Our CREATED cells use SHA-1 to hash the derived key data. + ?? E. The data we use in CREATE_FAST cells to generate a key is the length of a SHA-1. + NONE F. The data we send back in a CREATED/CREATED_FAST cell is the length of a SHA-1. - G. We use SHA-1 to derive our circuit keys from the negotiated g^xy value. + NONE + G. We use SHA-1 to derive our circuit keys from the negotiated g^xy + value. + NONE H. We use SHA-1 to derive the digest field of each RELAY cell, but that's used more as a checksum than as a strong digest. + NONE 3. Directory services + [All are COLLISION or COLLISION ] + A. All signatures are generated on the SHA-1 of their corresponding documents, using PKCS1 padding. * In dir-spec.txt, section 1.3, it states, @@ -159,9 +205,12 @@ What Tor uses hashes for today: A. We log information about servers based on SHA-1 hashes of their identity keys. + COLLISION B. The controller identifies servers based on SHA-1 hashes of their identity keys. + COLLISION C. Nearly all of our configuration options that list servers allow SHA-1 hashes of their identity keys. + COLLISION E. The deprecated .exit notation uses SHA-1 hashes of identity keys - + COLLISION