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

[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

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

09 Apr '16

commit 8f778bd4831c18e42ee8370b009b18ac3d2ad0c3 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Apr 9 08:16:52 2016 +0000 Update translations for tails-onioncircuits --- da/onioncircuits.pot | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/da/onioncircuits.pot b/da/onioncircuits.pot index 06560be..00878d5 100644 --- a/da/onioncircuits.pot +++ b/da/onioncircuits.pot @@ -3,13 +3,14 @@ # 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-26 00:31+0100\n" -"PO-Revision-Date: 2016-03-30 03:31+0000\n" -"Last-Translator: FULL NAME <EMAIL@ADDRESS>\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" @@ -20,15 +21,15 @@ msgstr "" #: ../onioncircuits:81 msgid "" "Cannot connect to the Tor daemon. Onion Circuits will try to reconnect..." -msgstr "" +msgstr "Kan ikke forbinde til Tor-dæmonen. Onion Circuits vil prøve at genforbinde…" #: ../onioncircuits:94 msgid "Onion Circuits" -msgstr "" +msgstr "Onion Circuits" #: ../onioncircuits:95 msgid "Display Tor circuits and streams" -msgstr "" +msgstr "Vis Tor-kredsløb og -strømme" #: ../onioncircuits:107 msgid "OK" @@ -44,25 +45,25 @@ msgstr "Status" #: ../onioncircuits:141 msgid "Click on a path to get details" -msgstr "" +msgstr "Klik på en sti for detaljer" #: ../onioncircuits:215 msgid "" "Lost connection to the Tor daemon. Onion Circuits will try to reconnect..." -msgstr "" +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 "" +msgstr "Forbundet til Tor-dæmonen! Du kan nu bruge Onion Circuits." #: ../onioncircuits:314 msgid "Building..." -msgstr "" +msgstr "Opbygger…" #: ../onioncircuits:339 #, c-format msgid "%s: %s" -msgstr "" +msgstr "%s: %s" #: ../onioncircuits:564 msgid "Fingerprint:" @@ -70,16 +71,16 @@ msgstr "Fingeraftryk:" #: ../onioncircuits:565 msgid "Published:" -msgstr "" +msgstr "Udgivet:" #: ../onioncircuits:566 msgid "IP:" -msgstr "" +msgstr "IP:" #: ../onioncircuits:566 #, c-format msgid "%s (%s)" -msgstr "" +msgstr "%s (%s)" #: ../onioncircuits:567 msgid "Bandwidth:" @@ -88,4 +89,4 @@ msgstr "Båndbredde:" #: ../onioncircuits:567 #, c-format msgid "%.2f Mb/s" -msgstr "" +msgstr "%.2f Mb/s"

1 0

[translation/tor-messenger-ircproperties_completed] Update translations for tor-messenger-ircproperties_completed
by translation＠torproject.org 09 Apr '16

09 Apr '16

commit ec1266cc9ce935243e161f5a61ec45edeacbdbb1 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Apr 9 08:16:32 2016 +0000 Update translations for tor-messenger-ircproperties_completed --- da/irc.properties | 3 +++ 1 file changed, 3 insertions(+) diff --git a/da/irc.properties b/da/irc.properties index 8fee831..6cc4762 100644 --- a/da/irc.properties +++ b/da/irc.properties @@ -172,6 +172,9 @@ error.sendMessageFailed=Der skete en fejl, da sidste besked blev afsendt. Prøv # %1$S is the channel the user tried to join, %2$S is the channel # he was forwarded to. error.channelForward=Du har ikke tilladelse til at gå ind i %1$S og blev automatisk videre dirigeret til %2$S. +# %S is the mode that the user tried to set but was not recognized +# by the server as a valid mode. +error.unknownMode="%S" er ikke en gyldig brugertilstand på denne server. # LOCALIZATION NOTE (tooltip.*): # These are the descriptions given in a tooltip with information received

1 0

[translation/tor-messenger-ircproperties] Update translations for tor-messenger-ircproperties
by translation＠torproject.org 09 Apr '16

09 Apr '16

commit 55298687c59c1bf04f4cd2a82df3e6f1d80d213b Author: Translation commit bot <translation(a)torproject.org> Date: Sat Apr 9 08:16:28 2016 +0000 Update translations for tor-messenger-ircproperties --- da/irc.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/da/irc.properties b/da/irc.properties index b0e60c1..6cc4762 100644 --- a/da/irc.properties +++ b/da/irc.properties @@ -174,7 +174,7 @@ error.sendMessageFailed=Der skete en fejl, da sidste besked blev afsendt. Prøv error.channelForward=Du har ikke tilladelse til at gå ind i %1$S og blev automatisk videre dirigeret til %2$S. # %S is the mode that the user tried to set but was not recognized # by the server as a valid mode. -error.unknownMode='%S' is not a valid user mode on this server. +error.unknownMode="%S" er ikke en gyldig brugertilstand på denne server. # LOCALIZATION NOTE (tooltip.*): # These are the descriptions given in a tooltip with information received

1 0