mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-12-06 19:41:15 +01:00
New proposal "idea" listing all the places I could think of that we use SHA-1.
svn:r17831
This commit is contained in:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user