Describe the behavior of our HSv3 crypto layers.

These layers use SHA3 instead of SHA1 and AES256 instead of AES128.
Their SENDME tags are made with SHA3 too, but they are truncated to
20 bytes.

Closes #204.

2 files changed, 7 insertions, 1 deletions

diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt
index 53880db..062b3d7 100644
--- a/rend-spec-v3.txt
+++ b/rend-spec-v3.txt
@@ -2080,7 +2080,8 @@ Table of contents:
    The hidden service host now also knows the keys generated by the
    handshake, which it will use to encrypt and authenticate data
    end-to-end between the client and the server. These keys are as
-   computed in tor-spec.txt section 5.1.4.
+   computed in tor-spec.txt section 5.1.4, except that instead of using
+   AES-128 and SHA1 for this hop, we use AES-256 and SHA3-256.
 
 3.4. Authentication during the introduction phase. [INTRO-AUTH]
 
diff --git a/tor-spec.txt b/tor-spec.txt
index 72a3f19..8ab16d8 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -2175,6 +2175,11 @@ see tor-design.pdf.
          matched on the other side from the previous cell sent that the OR/OP
          must remember.
 
+         (Note that if the digest in use has an output length greater than 20
+         bytes—as is the case for the hop of an onion service rendezvous
+         circuit created by the hs_ntor handshake—we truncate the digest
+         to 20 bytes here.)
+
    If the VERSION is unrecognized or below the minimum accepted version (taken
    from the consensus), the circuit should be torn down.