- tor-commits - lists.torproject.org

[torspec/master] prop224: Minor fixes to descriptor format
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit fdd5cc01bcb3c02901c51e3bd9f5812e4066c43b Author: John Brooks <special(a)torproject.org> Date: Thu Mar 10 19:25:45 2016 +0100 prop224: Minor fixes to descriptor format --- proposals/224-rend-spec-ng.txt | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index f7a4304..78b2071 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -942,11 +942,14 @@ Status: Draft The encrypted part of the hidden service descriptor is encrypted and authenticated with symmetric keys generated as follows: - salt = 16 random bytes, different for each post to each replica, + SALT = 16 bytes from H(random), different for each post to each replica, even if the content of the descriptor hasn't changed. (This avoids leaking service stability, and linking replicas via encrypted data comparison.) + (We hash salt so that we don't leak the raw bytes returned by a PRNG + to the network. See [RANDOM-REFS].) + [ XX/teor - is the extra load on the HSDirs worth it? ] secret_input = blinded_public_key(replica-keynum) | @@ -960,13 +963,10 @@ Status: Draft The encrypted data has the format: - H(SALT) H(random bytes from above) [16 bytes] + SALT hashed random bytes from above [16 bytes] ENCRYPTED The plaintext encrypted with S [variable] MAC MAC of both above fields [32 bytes] - (We hash salt so that we don't leak the raw bytes returned by a PRNG - to the network. See [RANDOM-REFS].) - The encryption format is ENCRYPTED = STREAM(SECRET_IV,SECRET_KEY) xor Plaintext @@ -1040,6 +1040,8 @@ Status: Draft [TODO: I'd like to have a cross-certification here too.] + To remain compatible with future revisions to the descriptor format, + clients should ignore unrecognized lines in the descriptor. Other encryption and authentication key formats are allowed; clients should ignore ones they do not recognize.

1 0

[torspec/master] prop224: Some syntax fixes and remove time-period
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit 68c654d37aaa4c3f9e87b6639c95509715369367 Author: David Goulet <dgoulet(a)ev0ke.net> Date: Thu Mar 10 09:50:41 2016 -0500 prop224: Some syntax fixes and remove time-period Signed-off-by: David Goulet <dgoulet(a)ev0ke.net> --- proposals/224-rend-spec-ng.txt | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 8dd30b0..f7a4304 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -839,23 +839,19 @@ Status: Draft The format for a hidden service descriptor is as follows, using the meta-format from dir-spec.txt. - "hs-descriptor" SP "3" certificate NL + "hs-descriptor" SP version-number SP certificate NL [At start, exactly once.] + The version-number contains a positive integer indicating the version + of the descriptor. Current version is "3". + The 'certificate' field contains a certificate in the format from proposal 220, with the short-term ed25519 descriptor-signing key for the replica, signed by the blinded public key for the replica. It must contain a ed25519-signing-key extension containing the blinded public key for the replica. - "time-period" SP YYYY-MM-DD HH:MM:SS NUM NL - - [Exactly once.] - - The time period for which this descriptor is relevant, including - its starting time and its period number. - "revision-counter" SP Integer NL [Exactly once.] @@ -987,10 +983,10 @@ Status: Draft [Exactly once] - A space-separated list of integers denoting CREATE2 cell format - numbers that the server recognizes. Must include at least TAP and - ntor as described in tor-spec.txt. See tor-spec section 5.1 for a - list of recognized handshake types. + A space-separated list of integers denoting CREATE2 cell format numbers + that the server recognizes. Must include at least ntor as described in + tor-spec.txt. See tor-spec section 5.1 for a list of recognized + handshake types. "authentication-required" SP types NL @@ -1011,7 +1007,7 @@ Status: Draft The link-specifiers is a base64 encoding of a link specifier block in the format described in BUILDING-BLOCKS. - "auth-key" SP "ed25519" certificate NL + "auth-key" SP "ed25519" SP certificate NL [Exactly once per introduction point]

1 0

