mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-28 06:13:31 +01:00
141 lines
5.7 KiB
Plaintext
141 lines
5.7 KiB
Plaintext
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.
|
|
F. OpenSSL's random number generator uses SHA-1, I believe.
|
|
|
|
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
|
|
|
|
A. Hidden servers use SHA-1 to establish introduction points on relays,
|
|
and relays use SHA-1 to check incoming introduction point
|
|
establishment requests.
|
|
B. Hidden servers use SHA-1 in multiple places when generating hidden
|
|
service descriptors.
|
|
C. Hidden servers performing basic-type client authorization for their
|
|
services use SHA-1 when encrypting introduction points contained in
|
|
hidden service descriptors.
|
|
D. Hidden service directories use SHA-1 to check whether a given hidden
|
|
service descriptor may be published under a given descriptor
|
|
identifier or not.
|
|
E. Hidden servers use SHA-1 to derive .onion addresses of their
|
|
services.
|
|
F. Clients use SHA-1 to generate the current hidden service descriptor
|
|
identifiers for a given .onion address.
|
|
G. Hidden servers use SHA-1 to remember digests of the first parts of
|
|
Diffie-Hellman handshakes contained in introduction requests in order
|
|
to detect replays.
|
|
H. Hidden servers use SHA-1 during the Diffie-Hellman key exchange with
|
|
a connecting client.
|
|
|
|
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
|
|
|
|
|