[or-cvs] [tor/master] delete trailing whitespace in xxx-what-uses-sha1.txt
Nick Mathewson
nickm at seul.org
Sat May 2 16:53:35 UTC 2009
Author: Nick Mathewson <nickm at torproject.org>
Date: Sat, 2 May 2009 11:49:45 -0500
Subject: delete trailing whitespace in xxx-what-uses-sha1.txt
Commit: 08e4a077207a5def143cf62ad34ce6c76e6f8300
---
doc/spec/proposals/ideas/xxx-what-uses-sha1.txt | 36 +++++++++++-----------
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt b/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt
index 1e62112..3112aee 100644
--- a/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt
+++ b/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt
@@ -15,10 +15,10 @@ Introduction:
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.
+ 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
@@ -91,29 +91,29 @@ What Tor uses hashes for today:
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
+ * 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.
+ 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
+ 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
+ * 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
+ * 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
+ 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.
--
1.5.6.5
More information about the tor-commits
mailing list