dir-spec.txt

@@ -285,11 +285,13 @@
      <signature item keyword> [arguments] NL SIGNATURE NL
 
    The "SIGNATURE" Object contains a signature (using the signing key) of
-   the PKCS1-padded digest of the entire document, taken from the
+   the PKCS#1 1.5 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.
 
-   Unless otherwise, the digest algorithm is SHA-1.
+   The signature does not include the algorithmIdentifier specified in PKCS #1.
+
+   Unless specified otherwise, the digest algorithm is SHA-1.
 
    All documents are invalid unless signed with the correct signing key.
 
@@ -2102,7 +2104,7 @@
 
         See shared-rand-current-value decription above.
 
-   The authority section of a consensus contains groups the following items,
+   The authority section of a consensus contains groups of the following items,
    in the order given, with one group for each authority that contributed to
    the consensus, with groups sorted by authority identity digest:
 
@@ -2144,7 +2146,8 @@
         "Nickname" is the OR's nickname.  "Identity" is a hash of its
         identity key, encoded in base64, with trailing equals sign(s)
         removed.  "Digest" is a hash of its most recent descriptor as
-        signed (that is, not including the signature), encoded in base64.
+        signed (that is, not including the signature) by the RSA identity
+        key (see section 1.3.), encoded in base64.
 
         "Publication" is the publication time of its most recent descriptor,
         in the form YYYY-MM-DD HH:MM:SS, in UTC.  Implementations MAY base
@@ -3398,7 +3401,7 @@
    prefer fallbacks to authorities, trying them earlier and more frequently.
    In all other cases, the client downloads from caches randomly chosen from
    among those believed to be V3 directory servers.  (This information comes
-   from the network-status documents; see 6 below.)
+   from the network-status documents.)
 
    After receiving any response client MUST discard any network-status
    documents that it did not request.
@@ -3484,8 +3487,8 @@
    After choosing mirrors, the client divides the descriptors among them
    randomly.
 
-   After receiving any response client MUST discard any descriptors that it
-   did not request.
+   After receiving any response the client MUST discard any descriptors that
+   it did not request.
 
    When a descriptor download fails, the client notes it, and does not
    consider the descriptor downloadable again until a certain amount of time
@@ -3584,18 +3587,7 @@
 
 5.4.4. Warning about a router's status.
 
-   If a router tries to publish its descriptor to a Naming authority
-   that has its nickname mapped to another key, the router SHOULD
-   warn the operator that it is either using the wrong key or is using
-   an already claimed nickname.
-
-   If a router has fetched a consensus document,, and the
-   authorities do not publish a binding for the router's nickname, the
-   router MAY remind the operator that the chosen nickname is not
-   bound to this key at the authorities, and suggest contacting the
-   authority operators.
-
-   ...
+   (This section is removed; authorities no longer assign the 'Named' flag.)
 
 6. Standards compliance
 
@@ -3847,11 +3839,8 @@ D. Inferring missing proto lines.
      Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3 HSRend=1-2 Link=1-4
      LinkAuth=1 Microdesc=1-2 Relay=1-2
 
-   For Desc, Tor versions before 0.2.7.stable should be taken to have Desc=1
-   and versions 0.2.7.stable or later should have Desc=1-2.
-
-   For Microdesc and Cons, Tor versions before 0.2.7.stable should be taken to
-   support version 1; 0.2.7.stable and later should have 1-2.
+   For Desc, Microdesc and Cons, Tor versions before 0.2.7.stable should be
+   taken to only support version 1.
 
 E. Limited ed diff format
 

rend-spec-v3.txt

@@ -2160,8 +2160,9 @@ A.2. Tor's key derivation scheme
   blinding factor like this:
 
            h = H(BLIND_STRING | A | s | B | N)
-           BLIND_STRING = "Derive temporary signing key"
+           BLIND_STRING = "Derive temporary signing key" | INT_1(0)
            N = "key-blind" | INT_8(period-number) | INT_8(period_length)
+           B = "(1511[...]2202, 4631[...]5960)"
 
   then clamp the blinding factor 'h' according to the ed25519 spec:
 
@@ -2171,8 +2172,15 @@ A.2. Tor's key derivation scheme
 
   and do the key derivation as follows:
 
-      private key for the period:   a' = h a
-      public key for the period:    A' = h A = (ha)B
+      private key for the period:
+
+           a' = h a mod l
+           RH' = SHA-512(RH_BLIND_STRING | RH)[:32]
+           RH_BLIND_STRING = "Derive temporary signing key hash input"
+
+      public key for the period:
+
+           A' = h A = (ha)B
 
   Generating a signature of M: given a deterministic random-looking r
   (see EdDSA paper), take R=rB, S=r+hash(R,A',M)ah mod l. Send signature
@@ -2185,6 +2193,8 @@ A.2. Tor's key derivation scheme
           = rB + (hash(R,A',M)ah)B
           = R + hash(R,A',M)A' )
 
+  This boils down to regular Ed25519 with key pair (a', A').
+
   See [KEYBLIND-REFS] for an extensive discussion on this scheme and
   possible alternatives. Also, see [KEYBLIND-PROOF] for a security
   proof of this scheme.
@@ -2222,7 +2232,7 @@ Appendix C. Recommendations for searching for vanity .onions [VANITY]
         While pk does not satisfy X:
 
             Add the number 8 to sk
-            Add the scalar 8*B to pk
+            Add the point 8*B to pk
 
         Return sk, pk.