[tor-commits] [torspec/master] Describe replay prevention for INTRODUCE2 cells

[nickm@xxxxxxxxxxxxxx]

commit 70d87e56d55a0a4f696a896d0ffcd7bae5cad0fc
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Mon Mar 11 17:31:15 2013 -0400

    Describe replay prevention for INTRODUCE2 cells
    
    Resolves ticket #4608
---
 rend-spec.txt |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/rend-spec.txt b/rend-spec.txt
index 6c90c70..9d207d7 100644
--- a/rend-spec.txt
+++ b/rend-spec.txt
@@ -683,7 +683,20 @@
    determined later; the current implementation sends a single '1' byte on
    failure.)
 
-   When Bob's OP receives the RELAY_COMMAND_INTRODUCE2 cell, it decrypts it
+   When Bob's OP receives the RELAY_COMMAND_INTRODUCE2 cell, it first checks
+   for a replay.  Because of the (undesirable!) malleability of the hybrid
+   encryption, Bob's OP should only check whether the RSA-encrypted part is
+   replayed.  It does this by keeping, for each introduction key, a list of
+   cryptographic digests of all the RSA-encrypted parts of the INTRODUCE2
+   cells that it's seen, and dropping any INTRODUCE2 cell whose RSA-encrypted
+   part it has seen before.  When Bob's OP stops using a given introduction
+   key, it drops the replay cache corresponding to that key.
+
+   (Versions of Tor before 0.2.3.9-alpha used the timestamp in the INTRODUCE2
+   cell to limit the lifetime of entries in the replay cache. This proved to
+   be fragile, due to insufficiently synchronized clients.)
+
+   Assuming that the cell has not been replayed, Bob's server decrypts it
    with the private key for the corresponding hidden service, and extracts the
    rendezvous point's nickname, the rendezvous cookie, and the value of g^x
    chosen by Alice.



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits