[tor-commits] [torspec/master] prop224: Switch back to a TYPE/LEN/KEY construction for cells.
asn at torproject.org
asn at torproject.org
Tue Apr 19 12:33:48 UTC 2016
commit 95a64b03cdb8f2254c11f33fc8ebb24b9d9be369
Author: George Kadianakis <desnacked at riseup.net>
Date: Thu Apr 14 13:14:37 2016 +0300
prop224: Switch back to a TYPE/LEN/KEY construction for cells.
Nick pointed out that having the length explicit is better for
backwards/future compatibility.
Also change some field names so that they are mostly uniform
throughout the proposal.
---
proposals/224-rend-spec-ng.txt | 56 ++++++++++++++++++------------------------
1 file changed, 24 insertions(+), 32 deletions(-)
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index 1edbc08..001d2ba 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -152,19 +152,6 @@ Status: Draft
themselves, but over those strings prefixed with a distinguishing
value.
- Through this proposal we use the following construction when sending
- cryptographic keys in tor cells:
-
- KEYTYPE [1 byte]
- KEY [depends on KEYTYPE]
-
- In this case the size of the KEY depends on the KEYTYPE. Here are the
- currently defined key types:
-
- * The KEYTYPE value [01] is for Ed25519 keys (size: 32 bytes).
- * The KEYTYPE value [02] is for Curve25519 keys (size: 32 bytes).
- * The KEYTYPE value [03] is for truncated Curve25519 keys (size: 8 bytes).
-
0.4. Protocol building blocks [BUILDING-BLOCKS]
In sections below, we need to transmit the locations and identities
@@ -1192,10 +1179,12 @@ Status: Draft
An INTRODUCE1 cell has the following contents:
- AUTH_KEYTYPE [1 byte]
- AUTH_KEYID [depends on AUTH_KEYTYPE]
- ENC_KEYTYPE [1 byte]
- ENC_KEYID [depends on ENC_KEYTYPE]
+ AUTH_KEY_TYPE [1 byte]
+ AUTH_KEY_LEN [1 byte]
+ AUTH_KEY [AUTH_KEY_LEN bytes]
+ ENC_KEY_TYPE [1 byte]
+ ENC_KEY_LEN [1 byte]
+ ENC_KEY [ENC_KEY_LEN bytes]
N_EXTENSIONS [1 byte]
N_EXTENSIONS times:
EXT_FIELD_TYPE [1 byte]
@@ -1208,20 +1197,20 @@ Status: Draft
encryption method? The latter is probably safer.]
Upon receiving an INTRODUCE1 cell, the introduction point checks
- whether AUTH_KEYID and ENC_KEYID match a configured introduction
+ whether AUTH_KEY and ENC_KEY match a configured introduction
point authentication key and introduction point encryption key. If
they do, the cell is relayed; if not, it is not.
- (After checking AUTH_KEYID and ENC_KEYID and finding no match, the
- introduction point should check to see whether a legacy hidden service is
- running whose PK_ID is the first 20 bytes of AUTH_KEYID. If so, it
- behaves as in rend-spec.txt.)
+ (After checking AUTH_KEY and ENC_KEY and finding no match, the introduction
+ point should check to see whether a legacy hidden service is running whose
+ PK_ID is the first 20 bytes of AUTH_KEY. If so, it behaves as in
+ rend-spec.txt.)
- The AUTH_KEYTYPE is an Ed25519 public key (value [01]).
+ The AUTH_KEY_TYPE is an Ed25519 public key (value [01]).
- The ENC_KEYTYPE is a truncated Curve25519 public key (value [03]). (This key
+ The ENC_KEY_TYPE is a truncated Curve25519 public key (value [03]). (This key
is safe to truncate, since all the keys are generated by the hidden service
- host, and the ID is only valid relative to a single AUTH_KEYID.) The
+ host, and the ID is only valid relative to a single AUTH_KEY.) The
ENCRYPTED field is as described in 3.3 below.
To relay an INTRODUCE1 cell, the introduction point sends an
@@ -1296,7 +1285,8 @@ Status: Draft
EXT_FIELD_LEN [1 byte]
EXT_FIELD [EXT_FIELD_LEN bytes]
ONION_KEY_TYPE [1 bytes]
- ONION_KEY [depends on ONION_KEY_TYPE]
+ ONION_KEY_LEN [1 bytes]
+ ONION_KEY [ONION_KEY_LEN bytes]
NSPEC (Number of link specifiers) [1 byte]
NSPEC times:
LSTYPE (Link specifier type) [1 byte]
@@ -1394,10 +1384,12 @@ Status: Draft
Substituting those fields into the INTRODUCE1 cell body format
described in [FMT_INTRO1] above, we have
- AUTH_KEYTYPE [1 byte]
- AUTH_KEYID [depends on AUTH_KEYTYPE]
- ENC_KEYTYPE [1 byte]
- ENC_KEYID [depends on ENC_KEYTYPE]
+ AUTH_KEY_TYPE [1 byte]
+ AUTH_KEY_LEN [1 byte]
+ AUTH_KEY [AUTH_KEY_LEN bytes]
+ ENC_KEY_TYPE [1 byte]
+ ENC_KEY_LEN [1 byte]
+ ENC_KEY [ENC_KEY_LEN bytes]
N_EXTENSIONS [1 bytes]
N_EXTENSIONS times:
EXT_FIELD_TYPE [1 byte]
@@ -1416,10 +1408,10 @@ Status: Draft
described in [LEGACY-INTRODUCE1].)
Here, the encryption key plays the role of B in the regular ntor
- handshake, and the AUTH_KEYID field plays the role of the node ID.
+ handshake, and the AUTH_KEY field plays the role of the node ID.
The CLIENT_PK field is the public key X. The ENCRYPTED_DATA field is
the message plaintext, encrypted with the symmetric key ENC_KEY. The
- MAC field is a MAC of all of the cell from the AUTH_KEYID through the
+ MAC field is a MAC of all of the cell from the AUTH_KEY through the
end of ENCRYPTED_DATA, using the MAC_KEY value as its key.
To process this format, the hidden service checks PK_VALID(CLIENT_PK)
More information about the tor-commits
mailing list