mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-11 05:33:47 +01:00
168 lines
7.3 KiB
Plaintext
168 lines
7.3 KiB
Plaintext
Filename: xxx-what-uses-sha1.txt
|
|
Title: Where does Tor use SHA-1 today?
|
|
Version: $Revision$
|
|
Last-Modified: 1-May-2009
|
|
Authors: Nick Mathewson, Marian
|
|
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. RIPEMD-160 is
|
|
also based on flawed past hashes. Some people think other hash
|
|
functions (e.g. Whirlpool and Tiger) are not as bad; most of these
|
|
have not seen enough analysis to be used yet.
|
|
|
|
Here is a 2006 paper about hash algorithms.
|
|
http://www.sane.nl/sane2006/program/final-papers/R10.pdf
|
|
|
|
(Todo: Ask smart crypto people.)
|
|
|
|
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.
|
|
* In dir-spec.txt, section 1.3, it states,
|
|
"SIGNATURE" Object contains a signature (using the signing key)
|
|
of the PKCS1-padded digest of the entire document, taken from
|
|
the beginning of the Initial item, through the newline after
|
|
the Signature Item's keyword and its arguments."
|
|
So our attacker, Malcom, could generate a collision for the hash
|
|
that is signed. Thus, a second pre-image attack is possible.
|
|
Vulnerable to regular collision attack only if key is stolen.
|
|
If the key is stolen, Malcom could distribute two different
|
|
copies of the document which have the same hash. Maybe useful
|
|
for a partitioning attack?
|
|
B. Router descriptors identify their corresponding extra-info documents
|
|
by their SHA-1 digest.
|
|
* A third party might use a second pre-image attack to generate a
|
|
false extra-info document that has the same hash. The router
|
|
itself might use a regular collision attack to generate multiple
|
|
extra-info documents with the same hash, which might be useful
|
|
for a partitioning attack.
|
|
C. Fingerprints in router descriptors are taken using SHA-1.
|
|
* The fingerprint must match the public key. Not sure what would
|
|
happen if two routers had different public keys but the same
|
|
fingerprint. There could perhaps be unpredictable behaviour.
|
|
D. In router descriptors, routers in the same "Family" may be listed
|
|
by server nicknames or hexdigests.
|
|
* Does not seem critical.
|
|
E. Fingerprints in authority certs are taken using SHA-1.
|
|
F. Fingerprints in dir-source lines of votes and consensuses are taken
|
|
using SHA-1.
|
|
G. Networkstatuses refer to routers identity keys and descriptors by their
|
|
SHA-1 digests.
|
|
H. 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.
|
|
I. The following items are downloaded by the SHA-1 of their contents:
|
|
XXXX list them
|
|
J. 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
|
|
|