[or-cvs] r17831: {} New proposal "idea" listing all the places I could think of (tor/trunk/doc/spec/proposals/ideas)

[nickm at seul.org]

Author: nickm
Date: 2008-12-30 12:15:27 -0500 (Tue, 30 Dec 2008)
New Revision: 17831

Added:
   tor/trunk/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt
Log:
New proposal "idea" listing all the places I could think of that we use SHA-1.

Added: tor/trunk/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt
===================================================================
--- tor/trunk/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt	                        (rev 0)
+++ tor/trunk/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt	2008-12-30 17:15:27 UTC (rev 17831)
@@ -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
+
+