Come up with a rendezvous INTRODUCE1 format that actually works for unknown rendezvous points. This will take some doing to implement

svn:r4464
This commit is contained in:
Nick Mathewson 2005-06-20 00:08:47 +00:00
parent e376e6cc07
commit 8a6f22b25d

View File

@ -251,9 +251,17 @@ $Id$
RP Rendezvous point's nickname [20 octets]
RC Rendezvous cookie [20 octets]
g^x Diffie-Hellman data, part 1 [128 octets]
OR
OR
VER Version byte: set to 1. [1 octet]
RP [42 octets]
RP Rendezvous point nick or ID [42 octets]
RC Rendezvous cookie [20 octets]
g^x Diffie-Hellman data, part 1 [128 octets]
OR
VER Version byte: set to 2. [1 octet]
IP Rendezvous point's address [4 octets]
PORT Rendezvous point's OR port [2 octets]
ID Rendezvous point identity ID [20 octets]
KEY Rendezvous point onion key [128 octets]
RC Rendezvous cookie [20 octets]
g^x Diffie-Hellman data, part 1 [128 octets]
@ -261,13 +269,14 @@ $Id$
and must contain EITHER a nickname, or an identity key digest, encoded in
hex, and prefixed with a '$'.
Implementations must accept both variants, but should only generate the
first so long as Tor 0.0.7 is in use.
Implementations must accept all variants, but should only generate the
first so long as any version of Tor before 0.1.1 is still in use.
Implementations should never generate the second version.
The hybrid encryption to Bob's PK works just like the hybrid
encryption in CREATE cells (see main spec). Thus the payload of the
RELAY_INTRODUCE1 cell on the wire will contain 20+42+16+20+20+128=246
bytes.
bytes. [XXXX not really]
1.9. Introduction: From the Introduction Point to Bob's OP