[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