Fix length of replaycache-checked data.

This is a regression; we should have been checking only the
public-key encrypted portion.  Fixes bug 24244, TROVE-2017-009, and
CVE-2017-8819.

changes/trove-2017-009

@@ -0,0 +1,10 @@
+  o Major fixes (security):
+    - When checking for replays in the INTRODUCE1 cell data for a (legacy)
+      hiddden service, correctly detect replays in the RSA-encrypted part of
+      the cell. We were previously checking for replays on the entire cell,
+      but those can be circumvented due to the malleability of Tor's legacy
+      hybrid encryption. This fix helps prevent a traffic confirmation
+      attack. Fixes bug 24244; bugfix on 0.2.4.1-alpha. This issue is also
+      tracked as TROVE-2017-009 and CVE-2017-8819.
+
+

src/or/rendservice.c

@@ -1162,6 +1162,7 @@ rend_service_introduce(origin_circuit_t *circuit, const uint8_t *request,
   time_t now = time(NULL);
   time_t elapsed;
   int replay;
+  size_t keylen;
 
   /* Do some initial validation and logging before we parse the cell */
   if (circuit->base_.purpose != CIRCUIT_PURPOSE_S_INTRO) {
@@ -1245,9 +1246,10 @@ rend_service_introduce(origin_circuit_t *circuit, const uint8_t *request,
   }
 
   /* check for replay of PK-encrypted portion. */
+  keylen = crypto_pk_keysize(intro_key);
   replay = replaycache_add_test_and_elapsed(
     intro_point->accepted_intro_rsa_parts,
-    parsed_req->ciphertext, parsed_req->ciphertext_len,
+    parsed_req->ciphertext, MIN(parsed_req->ciphertext_len, keylen),
     &elapsed);
 
   if (replay) {