[torspec/master] prop224: In cells, replace TYPE/LEN/KEY with just TYPE/KEY.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit 83a62b6e0f31dcb8fbe917ac9d406b78193605b7 Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Mar 15 15:28:25 2016 +0200 prop224: In cells, replace TYPE/LEN/KEY with just TYPE/KEY. --- proposals/224-rend-spec-ng.txt | 45 +++++++++++++++++++++++++++--------------- 1 file changed, 29 insertions(+), 16 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index dd76e36..d80b2d5 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -153,6 +153,18 @@ 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] @@ -1182,14 +1194,11 @@ Status: Draft NUMKEYS [1 byte] NUMKEYS times: KEYTYPE [1 byte] - KEYLEN [1 byte] - KEY [KEYLEN bytes] + KEY [depends on KEYTYPE] COUNTER [4 bytes] SIGLEN [1 byte] SIGNATURE [SIGLEN bytes.] - The KEYTYPE value [01] is for Curve25519 keys. - The COUNTER field is a monotonically increasing value across a given introduction point authentication key. @@ -1252,9 +1261,11 @@ Status: Draft An INTRODUCE1 cell has the following contents: - AUTH_KEYID [32 bytes] - ENC_KEYID [8 bytes] - N_EXTENSIONS [1 Byte] + AUTH_KEYTYPE [1 byte] + AUTH_KEYID [depends on AUTH_KEYTYPE] + ENC_KEYTYPE [1 byte] + ENC_KEYID [depends on ENC_KEYTYPE] + N_EXTENSIONS [1 byte] N_EXTENSIONS times: EXT_FIELD_TYPE [1 byte] EXT_FIELD_LEN [1 byte] @@ -1275,12 +1286,12 @@ Status: Draft running whose PK_ID is the first 20 bytes of AUTH_KEYID. If so, it behaves as in rend-spec.txt.) - The AUTH_KEYID for an Ed25519 public key is the public key itself. - The ENC_KEYID for a Curve25519 public key is the first 8 bytes of the - public key. (This key ID 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 ENCRYPTED field is as - described in 3.3 below. + The AUTH_KEYTYPE is an Ed25519 public key (value [01]). + + The ENC_KEYTYPE 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 + ENCRYPTED field is as described in 3.3 below. To relay an INTRODUCE1 cell, the introduction point sends an INTRODUCE2 cell with exactly the same contents. @@ -1360,7 +1371,7 @@ Status: Draft EXT_FIELD_TYPE [1 byte] EXT_FIELD_LEN [1 byte] EXT_FIELD [EXT_FIELD_LEN bytes] - ONION_KEY_TYPE [2 bytes] + ONION_KEY_TYPE [1 bytes] ONION_KEY [depends on ONION_KEY_TYPE] NSPEC (Number of link specifiers) [1 byte] NSPEC times: @@ -1458,8 +1469,10 @@ Status: Draft Substituting those fields into the INTRODUCE1 cell body format described in [FMT_INTRO1] above, we have - AUTH_KEYID [32 bytes] - ENC_KEYID [8 bytes] + AUTH_KEYTYPE [1 byte] + AUTH_KEYID [depends on AUTH_KEYTYPE] + ENC_KEYTYPE [1 byte] + ENC_KEYID [depends on ENC_KEYTYPE] N_EXTENSIONS [1 bytes] N_EXTENSIONS times: EXT_FIELD_TYPE [1 byte]

1 0

[torspec/master] prop224: Clarify use of shared random values.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit 2b8a0103b9f36a0b834ce1bde6608557fe10f866 Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Jan 5 16:28:11 2016 +0200 prop224: Clarify use of shared random values. --- proposals/224-rend-spec-ng.txt | 48 +++++++++++++++++++++--------------------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 8e14e2a..aee91bf 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -797,35 +797,36 @@ Status: Draft to generate such a value at least once per hsdir period. Here we describe how they publish these values; the procedure they use to generate them can change independently of the rest of this - specification. For one possible (somewhat broken) protocol, see - Appendix [SHAREDRANDOM]. + specification. For more information see [SHAREDRANDOM-REFS]. - We add a new line in votes and consensus documents: + According to proposal 250, we add two new lines in consensuses: - "hsdir-shared-random" PERIOD-START VALUE - PERIOD-START = YYYY-MM-DD HH:MM:SS - VALUE = A base-64 encoded 256-bit value. + "shared-rand-previous-value" SP NUM_REVEALS SP VALUE NL + "shared-rand-current-value" SP NUM_REVEALS SP VALUE NL - To decide which hsdir-shared-random line to include in a consensus - for a given PERIOD-START, we choose whichever line appears verbatim - in the most votes, so long as it is listed by at least three - authorities. Ties are broken in favor of the lower value. More than - one PERIOD-START is allowed per vote, and per consensus. The same - PERIOD-START must not appear twice in a vote or in a consensus. +2.3.1. Client behavior in the absense of shared random values - [TODO: Need to define a more robust algorithm. Need to cover cases - where multiple cluster of authorities publish a different value, - etc.] + 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. - The hs-dir-shared-random lines appear, sorted by PERIOD-START, in the - consensus immediately after the "params" line. + To do so, clients use: - The authorities should publish the shared random value for the - current period, and, at a time at least three voting periods before - the overlap interval begins, the shared random value for the next - period. + SRV = HMAC("shared-random-disaster", TIME_PERIOD_NUM) + + as the SRV for time period TIME_PERIOD_NUM. + +2.3.2. Hidden services and changing shared random values + + It's theoretically possible that the consensus shared random values will + change or disappear in the middle of a time period because of directory + authorities dropping offline or misbehaving. + + To avoid client reachability issues in this rare event, hidden services + should use the new shared random values to find the new responsible HSDirs + and upload their descriptors there. -[TODO: find out what weasel doesn't like here.] + XXX How long should they upload descriptors there for? 2.4. Hidden service descriptors: outer wrapper [DESC-OUTER] @@ -1705,9 +1706,8 @@ References: https://lists.torproject.org/pipermail/tor-dev/2013-December/005943.html [SHAREDRANDOM-REFS]: + https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-… https://trac.torproject.org/projects/tor/ticket/8244 - https://lists.torproject.org/pipermail/tor-dev/2013-November/005847.html - https://lists.torproject.org/pipermail/tor-talk/2013-November/031230.html [SCALING-REFS]: https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html

1 0

[torspec/master] prop224: Various improvements.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit 397244ffecd091b841307c710aa8f8c3d6483818 Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Mar 15 14:02:28 2016 +0200 prop224: Various improvements. - Kill last remnants of TAP from the proposal. - Replace SHA256 with SHA3-256 and our KDF with SHAKE. - Make the INTRO_ESTABLISHED cell extensible. - Improve the descriptor format a bit. - Don't be ambiguous about "INTRODUCE" cells (pointed out by malekbr). - Cleanup the scaling section. --- proposals/224-rend-spec-ng.txt | 91 ++++++++++++++++-------------------------- 1 file changed, 35 insertions(+), 56 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 78b2071..dd76e36 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -137,11 +137,11 @@ Status: Draft * Instantiate PK with Curve25519. - * Instantiate H with SHA256. [TODO: really?] + * Instantiate H with SHA3-256. - * Instantiate MAC with HMAC using H. + * Instantiate MAC(key=k, message=m) with H(k || m). - * Instantiate KDF with HKDF using H. + * Instantiate KDF with HKDF using SHAKE-256. For legacy purposes, we specify compatibility with older versions of the Tor introduction point and rendezvous point protocols. These used @@ -431,31 +431,12 @@ Status: Draft 1.5. In more detail: Scaling to multiple hosts - [THIS SECTION IS UNFINISHED] - - In order to allow multiple hosts to provide a single hidden service, - I'm considering two options. - - * We can have each server build an introduction circuit to each - introduction point, and have the introduction points responsible - for round-robining between these circuits. One service host is - responsible for picking the introduction points and publishing - the descriptors. - - * We can have servers choose their introduction points - independently, and build circuits to them. One service host is - responsible for combining these introduction points into a - single descriptor. - - If we want to avoid having a single "master" host without which the - whole service goes down (the "one service host" in the description - above), we need a way to fail over from one host to another. We also - need a way to coordinate between the hosts. This is as yet - undesigned. Maybe it should use a hidden service? - - See [SCALING-REFS] for discussion on this topic. - - [TODO: Finalize this design.] + This design is compatible with our current approaches for scaling hidden + services. Specifically, hidden service operators can use onionbalance to + achieve high availability between multiple nodes on the HSDir + layer. Furthermore, operators can use proposal 255 to load balance their + hidden services on the introduction layer. See [SCALING-REFS] for further + discussions on this topic and alternative designs. 1.6. In more detail: Backward compatibility with older hidden service protocols @@ -839,13 +820,17 @@ Status: Draft The format for a hidden service descriptor is as follows, using the meta-format from dir-spec.txt. - "hs-descriptor" SP version-number SP certificate NL + "hs-descriptor" SP version-number NL [At start, exactly once.] The version-number contains a positive integer indicating the version of the descriptor. Current version is "3". + "descriptor-signing-key-cert" SP certificate NL + + [Exactly once.] + The 'certificate' field contains a certificate in the format from proposal 220, with the short-term ed25519 descriptor-signing key for the replica, signed by the blinded public key for the replica. @@ -1089,7 +1074,7 @@ Status: Draft [00, 01] -- Reserved for legacy introduction cells; see [LEGACY_EST_INTRO below] - [02] -- Ed25519; HMAC-SHA256. + [02] -- Ed25519; SHA3-256. [FF] -- Reserved for maintenance messages on existing circuits; see MAINT_INTRO below. @@ -1155,22 +1140,14 @@ Status: Draft The KEY field is a ASN1-encoded RSA public key. - The HANDSHAKE_AUTH field contains the SHA1 digest of (KH | - "INTRODUCE"). + The HANDSHAKE_AUTH field contains the SHA1 digest of (KH | "INTRODUCE"). The SIG field contains an RSA signature, using PKCS1 padding, of all earlier fields. - Note that since the relay payload itself may be no more than 498 - bytes long, the KEY_LEN field can never have a first byte other - than [00] or [01]. These values are used to distinguish legacy - ESTABLISH_INTRO cells from newer ones. - - 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. + 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. 3.1.3. Managing introduction circuits [MAINT_INTRO] @@ -1242,12 +1219,16 @@ Status: Draft 3.1.4. 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 empty - INTRO_ESTABLISHED cell. + After setting up an introduction circuit, the introduction point reports its + status back to the hidden service host with an INTRO_ESTABLISHED cell. + + The INTRO_ESTABLISHED cell has the following contents: - [TODO: make this cell type extensible. It should be able to include - data if that turns out to be needed.] + N_EXTENSIONS [1 byte] + N_EXTENSIONS times: + EXT_FIELD_TYPE [1 byte] + EXT_FIELD_LEN [1 byte] + EXT_FIELD [EXT_FIELD_LEN bytes] 3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1] @@ -1400,10 +1381,9 @@ Status: Draft doesn't recognize; instead, it should use them verbatim in its EXTEND request to the rendezvous point. - The ONION_KEY_TYPE field is one of: + The ONION_KEY_TYPE field is: - [01] TAP-RSA-1024: ONION_KEY is 128 bytes long. - [02] NTOR: ONION_KEY is 32 bytes long. + [01] NTOR: ONION_KEY is 32 bytes long. The ONION_KEY field describes the onion key that must be used when extending to the rendezvous point. It must be of a type listed as @@ -1450,14 +1430,13 @@ Status: Draft Notation here is as in section 5.1.4 of tor-spec.txt, which defines the ntor handshake. - The PROTOID for this variant is - "hidden-service-ntor-curve25519-sha256-1". Define the tweak value - t_hsenc, and the tag value m_hsexpand as: + The PROTOID for this variant is "tor-hs-ntor-curve25519-sha3-256-1". + We also use the following tweak values: t_hsenc = PROTOID | ":hs_key_extract" m_hsexpand = PROTOID | ":hs_key_expand" - To make an INTRODUCE cell, the client must know a public encryption + To make an INTRODUCE1 cell, the client must know a public encryption key B for the hidden service on this introduction circuit. The client generates a single-use keypair: x,X = KEYGEN() @@ -1560,7 +1539,7 @@ Status: Draft 3.4.1. Password-based authentication. To authenticate with a password, the user must include an extension - field in the encrypted part of the INTRODUCE cell with an + field in the encrypted part of the INTRODUCE1 cell with an EXT_FIELD_TYPE type of [01] and the contents: Username [00] Password. @@ -1573,7 +1552,7 @@ Status: Draft 3.4.2. Ed25519-based authentication. To authenticate with an Ed25519 private key, the user must include an - extension field in the encrypted part of the INTRODUCE cell with an + extension field in the encrypted part of the INTRODUCE1 cell with an EXT_FIELD_TYPE type of [02] and the contents: Nonce [16 bytes]

1 0

[torspec/master] prop224: Fix undefined variables in the ntor section.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit 191e93cc6e0a126006c61b3eb3f46f4491c6a6af Author: George Kadianakis <desnacked(a)riseup.net> Date: Fri Apr 8 19:15:14 2016 +0300 prop224: Fix undefined variables in the ntor section. --- proposals/224-rend-spec-ng.txt | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index d80b2d5..8e14e2a 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1445,6 +1445,8 @@ Status: Draft We also use the following tweak values: t_hsenc = PROTOID | ":hs_key_extract" + t_hsverify = PROTOID | ":hs_verify" + t_hsmac = PROTOID | ":hs_mac" m_hsexpand = PROTOID | ":hs_key_expand" To make an INTRODUCE1 cell, the client must know a public encryption @@ -1454,8 +1456,7 @@ Status: Draft and computes: secret_hs_input = EXP(B,x) | AUTH_KEYID | X | B | PROTOID info = m_hsexpand | subcredential - hs_keys = HKDF(secret_hs_input, t_hsenc, info, - S_KEY_LEN+MAC_LEN) + hs_keys = HKDF(secret_hs_input, t_hsenc, info, S_KEY_LEN+MAC_LEN) ENC_KEY = hs_keys[0:S_KEY_LEN] MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN] @@ -1510,31 +1511,28 @@ Status: Draft service host generates a keypair of y,Y = KEYGEN(), and uses its introduction point encryption key 'b' to computes: - xb = EXP(X,b) - - secret_hs_input = xb | AUTH_KEYID | X | B | PROTOID + secret_hs_input = EXP(X,b) | AUTH_KEYID | X | B | PROTOID info = m_hsexpand | subcredential - hs_keys = HKDF(secret_hs_input, t_hsenc, info, - S_KEY_LEN+MAC_LEN) + hs_keys = HKDF(secret_hs_input, t_hsenc, info, S_KEY_LEN+MAC_LEN) HS_DEC_KEY = hs_keys[0:S_KEY_LEN] HS_MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN] (The above are used to check the MAC and then decrypt the encrypted data.) - ntor_secret_input = EXP(X,y) | xb | ID | B | X | Y | PROTOID - NTOR_KEY_SEED = H(secret_input, t_key) - verify = H(secret_input, t_verify) - auth_input = verify | ID | B | Y | X | PROTOID | "Server" + ntor_secret_input = EXP(X,y) | EXP(X,b) | AUTH_KEYID | B | X | Y | PROTOID + NTOR_KEY_SEED = MAC(ntor_secret_input, t_hsenc) + verify = MAC(ntor_secret_input, t_hsverify) + auth_input = verify | AUTH_KEYID | B | Y | X | PROTOID | "Server" (The above are used to finish the ntor handshake.) The server's handshake reply is: - SERVER_PK Y [G_LEN bytes] - AUTH H(auth_input, t_mac) [H_LEN bytes] + SERVER_PK Y [G_LEN bytes] + AUTH MAC(auth_input, t_hsmac) [H_LEN bytes] - These faileds can be send to the client in a RENDEZVOUS1 cell. - (See [JOIN_REND] below.) + These fields will be sent to the client in a RENDEZVOUS1 cell using the + HANDSHAKE_INFO element (see [JOIN_REND]). The hidden service host now also knows the keys generated by the handshake, which it will use to encrypt and authenticate data @@ -1578,7 +1576,7 @@ Status: Draft to authenticate. [TODO: should this be an identifier for the public key instead?] Signature is the signature, using Ed25519, of: - "Hidserv-userauth-ed25519" + "hidserv-userauth-ed25519" Nonce (same as above) Pubkey (same as above) AUTH_KEYID (As in the INTRODUCE1 cell) @@ -1653,6 +1651,8 @@ Status: Draft HANDSHAKE_INFO correctly completes a handshake, and uses the handshake output to derive shared keys for use on the circuit. + [TODO: How do we derive shared keys exactly? How do we use NTOR_KEY_SEED?] + [TODO: Should we encrypt HANDSHAKE_INFO as we did INTRODUCE2 contents? It's not necessary, but it could be wise. Similarly, we should make it extensible.]

1 0

[torspec/master] prop224: Add missing key expansion section for rendezvous crypto.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit 65f186e80c6ee425c2e9cf479cdf6ca66c51a337 Author: George Kadianakis <desnacked(a)riseup.net> Date: Fri Mar 18 12:10:35 2016 +0200 prop224: Add missing key expansion section for rendezvous crypto. --- proposals/224-rend-spec-ng.txt | 37 +++++++++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index aee91bf..51d6ea4 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1144,7 +1144,7 @@ Status: Draft In this older protocol, an ESTABLISH_INTRO cell contains: - KEY_LEN [2 bytes] + KEY_LEN [2 bytes] KEY [KEY_LEN bytes] HANDSHAKE_AUTH [20 bytes] SIG [variable, up to end of relay payload] @@ -1649,10 +1649,39 @@ Status: Draft client containing the contents of the RENDEZVOUS1 cell. Upon receiving the RENDEZVOUS2 cell, the client verifies that the - HANDSHAKE_INFO correctly completes a handshake, and uses the - handshake output to derive shared keys for use on the circuit. + HANDSHAKE_INFO correctly completes a handshake. Now both parties use the + handshake output to derive shared keys for use on the circuit as specified + in the section below: - [TODO: How do we derive shared keys exactly? How do we use NTOR_KEY_SEED?] +4.2.1. Key expansion + + The hidden service and its client need to derive crypto keys from the + NTOR_KEY_SEED part of the handshake output. To do so, they use the key + expansion construction specified in prop216: + + K = K_1 | K_2 | K_3 | ... + + Where K_1 = MAC(NTOR_KEY_SEED, m_hsexpand | INT8(1)) + and K_(i+1) = MAC(NTOR_KEY_SEED, K_i | m_hsexpand | INT8(i)) + and INT8(i) is a octet with the value "i". + + + The key material is then used to generate KH, Df, Db, Kf, and Kb as in the + KDF-TOR key derivation approach documented in tor-spec.txt: + + The first HASH_LEN bytes of K form KH; the next HASH_LEN form the forward + digest Df; the next HASH_LEN 41-60 form the backward digest Db; the next + KEY_LEN 61-76 form Kf, and the final KEY_LEN form Kb. Excess bytes from K + are discarded. + + Subsequently, the rendezvous point passes relay cells, unchanged, from each + of the two circuits to the other. When Alice's OP sends RELAY cells along + the circuit, it authenticates with Df, and encrypts them with the Kf, then + with all of the keys for the ORs in Alice's side of the circuit; and when + Alice's OP receives RELAY cells from the circuit, it decrypts them with the + keys for the ORs in Alice's side of the circuit, then decrypts them with Kb, + and checks integrity with Db. Bob's OP does the same, with Kf and Kb + interchanged. [TODO: Should we encrypt HANDSHAKE_INFO as we did INTRODUCE2 contents? It's not necessary, but it could be wise. Similarly, we

1 0

[torspec/master] prop224: Clarify backwards compatibility sections slightly.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit dd7933d8158cefff2ecf0e325b21ac22aed49978 Author: George Kadianakis <desnacked(a)riseup.net> Date: Fri Apr 8 19:15:34 2016 +0300 prop224: Clarify backwards compatibility sections slightly. --- proposals/224-rend-spec-ng.txt | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 51d6ea4..b3a567c 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1151,7 +1151,8 @@ Status: Draft The KEY_LEN variable determines the length of the KEY field. - The KEY field is a ASN1-encoded RSA public key. + The KEY field is the ASN1-encoded legacy RSA public key that was also + included in the hidden service descriptor. The HANDSHAKE_AUTH field contains the SHA1 digest of (KH | "INTRODUCE"). @@ -1323,24 +1324,24 @@ Status: Draft 3.2.3. Legacy formats [LEGACY-INTRODUCE1] - When the ESTABLISH_INTRO cell format of [LEGACY_EST_INTRO] is used, - INTRODUCE1 cells are of the form: + If a hidden service has listed a legacy introduction point in its + descriptor, INTRODUCE1 cells should be of the form: - AUTH_KEYID_HASH [20 bytes] - ENC_KEYID [8 bytes] - - EXT_FIELD_TYPE [1 byte] - EXT_FIELD_LEN [1 byte] - EXT_FIELD [EXT_FIELD_LEN bytes] - - ENCRYPTED [Up to end of relay payload] + 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, AUTH_KEYID_HASH is the hash of the introduction point - authentication key used to establish the introduction. + 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. + 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?] 3.3. Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2]

1 0

[torspec/master] prop224: Remove the MAINT_INTRO feature.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit 76b26c5dd46a633136e9d811125d91049b1b40a8 Author: George Kadianakis <desnacked(a)riseup.net> Date: Mon Apr 4 12:50:59 2016 +0300 prop224: Remove the MAINT_INTRO feature. Too complex and not sufficient gain. For full rationale, please see thread: https://lists.torproject.org/pipermail/tor-dev/2016-March/010560.html --- proposals/224-rend-spec-ng.txt | 79 +----------------------------------------- 1 file changed, 1 insertion(+), 78 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index b3a567c..833224b 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1088,11 +1088,6 @@ Status: Draft [00, 01] -- Reserved for legacy introduction cells; see [LEGACY_EST_INTRO below] [02] -- Ed25519; SHA3-256. - [FF] -- Reserved for maintenance messages on existing - circuits; see MAINT_INTRO below. - - [TODO: Should this just be a new relay cell type? - Matthew and George think so.] The AUTH_KEY_LEN field determines the length of the AUTH_KEY field. The AUTH_KEY field contains the public introduction point @@ -1163,71 +1158,6 @@ Status: Draft authentication keys. Newer hidden services MAY use RSA keys up 1904 bits. Any more than that will not fit in a RELAY cell payload. -3.1.3. Managing introduction circuits [MAINT_INTRO] - - If the first byte of an ESTABLISH_INTRO cell is [FF], the cell's body - contains an administrative command for the circuit. The format of - such a command is: - - Any number of times: - SUBCOMMAND_TYPE [2 bytes] - SUBCOMMAND_LEN [2 bytes] - SUBCOMMAND [COMMAND_LEN bytes] - - Recognized SUBCOMMAND_TYPE values are: - - [00 01] -- update encryption keys - - [TODO: Matthew says, "This can be used to fork an intro point to - balance traffic over multiple hidden service servers while - maintaining the criteria for a valid ESTABLISH_INTRO - cell. -MF". Investigate.] - - Unrecognized SUBCOMMAND_TYPE values should be ignored. - -3.1.3.1. Updating encryption keys (subcommand 0001) [UPDATE-KEYS-SUBCMD] - - Hidden service hosts send this subcommand to set their initial - encryption keys or update the configured public encryption keys - associated with this circuit. This message must be sent after - establishing an introduction point, before the circuit can be - advertised. These keys are given in the form: - - NUMKEYS [1 byte] - NUMKEYS times: - KEYTYPE [1 byte] - KEY [depends on KEYTYPE] - COUNTER [4 bytes] - SIGLEN [1 byte] - SIGNATURE [SIGLEN bytes.] - - The COUNTER field is a monotonically increasing value across a given - introduction point authentication key. - - The SIGNATURE must be generated with the introduction point - authentication key, and must cover the entire subcommand body, - prefixed with the string "Tor hidden service introduction encryption - keys v1". - - [TODO: Nothing is done here to prove ownership of the encryption - keys. Does that matter?] - - [TODO: The point here is to allow encryption keys to change while - maintaining an introduction point and not forcing a client to - download a new descriptor. I'm not sure if that's worth it. It makes - clients who have seen a key before distinguishable from ones who have - not.] - - [Matthew says: "Repeat-client over long periods of time will always - be distinguishable. It may be better to simply expire intro points - than try to preserve forward-secrecy, though". Must find out what he - meant.] - - Setting the encryption keys for a given circuit replaces the previous - keys for that circuit. Clients who attempt to connect using the old - key receive an INTRO_ACK cell with error code [00 02] as described in - section [INTRO_ACK] below. - 3.1.4. Acknowledging establishment of introduction point [INTRO_ESTABLISHED] After setting up an introduction circuit, the introduction point reports its @@ -1301,6 +1231,7 @@ Status: Draft 3.2.2. INTRODUCE_ACK cell format. [INTRO_ACK] An INTRODUCE_ACK cell has the following fields: + STATUS [2 bytes] N_EXTENSIONS [1 bytes] N_EXTENSIONS times: @@ -1314,14 +1245,6 @@ Status: Draft [00 02] -- Failure: key ID not recognized [00 03] -- Bad message format - Recognized extension field types: - [00 01] -- signed set of encryption keys - - The extension field type 0001 is a signed set of encryption keys; its - body matches the body of the key update command in - [UPDATE-KEYS-CMD]. Whenever sending status [00 02], the introduction - point MUST send this extension field. - 3.2.3. Legacy formats [LEGACY-INTRODUCE1] If a hidden service has listed a legacy introduction point in its

