[or-cvs] r11498: clean up r11496 (in tor/trunk: doc/spec src/or)
arma at seul.org
arma at seul.org
Tue Sep 18 23:34:27 UTC 2007
Author: arma
Date: 2007-09-18 19:34:27 -0400 (Tue, 18 Sep 2007)
New Revision: 11498
Modified:
tor/trunk/doc/spec/rend-spec.txt
tor/trunk/src/or/rendcommon.c
tor/trunk/src/or/rendservice.c
Log:
clean up r11496
Modified: tor/trunk/doc/spec/rend-spec.txt
===================================================================
--- tor/trunk/doc/spec/rend-spec.txt 2007-09-18 21:51:06 UTC (rev 11497)
+++ tor/trunk/doc/spec/rend-spec.txt 2007-09-18 23:34:27 UTC (rev 11498)
@@ -123,39 +123,35 @@
The first time the OP provides an advertised service, it generates
a public/private keypair (stored locally). Periodically, the OP
- generates and publishes a descriptor of type "V0". The V1 descriptor
- format in 0.1.1.5-alpha-cvs is understood and accepted, but currently
- no Tors generate them. The more complex V1 descriptor format below
- is just speculation and has never been used.
+ generates and publishes a descriptor of type "V0".
- A hypothetical "V1" descriptor contains:
+ The "V0" descriptor contains:
- V Format byte: set to 255 [1 octet]
- V Version byte: set to 1 [1 octet]
KL Key length [2 octets]
PK Bob's public key [KL octets]
TS A timestamp [4 octets]
- PROTO Rendezvous protocol versions: bitmask [2 octets]
- NA Number of auth mechanisms accepted [1 octet]
- For each auth mechanism:
- AUTHT The auth type that is supported [2 octets]
- AUTHL Length of auth data [1 octet]
- AUTHD Auth data [variable]
NI Number of introduction points [2 octets]
- For each introduction point: (as in INTRODUCE2 cells)
- ATYPE An address type (typically 4) [1 octet]
- ADDR Introduction point's IP address [4 or 16 octets]
- PORT Introduction point's OR port [2 octets]
- AUTHT The auth type that is supported [2 octets]
- AUTHL Length of auth data [1 octet]
- AUTHD Auth data [variable]
- ID Introduction point identity ID [20 octets]
- KLEN Length of onion key [2 octets]
- KEY Introduction point onion key [KLEN octets]
+ Ipt A list of NUL-terminated ORs [variable]
SIG Signature of above fields [variable]
- The "V1" descriptor in 0.1.1.5-alpha-cvs contains:
+ KL is the length of PK, in octets.
+ TS is the number of seconds elapsed since Jan 1, 1970.
+ The members of Ipt may be either (a) nicknames, or (b) identity key
+ digests, encoded in hex, and prefixed with a '$'. Clients must
+ accept both forms. Services must only generate the second form.
+ Once 0.0.9.x is obsoleted, we can drop the first form.
+
+ [It's ok for Bob to advertise 0 introduction points. He might want
+ to do that if he previously advertised some introduction points,
+ and now he doesn't have any. -RD]
+
+1.2.1. Other descriptor formats we don't use.
+
+ The V1 descriptor format was understood and accepted from
+ 0.1.1.5-alpha-cvs to 0.2.0.6-alpha-dev, but no Tors generated it and
+ was removed:
+
V Format byte: set to 255 [1 octet]
V Version byte: set to 1 [1 octet]
KL Key length [2 octets]
@@ -171,37 +167,39 @@
KEY Introduction point onion key [KLEN octets]
SIG Signature of above fields [variable]
- The "V0" descriptor contains:
+ A hypothetical "V1" descriptor, that has never been used but might
+ be useful for historical reasons, contains:
+ V Format byte: set to 255 [1 octet]
+ V Version byte: set to 1 [1 octet]
KL Key length [2 octets]
PK Bob's public key [KL octets]
TS A timestamp [4 octets]
+ PROTO Rendezvous protocol versions: bitmask [2 octets]
+ NA Number of auth mechanisms accepted [1 octet]
+ For each auth mechanism:
+ AUTHT The auth type that is supported [2 octets]
+ AUTHL Length of auth data [1 octet]
+ AUTHD Auth data [variable]
NI Number of introduction points [2 octets]
- Ipt A list of NUL-terminated ORs [variable]
+ For each introduction point: (as in INTRODUCE2 cells)
+ ATYPE An address type (typically 4) [1 octet]
+ ADDR Introduction point's IP address [4 or 16 octets]
+ PORT Introduction point's OR port [2 octets]
+ AUTHT The auth type that is supported [2 octets]
+ AUTHL Length of auth data [1 octet]
+ AUTHD Auth data [variable]
+ ID Introduction point identity ID [20 octets]
+ KLEN Length of onion key [2 octets]
+ KEY Introduction point onion key [KLEN octets]
SIG Signature of above fields [variable]
- KL is the length of PK, in octets.
- TS is the number of seconds elapsed since Jan 1, 1970.
-
AUTHT specifies which authentication/authorization mechanism is
required by the hidden service or the introduction point. AUTHD
is arbitrary data that can be associated with an auth approach.
Currently only AUTHT of [00 00] is supported, with an AUTHL of 0.
See section 2 of this document for details on auth mechanisms.
- The members of Ipt may be either (a) nicknames, or (b) identity key
- digests, encoded in hex, and prefixed with a '$'. Clients must
- accept both forms. Services must only generate the second form.
- Once 0.0.9.x is obsoleted, we can drop the first form.
-
- [It's ok for Bob to advertise 0 introduction points. He might want
- to do that if he previously advertised some introduction points,
- and now he doesn't have any. -RD]
-
- [Once Tor 0.1.0.x is obsolete, we can stop generating or using V0
- descriptors. -NM]
- [This should rather be retarded until V2 descriptors are stable. -KL]
-
1.3. Bob's OP establishes his introduction points.
The OP establishes a new introduction circuit to each introduction
@@ -333,8 +331,6 @@
Cleartext
PK_ID Identifier for Bob's PK [20 octets]
-[XXX011 want to put intro-level auth info here, but no version. crap. -RD]
-
Encrypted to Bob's PK:
RP Rendezvous point's nickname [20 octets]
RC Rendezvous cookie [20 octets]
@@ -349,12 +345,33 @@
IP Rendezvous point's address [4 octets]
PORT Rendezvous point's OR port [2 octets]
ID Rendezvous point identity ID [20 octets]
- KLEN Length of onion key [2 octets]
+ KLEN Length of onion key [2 octets]
KEY Rendezvous point onion key [KLEN octets]
RC Rendezvous cookie [20 octets]
g^x Diffie-Hellman data, part 1 [128 octets]
- OR
- VER Version byte: set to 4. [1 octet]
+
+ PK_ID is the hash of Bob's public key. RP is NUL-padded and
+ terminated. In version 0, it must contain a nickname. In version 1,
+ it must contain EITHER a nickname or an identity key digest that is
+ encoded in hex and prefixed with a '$'.
+
+ The hybrid encryption to Bob's PK works just like the hybrid
+ encryption in CREATE cells (see tor-spec). Thus the payload of the
+ version 0 RELAY_INTRODUCE1 cell on the wire will contain
+ 20+42+16+20+20+128=246 bytes, and the version 1 and version 2
+ introduction formats have other sizes.
+
+ As of Tor 0.2.0.6-alpha, clients only generate the v0 introduction
+ format, whereas hidden services have understoodd and accepted v0,
+ v1, and v2 since 0.1.1.x.
+
+1.8.1. Other introduction formats we don't use.
+
+ We briefly speculated about using the following format for the
+ "encrypted to Bob's PK" part of the introduction, but no Tors have
+ ever generated these.
+
+ VER Version byte: set to 3. [1 octet]
ATYPE An address type (typically 4) [1 octet]
ADDR Rendezvous point's IP address [4 or 16 octets]
PORT Rendezvous point's OR port [2 octets]
@@ -367,22 +384,6 @@
RC Rendezvous cookie [20 octets]
g^x Diffie-Hellman data, part 1 [128 octets]
- PK_ID is the hash of Bob's public key. RP is NUL-padded and terminated,
- and must contain EITHER a nickname, or an identity key digest, encoded in
- hex, and prefixed with a '$'.
-
- Implementations SHOULD accept all variants, although only the first,
- unversioned variant SHOULD be generated. If V1 descriptors were used,
- implementations SHOULD have listed the variants they accept in their V1
- descriptor, and implementations SHOULD only have generated the variants
- listed in the service's V1 descriptor. No version SHOULD generate the
- second variant (version byte=1).
-
- 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. [XXXX not really]
-
1.9. Introduction: From the Introduction Point to Bob's OP
If the Introduction Point recognizes PK_ID as a public key which has
Modified: tor/trunk/src/or/rendcommon.c
===================================================================
--- tor/trunk/src/or/rendcommon.c 2007-09-18 21:51:06 UTC (rev 11497)
+++ tor/trunk/src/or/rendcommon.c 2007-09-18 23:34:27 UTC (rev 11498)
@@ -43,7 +43,7 @@
tor_free(desc);
}
-/** Encode a service descriptor for <b>desc</b>, and sign it with
+/** Encode a V0 service descriptor for <b>desc</b>, and sign it with
* <b>key</b>. Store the descriptor in *<b>str_out</b>, and set
* *<b>len_out</b> to its length.
*/
Modified: tor/trunk/src/or/rendservice.c
===================================================================
--- tor/trunk/src/or/rendservice.c 2007-09-18 21:51:06 UTC (rev 11497)
+++ tor/trunk/src/or/rendservice.c 2007-09-18 23:34:27 UTC (rev 11498)
@@ -301,7 +301,8 @@
d->n_intro_points = 0;
d->intro_points = tor_malloc_zero(sizeof(char*)*n);
d->intro_point_extend_info = tor_malloc_zero(sizeof(extend_info_t*)*n);
- d->protocols = (1<<2) | (1<<0); /* We support protocol 2 and protocol 0. */
+ /* We support intro protocol 2 and protocol 0. */
+ d->protocols = (1<<2) | (1<<0);
for (i=0; i < n; ++i) {
router = router_get_by_nickname(smartlist_get(service->intro_nodes, i),1);
if (!router) {
@@ -541,7 +542,7 @@
* any */
router = router_get_by_nickname(rp_nickname, 0);
if (!router) {
- log_info(LD_REND, "Couldn't find router %s named in rendezvous cell.",
+ log_info(LD_REND, "Couldn't find router %s named in introduce2 cell.",
escaped_safe_str(rp_nickname));
/* XXXX Add a no-such-router reason? */
reason = END_CIRC_REASON_TORPROTOCOL;
More information about the tor-commits
mailing list