From: Nick Mathewson <nickm@torproject.org>
Date: Wed, 23 Sep 2009 15:45:54 +0000 (-0400)
Subject: Revise proposal 162: SHA256(x), not SHA256(SHA256(x))
X-Git-Tag: tor-0.2.2.6-alpha~36^2~9
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=0bce0161dded650ac6fa665a7b861d6faac9e91c;p=thirdparty%2Ftor.git

Revise proposal 162: SHA256(x), not SHA256(SHA256(x))

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.
---

diff --git a/doc/spec/proposals/162-consensus-flavors.txt b/doc/spec/proposals/162-consensus-flavors.txt
index 56a0b0e1ab..e257205bbe 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: