May 2016 - tor-commits - lists.torproject.org

[tor/master] Use a much less clever scan_signed no-overflow hack
by nickm＠torproject.org 12 May '16

12 May '16

commit 6bc052365a8dbfc9ed7c43e69761099ba973af74 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu May 12 14:33:26 2016 -0400 Use a much less clever scan_signed no-overflow hack --- src/common/util.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/src/common/util.c b/src/common/util.c index fa2953c..d290f54 100644 --- a/src/common/util.c +++ b/src/common/util.c @@ -3060,7 +3060,7 @@ digit_to_num(char d) * success, store the result in <b>out</b>, advance bufp to the next * character, and return 0. On failure, return -1. */ static int -scan_unsigned(const char **bufp, unsigned long *out, int width, int base) +scan_unsigned(const char **bufp, unsigned long *out, int width, unsigned base) { unsigned long result = 0; int scanned_so_far = 0; @@ -3073,7 +3073,7 @@ scan_unsigned(const char **bufp, unsigned long *out, int width, int base) while (**bufp && (hex?TOR_ISXDIGIT(**bufp):TOR_ISDIGIT(**bufp)) && scanned_so_far < width) { - int digit = hex?hex_decode_digit(*(*bufp)++):digit_to_num(*(*bufp)++); + unsigned digit = hex?hex_decode_digit(*(*bufp)++):digit_to_num(*(*bufp)++); // Check for overflow beforehand, without actually causing any overflow // This preserves functionality on compilers that don't wrap overflow // (i.e. that trap or optimise away overflow) @@ -3119,14 +3119,15 @@ scan_signed(const char **bufp, long *out, int width) if (neg && result > 0) { if (result > ((unsigned long)LONG_MAX) + 1) return -1; /* Underflow */ - // Avoid overflow on the cast to signed long when result is LONG_MIN - // by subtracting 1 from the unsigned long positive value, - // then, after it has been cast to signed and negated, - // subtracting the original 1 (the double-subtraction is intentional). - // Otherwise, the cast to signed could cause a temporary long - // to equal LONG_MAX + 1, which is undefined. - // We avoid underflow on the subtraction by treating -0 as positive. - *out = (-(long)(result - 1)) - 1; + else if (result == ((unsigned long)LONG_MAX) + 1) + *out = LONG_MIN; + else { + /* We once had a far more clever no-overflow conversion here, but + * some versions of GCC apparently ran it into the ground. Now + * we just check for LONG_MIN explicitly. + */ + *out = -(long)result; + } } else { if (result > LONG_MAX) return -1; /* Overflow */

1 0

[torspec/master] prop224: Add a table of contents to the proposal.
by asn＠torproject.org 12 May '16

12 May '16

commit 12be3afbcf2ec1fe0bfc3222e200c4e3dcced05c Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue May 10 15:01:36 2016 -0400 prop224: Add a table of contents to the proposal. --- proposals/224-rend-spec-ng.txt | 54 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 70f05e9..4107599 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -4,6 +4,60 @@ Author: Nick Mathewson Created: 2013-11-29 Status: Draft +Table of contents: + + 0. Hidden services: overview and preliminaries. + 0.1. Improvements over previous versions. + 0.2. Notation and vocabulary + 0.3. Cryptographic building blocks + 0.4. Protocol building blocks [BUILDING-BLOCKS] + 0.5. Assigned relay cell types + 0.5. Acknowledgments + 1. Protocol overview + 1.1. View from 10,000 feet + 1.2. In more detail: naming hidden services [NAMING] + 1.3. In more detail: Access control [IMD:AC] + 1.4. In more detail: Distributing hidden service descriptors. [IMD:DIST] + 1.5. In more detail: Scaling to multiple hosts + 1.6. In more detail: Backward compatibility with older hidden service + 1.7. In more detail: Keeping crypto keys offline + 1.8. In more detail: Encryption Keys And Replay Resistance + 1.9. In more detail: A menagerie of keys + 2. Generating and publishing hidden service descriptors [HSDIR] + 2.1. Deriving blinded keys and subcredentials [SUBCRED] + 2.2. Locating, uploading, and downloading hidden service descriptors + 2.2.1. Dividing time into periods [TIME-PERIODS] + 2.2.2. Overlapping time periods to avoid thundering herds [TIME-OVERLAP] + 2.2.3. Where to publish a service descriptor + 2.2.4. Using time periods and SRVs to fetch/upload HS descriptors + 2.2.5. URLs for anonymous uploading and downloading + 2.3. Publishing shared random values [PUB-SHAREDRANDOM] + 2.3.1. Client behavior in the absense of shared random values + 2.3.2. Hidden services and changing shared random values + 2.4. Hidden service descriptors: outer wrapper [DESC-OUTER] + 2.5. Hidden service descriptors: encryption format [ENCRYPTED-DATA] + 3. The introduction protocol + 3.1. Registering an introduction point [REG_INTRO_POINT] + 3.1.1. Extensible ESTABLISH_INTRO protocol. [EST_INTRO] + 3.1.2. Registering an introduction point on a legacy Tor node [LEGACY_EST_INTRO] + 3.1.3. Acknowledging establishment of introduction point [INTRO_ESTABLISHED] + 3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1] + 3.2.1. INTRODUCE1 cell format [FMT_INTRO1] + 3.2.2. Legacy formats [LEGACY-INTRODUCE1] + 3.2.3. INTRODUCE_ACK cell format. [INTRO_ACK] + 3.3. Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2] + 3.3.1. Introduction handshake encryption requirements [INTRO-HANDSHAKE-REQS] + 3.3.2. Example encryption handshake: ntor with extra data [NTOR-WITH-EXTRA-DATA] + 3.4. Authentication during the introduction phase. [INTRO-AUTH] + 3.4.1. Password-based authentication. + 3.4.2. Ed25519-based authentication. + 4. The rendezvous protocol + 4.1. Establishing a rendezvous point [EST_REND_POINT] + 4.2. Joining to a rendezvous point [JOIN_REND] + 4.2.1. Key expansion + 4.3. Using legacy hosts as rendezvous points + 5. Encrypting data between client and host + 6. Open Questions: -1. Draft notes

1 0

[torspec/master] prop224: Clarify the format of INTRODUCE1 cells
by asn＠torproject.org 12 May '16

12 May '16

commit 8731baffa869894416aa0d09f499298ed05a87f4 Author: John Brooks <special(a)torproject.org> Date: Mon May 9 18:45:35 2016 -0400 prop224: Clarify the format of INTRODUCE1 cells - Clarify how to distinguish between old and new style cells. - Don't send the encryption key to the introduction point. --- proposals/224-rend-spec-ng.txt | 100 ++++++++++++++++++----------------------- 1 file changed, 43 insertions(+), 57 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 4107599..097f442 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1220,12 +1220,10 @@ Table of contents: An INTRODUCE1 cell has the following contents: + LEGACY_KEY_ID [20 bytes] 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] @@ -1233,31 +1231,43 @@ Table of contents: EXT_FIELD [EXT_FIELD_LEN bytes] ENCRYPTED [Up to end of relay payload] - [TODO: Should we have a field to determine the type of ENCRYPTED, or - should we instead assume that there is exactly one encryption key per - encryption method? The latter is probably safer.] [Agree -RD] + The LEGACY_KEY_ID field is used to distinguish between legacy and new style + INTRODUCE1 cells. In new style INTRODUCE1 cells, LEGACY_KEY_ID is 20 zero + bytes. Upon receiving an INTRODUCE1 cell, the introduction point checks the + LEGACY_KEY_ID field. If LEGACY_KEY_ID is non-zero, the INTRODUCE1 cell + should be handled as specified in rend-spec.txt. - Upon receiving an INTRODUCE1 cell, the introduction point checks - 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. + AUTH_KEY_TYPE is defined as in [EST_INTRO]. Currently, the only value of + AUTH_KEY_TYPE for this cell is an Ed25519 public key [02]. - (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.) + Upon receiving a INTRODUCE1 cell, the introduction point checks + whether AUTH_KEY matches the introduction point authentication key for an + active introduction circuit. If so, the introduction point sends an + INTRODUCE2 cell with exactly the same contents to the service, and sends an + INTRODUCE_ACK response to the client. - The AUTH_KEY_TYPE is an Ed25519 public key (value [01]). +3.2.2. Legacy formats [LEGACY-INTRODUCE1] - 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_KEY.) The - ENCRYPTED field is as described in 3.3 below. + When a client is using a legacy introduction point, INTRODUCE1 cells should + be of the form: - To relay an INTRODUCE1 cell, the introduction point sends an - INTRODUCE2 cell with exactly the same contents. + LEGACY_KEYID_HASH [20 bytes] + N_EXTENSIONS [1 byte] + N_EXTENSIONS times: + EXT_FIELD_TYPE [1 byte] + EXT_FIELD_LEN [1 byte] + EXT_FIELD [EXT_FIELD_LEN bytes] + ENCRYPTED [Up to end of relay payload] + + Here, LEGACY_KEYID_HASH is the hash of the introduction point legacy + encryption key that was included in the hidden service descriptor. + + Because of limitations in older versions of Tor, the relay payload size for + these INTRODUCE1 cells must always be at least 246 bytes, or they will be + rejected as invalid. The ENCRYPTED field may contain padding to reach this + length. -3.2.2. INTRODUCE_ACK cell format. [INTRO_ACK] +3.2.3. INTRODUCE_ACK cell format. [INTRO_ACK] An INTRODUCE_ACK cell has the following fields: @@ -1271,36 +1281,13 @@ Table of contents: Recognized status values are: [00 00] -- Success: cell relayed to hidden service host. [00 01] -- Failure: service ID not recognized - [00 02] -- Failure: key ID not recognized - [00 03] -- Bad message format - -3.2.3. Legacy formats [LEGACY-INTRODUCE1] - - If a hidden service has listed a legacy introduction point in its - descriptor, INTRODUCE1 cells should be of the form: - - LEGACY_KEYID_HASH [20 bytes] - ENC_KEYID [8 bytes] - N_EXTENSIONS [1 byte] - N_EXTENSIONS times: - EXT_FIELD_TYPE [1 byte] - EXT_FIELD_LEN [1 byte] - EXT_FIELD [EXT_FIELD_LEN bytes] - ENCRYPTED [Up to end of relay payload] - - Here, LEGACY_KEYID_HASH is the hash of the introduction point legacy - encryption key that was included in the hidden service descriptor. - - Because of limitations in older versions of Tor, the relay payload size for - these INTRODUCE1 cells must always be at least 246 bytes, or they will be - rejected as invalid. [TODO: Do we need to pad with something?] + [00 02] -- Bad message format 3.3. Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2] - Upon receiving an INTRODUCE2 cell, the hidden service host checks - whether the AUTH_KEYID/AUTH_KEYID_HASH field and the ENC_KEYID fields - are as expected, and match the configured authentication and - encryption key(s) on that circuit. + Upon receiving an INTRODUCE2 cell, the hidden service host checks whether + the AUTH_KEY or LEGACY_KEYID_HASH field matches the keys for this + introduction circuit. The service host then checks whether it has received a cell with these contents before. If it has, it silently drops it as a @@ -1335,7 +1322,6 @@ Table of contents: LSPEC (Link specifier) [LSLEN bytes] PAD (optional padding) [up to end of plaintext] - Upon processing this plaintext, the hidden service makes sure that any required authentication is present in the extension fields, and then extends a rendezvous circuit to the node described in the LSPEC @@ -1355,6 +1341,9 @@ Table of contents: extending to the rendezvous point. It must be of a type listed as supported in the hidden service descriptor. + When using a legacy introduction point, the INTRODUCE cells must be padded + to a certain length using the PAD field in the encrypted portion. + Upon receiving a well-formed INTRODUCE2 cell, the hidden service host will have: @@ -1426,11 +1415,8 @@ Table of contents: described in [FMT_INTRO1] above, we have AUTH_KEY_TYPE [1 byte] - AUTH_KEY_LEN [1 byte] + AUTH_KEY_LEN [2 bytes] 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] @@ -1534,8 +1520,7 @@ Table of contents: "hidserv-userauth-ed25519" Nonce (same as above) Pubkey (same as above) - AUTH_KEYID (As in the INTRODUCE1 cell) - ENC_KEYID (As in the INTRODUCE1 cell) + AUTH_KEY (As in the INTRODUCE1 cell) The hidden service host checks this by seeing whether it recognizes and would accept a signature from the provided public key. If it @@ -1639,7 +1624,8 @@ Table of contents: Old versions of Tor required that RENDEZVOUS cell payloads be exactly 168 bytes long. All shorter rendezvous payloads should be padded to - this length with [00] bytes. + this length with random bytes, to make them difficult to distinguish from + older protocols at the rendezvous point. 5. Encrypting data between client and host

1 0

[torspec/master] prop224: Various improvements and XXX removals.
by asn＠torproject.org 12 May '16

12 May '16

commit c4d470333bc5735a60b6282ff8d97ac952309fdf Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue May 10 10:53:05 2016 -0400 prop224: Various improvements and XXX removals. - Replace AES128-CTR with AES256. - Use relay ed25519 identity keys to create the HSDir hash ring. - Accept 0 introduction points in descriptors. --- proposals/224-rend-spec-ng.txt | 60 ++++++++++++++++-------------------------- 1 file changed, 22 insertions(+), 38 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 097f442..408a982 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -188,7 +188,7 @@ Table of contents: As a first pass, I suggest: - * Instantiate STREAM with AES128-CTR. [TODO: or ChaCha20?] + * Instantiate STREAM with AES256-CTR. * Instantiate SIGN with Ed25519 and the blinding protocol in [KEYBLIND]. @@ -204,9 +204,7 @@ Table of contents: For legacy purposes, we specify compatibility with older versions of the Tor introduction point and rendezvous point protocols. These used RSA1024, DH1024, AES128, and SHA1, as discussed in - rend-spec.txt. Except as noted, all RSA keys MUST have exponent - values of 65537. - [XXX -- is this last sentence new? I think we don't require it now. -RD] + rend-spec.txt. As in [proposal 220], all signatures are generated not over strings themselves, but over those strings prefixed with a distinguishing @@ -441,13 +439,9 @@ Table of contents: of the hidden service descriptor. The encryption key for these is derived from the service's credential. - In order to make an introduction point send a request to the server, - the client must know the introduction point and know the service's - per-introduction-point authentication key from the hidden service - descriptor. - [XXX what exactly does the intro point check then? Seems like the - intro point should be able to send a cell down the circuit to the - service, even if the service doesn't like the cell. -RD] + In order to make the introduction point send a rendezvous request to the + service, the client needs to use the per-introduction-point authentication + key found in the hidden service descriptor. The final level of access control happens at the server itself, which may decide to respond or not respond to the client's request @@ -523,7 +517,6 @@ Table of contents: compromised, the adversary can only impersonate it for a limited period of time (depending on how many signing keys were generated in advance). - [TODO: Define revocation mechanism?] It's important to not send the private part of the blinded signing key to the Hidden Service since an attacker can derive from it the @@ -754,14 +747,13 @@ Table of contents: Then, for each node listed in the current consensus with the HSDirV3 flag, we compute a directory index for that node as: - hsdir_index(node) = H("node-idx" | node_identity_digest | + hsdir_index(node) = H("node-idx" | node_identity | shared_random_value | INT_8(period_num) ) where shared_random_value is the shared value generated by the authorities - in section [PUB-SHAREDRANDOM], and node_identity_digest is a SHA1 digest of - the node's RSA public key as described in tor-spec.txt. -[XXX Maybe include a sentence about why SHA1 isn't scary here? -RD] + in section [PUB-SHAREDRANDOM], and node_identity is the ed25519 identity key + of the node. Finally, for replicanum in 1...hsdir_n_replicas, the hidden service host uploads descriptors to the first hsdir_spread_store nodes whose @@ -855,10 +847,6 @@ Table of contents: /tor/rendezvous3/<z> where z is a base-64 encoding of the hidden service's blinded public key. - [TODO: raw base64 is not super-nice for URLs, since it can have - slashes. We already use it for microdescriptor URLs, though. Do we - care here?] - These requests must be made anonymously, on circuits not used for anything else. @@ -880,18 +868,15 @@ Table of contents: 2.3.1. Client behavior in the absense of shared random values If the previous or current shared random value cannot be found in a - consensus, then Tor clients need to generate their own random value for use - when choosing HSDirs. + consensus, then Tor clients and services need to generate their own random + value for use when choosing HSDirs. - To do so, clients use: + To do so, Tor clients and services use: SRV = HMAC("shared-random-disaster", TIME_PERIOD_NUM) as the SRV for time period TIME_PERIOD_NUM. -[Ok, this says clients. What do servers do? The same, right? Or should - we let services choose to drop off in the disaster case? -RD] - 2.3.2. Hidden services and changing shared random values It's theoretically possible that the consensus shared random values will @@ -1008,9 +993,7 @@ Table of contents: able to contact the host. Recognized types are: 'password' and 'ed25519'. See [INTRO-AUTH] below. - At least once: -[XXX Why not permit descriptors that list 0 intro points? I think - they're permitted in the legacy rend design. -RD] + Followed by zero or more introduction points as follows: "introduction-point" SP link-specifiers NL @@ -1155,8 +1138,6 @@ Table of contents: cell, first documented in rend-spec.txt. New hidden service hosts must use this format when establishing introduction points at older Tor nodes that do not support the format above in [EST_INTRO]. - [If we roll out intro-point-side support early enough, then service - hosts can simply avoid making intro points to old relays? -RD] In this older protocol, an ESTABLISH_INTRO cell contains: @@ -1372,6 +1353,8 @@ Table of contents: 3.3.2. Example encryption handshake: ntor with extra data [NTOR-WITH-EXTRA-DATA] + [TODO: relocate this] + This is a variant of the ntor handshake (see tor-spec.txt, section 5.1.4; see proposal 216; and see "Anonymity and one-way authentication in key-exchange protocols" by Goldberg, Stebila, and @@ -1544,12 +1527,13 @@ Table of contents: 4.1. Establishing a rendezvous point [EST_REND_POINT] - The client sends the rendezvous point a - RELAY_COMMAND_ESTABLISH_RENDEZVOUS cell containing a 20-byte value. + The client sends the rendezvous point a RELAY_COMMAND_ESTABLISH_RENDEZVOUS + cell containing a 20-byte value. + RENDEZVOUS_COOKIE [20 bytes] Rendezvous points MUST ignore any extra bytes in an - ESTABLISH_RENDEZVOUS message. (Older versions of Tor did not.) + ESTABLISH_RENDEZVOUS cell. (Older versions of Tor did not.) The rendezvous cookie is an arbitrary 20-byte value, chosen randomly by the client. The client SHOULD choose a new rendezvous cookie for @@ -1557,10 +1541,10 @@ Table of contents: use on an existing circuit, the rendezvous point should reject it and destroy the circuit. - Upon receiving an ESTABLISH_RENDEZVOUS cell, the rendezvous point - associates the cookie with the circuit on which it was sent. It - replies to the client with an empty RENDEZVOUS_ESTABLISHED cell to - indicate success. [TODO: make this extensible] + Upon receiving an ESTABLISH_RENDEZVOUS cell, the rendezvous point associates + the cookie with the circuit on which it was sent. It replies to the client + with an empty RENDEZVOUS_ESTABLISHED cell to indicate success. Clients MUST + ignore any extra bytes in a RENDEZVOUS_ESTABLISHED cell. The client MUST NOT use the circuit which sent the cell for any purpose other than rendezvous with the given location-hidden service.

1 0

[torspec/master] prop224: Bump keylen to 2 bytes in all cells.
by asn＠torproject.org 12 May '16

12 May '16

commit 1020c797324e6f8707157f8bca2a6d7f68429b3c Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue May 10 11:10:12 2016 -0400 prop224: Bump keylen to 2 bytes in all cells. --- proposals/224-rend-spec-ng.txt | 21 ++++++--------------- 1 file changed, 6 insertions(+), 15 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 408a982..365f4fd 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1067,7 +1067,7 @@ Table of contents: sends an ESTABLISH_INTRO cell with the following contents: AUTH_KEY_TYPE [1 byte] - AUTH_KEY_LEN [1 byte] + AUTH_KEY_LEN [2 bytes] AUTH_KEY [AUTH_KEY_LEN bytes] N_EXTENSIONS [1 byte] N_EXTENSIONS times: @@ -1075,8 +1075,8 @@ Table of contents: EXT_FIELD_LEN [1 byte] EXT_FIELD [EXT_FIELD_LEN bytes] HANDSHAKE_AUTH [MAC_LEN bytes] - SIGLEN [1 byte] - SIG [SIGLEN bytes] + SIG_LEN [2 bytes] + SIG [SIG_LEN bytes] The AUTH_KEY_TYPE field indicates the type of the introduction point authentication key and the type of the MAC to use in @@ -1100,7 +1100,7 @@ Table of contents: section 5.2, "Setting circuit keys". It prevents replays of ESTABLISH_INTRO cells. - SIGLEN is the length of the signature. + SIG_LEN is the length of the signature. SIG is a signature, using AUTH_KEY, of all contents of the cell, up to but not including SIG. These contents are prefixed with the string @@ -1123,15 +1123,6 @@ Table of contents: Otherwise, the node must associate the key with the circuit, for use later in INTRODUCE1 cells. - [TODO: The above will work fine with what we do today, but it will do - quite badly if we ever freak out and want to go back to RSA2048 or - bigger. Do we care?] - [Do we lose much by making AUTH_KEY_LEN and SIGLEN 2 bytes each? Or, - even crazier, do we lose much by making those two variable sizes, - defined by whichever value of AUTH_KEY_TYPE you pick? I guess we - don't know how big it is if we don't recognize the key type, but we - are already planning to refuse the intro request then. -RD] - 3.1.2. Registering an introduction point on a legacy Tor node [LEGACY_EST_INTRO] Tor nodes should also support an older version of the ESTABLISH_INTRO @@ -1203,7 +1194,7 @@ Table of contents: LEGACY_KEY_ID [20 bytes] AUTH_KEY_TYPE [1 byte] - AUTH_KEY_LEN [1 byte] + AUTH_KEY_LEN [2 bytes] AUTH_KEY [AUTH_KEY_LEN bytes] N_EXTENSIONS [1 byte] N_EXTENSIONS times: @@ -1294,7 +1285,7 @@ Table of contents: EXT_FIELD_LEN [1 byte] EXT_FIELD [EXT_FIELD_LEN bytes] ONION_KEY_TYPE [1 bytes] - ONION_KEY_LEN [1 bytes] + ONION_KEY_LEN [2 bytes] ONION_KEY [ONION_KEY_LEN bytes] NSPEC (Number of link specifiers) [1 byte] NSPEC times:

1 0

[torspec/master] prop224: More improvements.
by asn＠torproject.org 12 May '16

12 May '16

commit 316481f4386428f61a436feefa3a4a11a46890bc Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue May 10 14:15:36 2016 -0400 prop224: More improvements. - Specify credential/subcredential format. - Bump up revision-counter to 64-bits. - Specify descriptor encryption padding. --- proposals/224-rend-spec-ng.txt | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 365f4fd..260036b 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -626,9 +626,17 @@ Table of contents: leaving the hidden service's private key offline. The subcredential for a period is derived as: - H("subcredential" | - credential | - blinded-public-key). + + subcredential = H("subcredential" | credential | blinded-public-key). + + In the above formula, credential corresponds to: + + credential = H(public-identity-key | authorization-key) + + where public-identity-key is the public identity master key of the hidden + service, and authorization-key is an optional secret used for client + authorization. If no client authorization is specified, authorization-key is + left blank. 2.2. Locating, uploading, and downloading hidden service descriptors [HASHRING] @@ -949,7 +957,7 @@ Table of contents: descriptor even if the content of the descriptor hasn't changed. (So that we don't leak whether the intro point list etc. changed) - secret_input = blinded_public_key | subcredential | INT_4(revision_counter) + secret_input = blinded_public_key | subcredential | INT_8(revision_counter) keys = KDF(secret_input, salt, "hsdir-encrypted-data", S_KEY_LEN + S_IV_LEN + MAC_KEY_LEN) @@ -964,14 +972,10 @@ Table of contents: MAC MAC of both above fields [32 bytes] The encryption format is ENCRYPTED = - STREAM(SECRET_IV,SECRET_KEY) xor Plaintext + STREAM(SECRET_IV,SECRET_KEY) XOR Plaintext - Before encryption, the plaintext must be padded to a multiple of ??? - bytes with NUL bytes. The plaintext must not be longer than ??? - bytes. [TODO: how much? Should this be a parameter? What values in - practice are needed to hide how many intro points we have, and how - many might be legacy ones? Note that Single Onion Services add extend - intro points as well. ] + Before encryption, the plaintext must be padded to a multiple of 4096 bytes + with NUL bytes. The plaintext format is: @@ -1007,7 +1011,7 @@ Table of contents: [Exactly once per introduction point] - Base-64 encoded introduction point authentication key that was + Base64 encoded introduction point authentication key that was used to establish introduction point circuit, cross-certifying the blinded public key. This uses the certificate format of proposal 220 with type [09]. The signing-key extension is @@ -1460,7 +1464,7 @@ Table of contents: Hidden services may restrict access only to authorized users. One mechanism to do so is the credential mechanism, where only users who - know the credential for a hidden service may connect at all. For more + know the credentialo for a hidden service may connect at all. For more fine-grained conntrol, a hidden service can be configured with password-based or public-key-based authentication.

1 0

[torspec/master] prop224: Cross-certify all intro keys
by asn＠torproject.org 12 May '16

12 May '16

commit e896dcf2f1e2782c5ba7dc72bdccc39b7f519af1 Author: John Brooks <special(a)torproject.org> Date: Tue May 10 14:24:38 2016 -0400 prop224: Cross-certify all intro keys --- proposals/224-rend-spec-ng.txt | 65 ++++++++++++++++++++++++++---------------- 1 file changed, 40 insertions(+), 25 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 260036b..292ab3f 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -909,14 +909,15 @@ Table of contents: The version-number contains a positive integer indicating the version of the descriptor. Current version is "3". - "descriptor-signing-key-cert" SP certificate NL + "descriptor-signing-key-cert" NL certificate NL [Exactly once.] The 'certificate' field contains a certificate in the format from - proposal 220, with the short-term ed25519 descriptor-signing key - signed by the blinded public key. It must contain a - ed25519-signing-key extension containing the blinded public key. + proposal 220, wrapped with "-----BEGIN ED25519 CERT-----". The + certificate cross-certifies the short-term descriptor signing key with + the blinded public key. The certificate type must be [08], and the + blinded public key must be present as the signing-key extension. "revision-counter" SP Integer NL @@ -944,7 +945,7 @@ Table of contents: [exactly once, at end.] A signature of all previous fields, using the signing key in the - hs-descriptor line. We use a separate key for signing, so that + descriptor-signing-key-cert line. We use a separate key for signing, so that the hidden service host does not need to have its private blinded key online. @@ -1007,37 +1008,49 @@ Table of contents: The link-specifiers is a base64 encoding of a link specifier block in the format described in BUILDING-BLOCKS. - "auth-key" SP "ed25519" SP certificate NL + "auth-key" SP "ed25519" NL certificate NL [Exactly once per introduction point] - Base64 encoded introduction point authentication key that was - used to establish introduction point circuit, cross-certifying - the blinded public key. This uses the certificate format of - proposal 220 with type [09]. The signing-key extension is - mandatory here to tell you what the public key is. + The certificate is a proposal 220 certificate wrapped in + "-----BEGIN ED25519 CERT-----", cross-certifying the descriptor + signing key with the introduction point authentication key, which + is included in the mandatory signing-key extension. The certificate + type must be [09]. - "enc-key" SP "ntor" SP key NL + "enc-key" SP "ntor" SP enc-public-key NL - [At most once per introduction point] + [Exactly one enc-key per introduction point] - Base64-encoded curve25519 key used to encrypt request to - hidden service. - - [TODO: I'd like to have a cross-certification here too.] + The enc-public-key is a base64 encoded curve25519 public key used to + encrypt the introduction request to service. "enc-key" SP "legacy" NL key NL - [At most once per introduction point] + [Exactly one enc-key per introduction point] - Base64-encoded RSA key, wrapped in "----BEGIN RSA PUBLIC + Base64 encoded RSA key, wrapped in "----BEGIN RSA PUBLIC KEY-----" armor, for use with a legacy introduction point as described in [LEGACY_EST_INTRO] and [LEGACY-INTRODUCE1] below. - Exactly one of the "enc-key ntor" and "enc-key legacy" - elements must be present for each introduction point. + "enc-key-certification" NL certificate NL + + [Exactly once per introduction point] + + Cross-certification of the descriptor signing key by the enc-key. + The format of this certificate depends on the type of enc-key. + + For "ntor" keys, certificate is a proposal 220 certificate in + "-----BEGIN ED25519 CERT-----" armor, cross-certifying the descriptor + signing key with the ed25519 equivalent of the curve25519 public key + from "enc-key" derived using the process in proposal 228 appendix A. + The certificate type must be [10], and the signing-key extension is + mandatory. - [TODO: I'd like to have a cross-certification here too.] + For "legacy" keys, certificate is an RSA signature wrapped in + "-----BEGIN SIGNATURE-----" of the digest: + H("legacy introduction point encryption key" | ED25519_KEY) + ED25519_KEY is the 32 byte descriptor signing public key. To remain compatible with future revisions to the descriptor format, clients should ignore unrecognized lines in the descriptor. @@ -1799,10 +1812,12 @@ Appendix E. Reserved numbers We reserve these certificate type values for Ed25519 certificates: - [08] hidden service short-term ed25519 key, signed with blinded + [08] short-term descriptor signing key, signed with blinded public key. (Section 2.4) - [09] intro point authentication key, cross-certifying blinded - public key. (Section 2.5) + [09] intro point authentication key, cross-certifying the descriptor + signing key. (Section 2.5) + [10] ed25519 key derived from the curve25519 intro point encryption key, + cross-certifying the descriptor signing key. (Section 2.5) [XXXX list more]

1 0

[torspec/master] prop224: More trivial fixups.
by asn＠torproject.org 12 May '16

12 May '16

commit f9313163c3f85d7bbb92f90947dfe9021f637c89 Author: John Brooks <special(a)torproject.org> Date: Tue May 10 14:25:21 2016 -0400 prop224: More trivial fixups. - Sectioning fixes --- proposals/224-rend-spec-ng.txt | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 292ab3f..5db0ae3 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1165,12 +1165,9 @@ Table of contents: earlier fields. Older versions of Tor always use a 1024-bit RSA key for these introduction - authentication keys. Newer hidden services MAY use RSA keys up 1904 - bits. Any more than that will not fit in a RELAY cell payload. + authentication keys. -[There is no 3.1.3?] - -3.1.4. Acknowledging establishment of introduction point [INTRO_ESTABLISHED] +3.1.3. Acknowledging establishment of introduction point [INTRO_ESTABLISHED] After setting up an introduction circuit, the introduction point reports its status back to the hidden service host with an INTRO_ESTABLISHED cell. @@ -1183,9 +1180,8 @@ Table of contents: EXT_FIELD_LEN [1 byte] EXT_FIELD [EXT_FIELD_LEN bytes] - [Worth mentioning that old-school Tor relays send back an empty - payload here? Or, even better, not mentioning it if we simplify - 3.1.2 to "don't do that". -RD] + Older versions of Tor send back an empty INTRO_ESTABLISHED cell instead. + Services must accept an empty INTRO_ESTABLISHED cell from a legacy relay. 3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1]

1 0

[torspec/master] prop224: Some proposed fixes mostly discussed with asn
by asn＠torproject.org 12 May '16

12 May '16

commit d94b22560b19861b59570a12eff8e68f122ebf31 Author: David Goulet <dgoulet(a)ev0ke.net> Date: Thu May 12 14:17:44 2016 -0400 prop224: Some proposed fixes mostly discussed with asn Signed-off-by: David Goulet <dgoulet(a)ev0ke.net> --- proposals/224-rend-spec-ng.txt | 151 +++++++++++++++++++++-------------------- 1 file changed, 77 insertions(+), 74 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 5db0ae3..0a673a7 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -6,58 +6,58 @@ Status: Draft Table of contents: - 0. Hidden services: overview and preliminaries. - 0.1. Improvements over previous versions. - 0.2. Notation and vocabulary - 0.3. Cryptographic building blocks - 0.4. Protocol building blocks [BUILDING-BLOCKS] - 0.5. Assigned relay cell types - 0.5. Acknowledgments - 1. Protocol overview - 1.1. View from 10,000 feet - 1.2. In more detail: naming hidden services [NAMING] - 1.3. In more detail: Access control [IMD:AC] - 1.4. In more detail: Distributing hidden service descriptors. [IMD:DIST] - 1.5. In more detail: Scaling to multiple hosts - 1.6. In more detail: Backward compatibility with older hidden service - 1.7. In more detail: Keeping crypto keys offline - 1.8. In more detail: Encryption Keys And Replay Resistance - 1.9. In more detail: A menagerie of keys - 2. Generating and publishing hidden service descriptors [HSDIR] - 2.1. Deriving blinded keys and subcredentials [SUBCRED] - 2.2. Locating, uploading, and downloading hidden service descriptors - 2.2.1. Dividing time into periods [TIME-PERIODS] - 2.2.2. Overlapping time periods to avoid thundering herds [TIME-OVERLAP] - 2.2.3. Where to publish a service descriptor - 2.2.4. Using time periods and SRVs to fetch/upload HS descriptors - 2.2.5. URLs for anonymous uploading and downloading - 2.3. Publishing shared random values [PUB-SHAREDRANDOM] - 2.3.1. Client behavior in the absense of shared random values - 2.3.2. Hidden services and changing shared random values - 2.4. Hidden service descriptors: outer wrapper [DESC-OUTER] - 2.5. Hidden service descriptors: encryption format [ENCRYPTED-DATA] - 3. The introduction protocol - 3.1. Registering an introduction point [REG_INTRO_POINT] - 3.1.1. Extensible ESTABLISH_INTRO protocol. [EST_INTRO] - 3.1.2. Registering an introduction point on a legacy Tor node [LEGACY_EST_INTRO] - 3.1.3. Acknowledging establishment of introduction point [INTRO_ESTABLISHED] - 3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1] - 3.2.1. INTRODUCE1 cell format [FMT_INTRO1] - 3.2.2. Legacy formats [LEGACY-INTRODUCE1] - 3.2.3. INTRODUCE_ACK cell format. [INTRO_ACK] - 3.3. Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2] - 3.3.1. Introduction handshake encryption requirements [INTRO-HANDSHAKE-REQS] - 3.3.2. Example encryption handshake: ntor with extra data [NTOR-WITH-EXTRA-DATA] - 3.4. Authentication during the introduction phase. [INTRO-AUTH] - 3.4.1. Password-based authentication. - 3.4.2. Ed25519-based authentication. - 4. The rendezvous protocol - 4.1. Establishing a rendezvous point [EST_REND_POINT] - 4.2. Joining to a rendezvous point [JOIN_REND] - 4.2.1. Key expansion - 4.3. Using legacy hosts as rendezvous points - 5. Encrypting data between client and host - 6. Open Questions: + 0. Hidden services: overview and preliminaries. + 0.1. Improvements over previous versions. + 0.2. Notation and vocabulary + 0.3. Cryptographic building blocks + 0.4. Protocol building blocks [BUILDING-BLOCKS] + 0.5. Assigned relay cell types + 0.5. Acknowledgments + 1. Protocol overview + 1.1. View from 10,000 feet + 1.2. In more detail: naming hidden services [NAMING] + 1.3. In more detail: Access control [IMD:AC] + 1.4. In more detail: Distributing hidden service descriptors. [IMD:DIST] + 1.5. In more detail: Scaling to multiple hosts + 1.6. In more detail: Backward compatibility with older hidden service + 1.7. In more detail: Keeping crypto keys offline + 1.8. In more detail: Encryption Keys And Replay Resistance + 1.9. In more detail: A menagerie of keys + 2. Generating and publishing hidden service descriptors [HSDIR] + 2.1. Deriving blinded keys and subcredentials [SUBCRED] + 2.2. Locating, uploading, and downloading hidden service descriptors + 2.2.1. Dividing time into periods [TIME-PERIODS] + 2.2.2. Overlapping time periods to avoid thundering herds [TIME-OVERLAP] + 2.2.3. Where to publish a service descriptor + 2.2.4. Using time periods and SRVs to fetch/upload HS descriptors + 2.2.5. URLs for anonymous uploading and downloading + 2.3. Publishing shared random values [PUB-SHAREDRANDOM] + 2.3.1. Client behavior in the absense of shared random values + 2.3.2. Hidden services and changing shared random values + 2.4. Hidden service descriptors: outer wrapper [DESC-OUTER] + 2.5. Hidden service descriptors: encryption format [ENCRYPTED-DATA] + 3. The introduction protocol + 3.1. Registering an introduction point [REG_INTRO_POINT] + 3.1.1. Extensible ESTABLISH_INTRO protocol. [EST_INTRO] + 3.1.2. Registering an introduction point on a legacy Tor node [LEGACY_EST_INTRO] + 3.1.3. Acknowledging establishment of introduction point [INTRO_ESTABLISHED] + 3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1] + 3.2.1. INTRODUCE1 cell format [FMT_INTRO1] + 3.2.2. Legacy formats [LEGACY-INTRODUCE1] + 3.2.3. INTRODUCE_ACK cell format. [INTRO_ACK] + 3.3. Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2] + 3.3.1. Introduction handshake encryption requirements [INTRO-HANDSHAKE-REQS] + 3.3.2. Example encryption handshake: ntor with extra data [NTOR-WITH-EXTRA-DATA] + 3.4. Authentication during the introduction phase. [INTRO-AUTH] + 3.4.1. Password-based authentication. + 3.4.2. Ed25519-based authentication. + 4. The rendezvous protocol + 4.1. Establishing a rendezvous point [EST_REND_POINT] + 4.2. Joining to a rendezvous point [JOIN_REND] + 4.2.1. Key expansion + 4.3. Using legacy hosts as rendezvous points + 5. Encrypting data between client and host + 6. Open Questions: -1. Draft notes @@ -1018,20 +1018,20 @@ Table of contents: is included in the mandatory signing-key extension. The certificate type must be [09]. - "enc-key" SP "ntor" SP enc-public-key NL + Encryption key is specified as follow: - [Exactly one enc-key per introduction point] + [Exactly once enc-key per introduction point] - The enc-public-key is a base64 encoded curve25519 public key used to - encrypt the introduction request to service. + "enc-key" SP "ntor" SP key NL - "enc-key" SP "legacy" NL key NL + The key is a base64 encoded curve25519 public key used to encrypt + the introduction request to service. - [Exactly one enc-key per introduction point] + "enc-key" SP "legacy" NL key NL - Base64 encoded RSA key, wrapped in "----BEGIN RSA PUBLIC - KEY-----" armor, for use with a legacy introduction point as - described in [LEGACY_EST_INTRO] and [LEGACY-INTRODUCE1] below. + Base64 encoded RSA key, wrapped in "----BEGIN RSA PUBLIC + KEY-----" armor, for use with a legacy introduction point as + described in [LEGACY_EST_INTRO] and [LEGACY-INTRODUCE1] below. "enc-key-certification" NL certificate NL @@ -1041,11 +1041,11 @@ Table of contents: The format of this certificate depends on the type of enc-key. For "ntor" keys, certificate is a proposal 220 certificate in - "-----BEGIN ED25519 CERT-----" armor, cross-certifying the descriptor - signing key with the ed25519 equivalent of the curve25519 public key - from "enc-key" derived using the process in proposal 228 appendix A. - The certificate type must be [10], and the signing-key extension is - mandatory. + "-----BEGIN ED25519 CERT-----" armor, cross-certifying the + descriptor signing key with the ed25519 equivalent of the curve25519 + public key from "enc-key" derived using the process in proposal 228 + appendix A. The certificate type must be [10], and the signing-key + extension is mandatory. For "legacy" keys, certificate is an RSA signature wrapped in "-----BEGIN SIGNATURE-----" of the digest: @@ -1201,9 +1201,13 @@ Table of contents: the client, either informing it that its request has been delivered, or that its request will not succeed. + [TODO: specify what tor should do when receiving a malformed cell. Drop it? + Kill circuit? This goes for all possible cells.] + 3.2.1. INTRODUCE1 cell format [FMT_INTRO1] - An INTRODUCE1 cell has the following contents: + When a client is connecting to an introduction point, INTRODUCE1 cells + should be of the form: LEGACY_KEY_ID [20 bytes] AUTH_KEY_TYPE [1 byte] @@ -1220,7 +1224,7 @@ Table of contents: INTRODUCE1 cells. In new style INTRODUCE1 cells, LEGACY_KEY_ID is 20 zero bytes. Upon receiving an INTRODUCE1 cell, the introduction point checks the LEGACY_KEY_ID field. If LEGACY_KEY_ID is non-zero, the INTRODUCE1 cell - should be handled as specified in rend-spec.txt. + should be handled as specified in [LEGACY-INTRODUCE1]. AUTH_KEY_TYPE is defined as in [EST_INTRO]. Currently, the only value of AUTH_KEY_TYPE for this cell is an Ed25519 public key [02]. @@ -1233,10 +1237,9 @@ Table of contents: 3.2.2. Legacy formats [LEGACY-INTRODUCE1] - When a client is using a legacy introduction point, INTRODUCE1 cells should - be of the form: + For legacy introduction points, INTRODUCE1 cells should be of the form: - LEGACY_KEYID_HASH [20 bytes] + LEGACY_KEY_ID [20 bytes] N_EXTENSIONS [1 byte] N_EXTENSIONS times: EXT_FIELD_TYPE [1 byte] @@ -1244,7 +1247,7 @@ Table of contents: EXT_FIELD [EXT_FIELD_LEN bytes] ENCRYPTED [Up to end of relay payload] - Here, LEGACY_KEYID_HASH is the hash of the introduction point legacy + Here, LEGACY_KEY_ID is the hash of the introduction point legacy encryption key that was included in the hidden service descriptor. Because of limitations in older versions of Tor, the relay payload size for @@ -1271,7 +1274,7 @@ Table of contents: 3.3. Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2] Upon receiving an INTRODUCE2 cell, the hidden service host checks whether - the AUTH_KEY or LEGACY_KEYID_HASH field matches the keys for this + the AUTH_KEY or LEGACY_KEY_ID field matches the keys for this introduction circuit. The service host then checks whether it has received a cell with @@ -1473,7 +1476,7 @@ Table of contents: Hidden services may restrict access only to authorized users. One mechanism to do so is the credential mechanism, where only users who - know the credentialo for a hidden service may connect at all. For more + know the credential for a hidden service may connect at all. For more fine-grained conntrol, a hidden service can be configured with password-based or public-key-based authentication.

1 0

[torspec/master] prop250: Add the Version field to a commit
by dgoulet＠torproject.org 12 May '16

12 May '16

commit 6945958d997401511fc6dcd36c4e37a6233f2a11 Author: David Goulet <dgoulet(a)ev0ke.net> Date: Thu May 12 13:43:47 2016 -0400 prop250: Add the Version field to a commit Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- proposals/250-commit-reveal-consensus.txt | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/proposals/250-commit-reveal-consensus.txt b/proposals/250-commit-reveal-consensus.txt index cd19b4c..0e7675e 100644 --- a/proposals/250-commit-reveal-consensus.txt +++ b/proposals/250-commit-reveal-consensus.txt @@ -423,14 +423,15 @@ Supersedes: 225 seen from the other authorities. To do so, it includes the following in its votes: - "shared-rand-commit" SP ALGNAME SP IDENTITY SP COMMIT [SP REVEAL] NL + "shared-rand-commit" SP VERSION SP ALGNAME SP IDENTITY SP COMMIT [SP REVEAL] NL - where IDENTITY is the authority's SHA1 identity fingerprint and COMMIT is the - encoded commit [COMMITREVEAL]. Authorities during the reveal phase can also - optionally include an encoded reveal value REVEAL. There MUST be only one - line per authority else the vote is considered invalid. Finally, the ALGNAME - is the hash algorithm that should be used to compute COMMIT and REVEAL which - is "sha3-256" for version 1. + where VERSION is the version of the protocol the commit was created with. + IDENTITY is the authority's SHA1 identity fingerprint and COMMIT is the + encoded commit [COMMITREVEAL]. Authorities during the reveal phase can + also optionally include an encoded reveal value REVEAL. There MUST be only + one line per authority else the vote is considered invalid. Finally, the + ALGNAME is the hash algorithm that should be used to compute COMMIT and + REVEAL which is "sha3-256" for version 1. 4.1.5. Shared Random Value [SRVOTE] @@ -481,7 +482,7 @@ Supersedes: 225 The following details the commitment and reveal section. They are encoded the same as in the vote. This makes it easier for implementation purposes. - "Commit" SP algname SP identity SP commit [SP reveal] NL + "Commit" SP version SP algname SP identity SP commit [SP reveal] NL [Exactly once per authority]

1 0