1 0

[translation/tails-onioncircuits_completed] Update translations for tails-onioncircuits_completed
by translation＠torproject.org 09 Apr '16

09 Apr '16

commit 6303f63745ce28eccb7caa98c69c9c599abb82c9 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Apr 9 08:16:56 2016 +0000 Update translations for tails-onioncircuits_completed --- da/onioncircuits.pot | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) diff --git a/da/onioncircuits.pot b/da/onioncircuits.pot new file mode 100644 index 0000000..00878d5 --- /dev/null +++ b/da/onioncircuits.pot @@ -0,0 +1,92 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# +# Translators: +# Thomas Pryds <thomas(a)pryds.eu>, 2016 +msgid "" +msgstr "" +"Project-Id-Version: The Tor Project\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2016-03-31 21:31+0200\n" +"PO-Revision-Date: 2016-04-09 08:04+0000\n" +"Last-Translator: Thomas Pryds <thomas(a)pryds.eu>\n" +"Language-Team: Danish (http://www.transifex.com/otf/torproject/language/da/)\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Language: da\n" +"Plural-Forms: nplurals=2; plural=(n != 1);\n" + +#: ../onioncircuits:81 +msgid "" +"Cannot connect to the Tor daemon. Onion Circuits will try to reconnect..." +msgstr "Kan ikke forbinde til Tor-dæmonen. Onion Circuits vil prøve at genforbinde…" + +#: ../onioncircuits:94 +msgid "Onion Circuits" +msgstr "Onion Circuits" + +#: ../onioncircuits:95 +msgid "Display Tor circuits and streams" +msgstr "Vis Tor-kredsløb og -strømme" + +#: ../onioncircuits:107 +msgid "OK" +msgstr "OK" + +#: ../onioncircuits:124 +msgid "Path" +msgstr "Sti" + +#: ../onioncircuits:125 +msgid "Status" +msgstr "Status" + +#: ../onioncircuits:141 +msgid "Click on a path to get details" +msgstr "Klik på en sti for detaljer" + +#: ../onioncircuits:215 +msgid "" +"Lost connection to the Tor daemon. Onion Circuits will try to reconnect..." +msgstr "Mistede forbindelsen til Tor-dæmonen. Onion Circuits vil prøve at genforbinde…" + +#: ../onioncircuits:232 +msgid "Connected to the Tor daemon! You can use now Onion Circuits." +msgstr "Forbundet til Tor-dæmonen! Du kan nu bruge Onion Circuits." + +#: ../onioncircuits:314 +msgid "Building..." +msgstr "Opbygger…" + +#: ../onioncircuits:339 +#, c-format +msgid "%s: %s" +msgstr "%s: %s" + +#: ../onioncircuits:564 +msgid "Fingerprint:" +msgstr "Fingeraftryk:" + +#: ../onioncircuits:565 +msgid "Published:" +msgstr "Udgivet:" + +#: ../onioncircuits:566 +msgid "IP:" +msgstr "IP:" + +#: ../onioncircuits:566 +#, c-format +msgid "%s (%s)" +msgstr "%s (%s)" + +#: ../onioncircuits:567 +msgid "Bandwidth:" +msgstr "Båndbredde:" + +#: ../onioncircuits:567 +#, c-format +msgid "%.2f Mb/s" +msgstr "%.2f Mb/s"

1 0