commit 95a64b03cdb8f2254c11f33fc8ebb24b9d9be369 Author: George Kadianakis <desnacked@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)