Clarify how we derive ed25519 for cross-certification.

The descriptor format uses a curve25519->ed25519 conversion
algorithm to cross-certify descriptors with their ntor onion keys.

This patch clarifies two aspects of the algorithm:

1. When deriving a private key, how to derive the part of the
   private key that _isn't_ a point on the curve.

2. That there are two algorithms here, one for private->private and
   one for public->public.

1 files changed, 14 insertions, 4 deletions

diff --git a/dir-spec.txt b/dir-spec.txt
index 543e341..0eb174a 100644
--- a/dir-spec.txt
+++ b/dir-spec.txt
@@ -4162,10 +4162,20 @@ C. Converting a curve25519 public key to an ed25519 public key
    [Recomputing the sign bit from the private key every time sounds
    rather strange and inefficient to me… —isis]
 
-   Alternatively, without access to the corresponding ed25519 private
-   key, one may use the Montgomery u-coordinate to recover the
-   Montgomery v-coordinate by computing the right-hand side of the
-   Montgomery curve equation:
+   Note that in addition to its coordinates, an expanded Ed25519 private key
+   also has a 32-byte random value, "prefix", used to compute internal `r`
+   values in the signature.  For security, this prefix value should be
+   derived deterministically from the curve25519 key.  The Tor
+   implementation derives it as SHA512(private_key | STR)[0..32], where
+   STR is the nul-terminated string:
+
+        "Derive high part of ed25519 key from curve25519 key\0"
+
+
+   On the client side, where there is no access to the curve25519 private
+   keys, one may use the curve25519 public key's Montgomery u-coordinate to
+   recover the Montgomery v-coordinate by computing the right-hand side of
+   the Montgomery curve equation:
 
          bv^2 = u(u^2 + au +1)