[or-cvs] [tor/master] Revise proposal 162: SHA256(x), not SHA256(SHA256(x))
Nick Mathewson
nickm at seul.org
Mon Oct 19 04:48:28 UTC 2009
Author: Nick Mathewson <nickm at torproject.org>
Date: Wed, 23 Sep 2009 11:45:54 -0400
Subject: Revise proposal 162: SHA256(x), not SHA256(SHA256(x))
Commit: 0bce0161dded650ac6fa665a7b861d6faac9e91c
The point of doing SHA256 twice is, generally, is to prevent message
extension attacks where an attacker who knows H(A) can calculate
H(A|B). But for attaching a signature to a document, the attacker
already _knows_ A, so trying to keep them from calculating H(A|B) is
pointless.
---
doc/spec/proposals/162-consensus-flavors.txt | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/doc/spec/proposals/162-consensus-flavors.txt b/doc/spec/proposals/162-consensus-flavors.txt
index 56a0b0e..e257205 100644
--- a/doc/spec/proposals/162-consensus-flavors.txt
+++ b/doc/spec/proposals/162-consensus-flavors.txt
@@ -148,11 +148,10 @@ Spec modifications:
4.1. The "sha256" signature format.
The 'SHA256' signature format for directory objects is defined as
- the RSA signature of the OAEP+-padded SHA256 digest of the SHA256
- digest of the item to be signed. When checking signatures,
- the signature MUST be treated as valid if the signature material
- begins with SHA256(SHA256(document)); this allows us to add other
- data later.
+ the RSA signature of the OAEP+-padded SHA256 digest of the item to
+ be signed. When checking signatures, the signature MUST be treated
+ as valid if the signature material begins with SHA256(document);
+ this allows us to add other data later.
Considerations:
--
1.5.6.5
More information about the tor-commits
mailing list