summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2008-12-30 17:15:27 +0000
committerNick Mathewson <nickm@torproject.org>2008-12-30 17:15:27 +0000
commit1ef472b2bd05cf210f0edc12a7cf963082e70fa3 (patch)
tree422af4eae2742d421c24d26902685dcbe72f2b3a
parent9a04358d878326d7f4275d32105efd9ba985c257 (diff)
downloadtor-1ef472b2bd05cf210f0edc12a7cf963082e70fa3.tar.gz
tor-1ef472b2bd05cf210f0edc12a7cf963082e70fa3.zip
New proposal "idea" listing all the places I could think of that we use SHA-1.
svn:r17831
-rw-r--r--doc/spec/proposals/ideas/xxx-what-uses-sha1.txt120
1 files changed, 120 insertions, 0 deletions
diff --git a/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt b/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt
new file mode 100644
index 0000000000..8dfdb99c94
--- /dev/null
+++ b/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt
@@ -0,0 +1,120 @@
+Filename: xxx-what-uses-sha1.txt
+Title: Where does Tor use SHA-1 today?
+Version: $Revision$
+Last-Modified: $Date$
+Author: Nick Mathewson
+Created: 30-Dec-2008
+Status: Meta
+
+
+Introduction:
+
+ Tor uses SHA-1 as a message digest. SHA-1 is showing its age:
+ theoretical attacks for finding collisions against it get better
+ every year or two, and it will likely be broken in practice before
+ too long.
+
+ According to smart crypto people, the SHA-2 functions (SHA-256, etc)
+ share too much of SHA-1's structure to be very good. Some people
+ like other hash functions; most of these have not seen enough
+ analysis to be widely regarded as an extra-good idea.
+
+ By 2012, the NIST SHA-3 competition will be done, and with luck we'll
+ have something good to switch too. But it's probably a bad idea to
+ wait until 2012 to figure out _how_ to migrate to a new hash
+ function, for two reasons:
+ 1) It's not inconceivable we'll want to migrate in a hurry
+ some time before then.
+ 2) It's likely that migrating to a new hash function will
+ require protocol changes, and it's easiest to make protocol
+ changes backward compatible if we lay the groundwork in
+ advance. It would suck to have to break compatibility with
+ a big hard-to-test "flag day" protocol change.
+
+ This document attempts to list everything Tor uses SHA-1 for today.
+ This is the first step in getting all the design work done to switch
+ to something else.
+
+ This document SHOULD NOT be a clearinghouse of what to do about our
+ use of SHA-1. That's better left for other individual proposals.
+
+
+Why now?
+
+ The recent publication of "MD5 considered harmful today: Creating a
+ rogue CA certificate" by Alexander Sotirov, Marc Stevens, Jacob
+ Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de
+ Weger has reminded me that:
+
+ * You can't rely on theoretical attacks to stay theoretical.
+ * It's quite unpleasant when theoretical attacks become practical
+ and public on days you were planning to leave for vacation.
+ * Broken hash functions (which SHA-1 is not quite yet AFAIU)
+ should be dropped like hot potatoes. Failure to do so can make
+ one look silly.
+
+
+
+What Tor uses hashes for today:
+
+1. Infrastructure.
+
+ A. Our X.509 certificates are signed with SHA-1.
+ B. TLS uses SHA-1 (and MD5) internally to generate keys.
+ C. Some of the TLS ciphersuites we allow use SHA-1.
+ D. When we sign our code with GPG, it might be using SHA-1.
+ E. Our GPG keys might be authenticated with SHA-1.
+
+2. The Tor protocol
+
+ A. Everything we sign, we sign using SHA-1-based OAEP-MGF1.
+ B. Our CREATE cell format uses SHA-1 for: OAEP padding.
+ C. Our EXTEND cells use SHA-1 to hash the identity key of the
+ target server.
+ 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.
+ 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.
+ 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.
+
+3. Directory services
+
+ A. All signatures are generated on the SHA-1 of their corresponding
+ documents, using PKCS1 padding.
+ B. Router descriptors identify their corresponding extra-info documents
+ by their SHA-1 digest.
+ C. Fingerprints in router descriptors are taken using SHA-1.
+ D. Fingerprints in authority certs are taken using SHA-1.
+ E. Fingerprints in dir-source lines of votes and consensuses are taken
+ using SHA-1.
+ F. Networkstatuses refer to routers identity keys and descriptors by their
+ SHA-1 digests.
+ G. Directory-signature lines identify which key is doing the signing by
+ the SHA-1 digests of the authority's signing key and its identity key.
+ H. The following items are downloaded by the SHA-1 of their contents:
+ XXXX list them
+ I. The following items are downloaded by the SHA-1 of an identity key:
+ XXXX list them too.
+
+4. The rendezvous protocol
+
+ XXXX write me
+
+5. The bridge protocol
+
+ XXXX write me
+
+6. The Tor user interface
+
+ A. We log information about servers based on SHA-1 hashes of their
+ identity keys.
+ B. The controller identifies servers based on SHA-1 hashes of their
+ identity keys.
+ C. Nearly all of our configuration options that list servers allow SHA-1
+ hashes of their identity keys.
+ E. The deprecated .exit notation uses SHA-1 hashes of identity keys
+
+