- tor-commits - lists.torproject.org

[torspec/master] Latest version of proposal 295 (from Jan :/ )
by nickm＠torproject.org 23 Apr '20

23 Apr '20

commit 2202910e2b699e0bd9e6eca0d59094c15684707b Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 23 15:20:45 2020 -0400 Latest version of proposal 295 (from Jan :/ ) --- proposals/295-relay-crypto-with-adl.txt | 268 ++++++++++++++++++++++++++------ 1 file changed, 223 insertions(+), 45 deletions(-) diff --git a/proposals/295-relay-crypto-with-adl.txt b/proposals/295-relay-crypto-with-adl.txt index cfb58a2..d3414c4 100644 --- a/proposals/295-relay-crypto-with-adl.txt +++ b/proposals/295-relay-crypto-with-adl.txt @@ -2,7 +2,8 @@ Filename: 295-relay-crypto-with-adl.txt Title: Using ADL for relay cryptography (solving the crypto-tagging attack) Author: Tomer Ashur, Orr Dunkelman, Atul Luykx Created: 22 Feb 2018 -Last-Modified: 10 July 2019 +Last-Modified: 13 Jan. 2020 + Status: Open @@ -37,7 +38,12 @@ Status: Open available online at https://eprint.iacr.org/2017/239 . For authentication between the OP and the edge node we use - the PIV scheme: https://eprint.iacr.org/2013/835 + the PIV scheme: https://eprint.iacr.org/2013/835 . + + A recent paper presented a birthday bound distinguisher + against the ADL scheme, thus showing that the RUP security + proof is tight: https://eprint.iacr.org/2019/1359 . + 2. Preliminaries @@ -74,7 +80,7 @@ Status: Open ENC_KEY_LEN -- The key length used for encryption (e.g., AES). We recommend ENC_KEY_LEN = 256. -2.4. Key derivation (replaces Section 5.2.2) +2.4. Key derivation (replaces Section 5.2.2 in Tor-spec.txt) For newer KDF needs, Tor uses the key derivation function HKDF from RFC5869, instantiated with SHA256. The generated key @@ -93,26 +99,27 @@ Status: Open When used in the ntor handshake a string of key material is generated and is used in the following way: - Length Purpose Notation - ------ ------- -------- - HASH_LEN forward digest IV DF - HASH_LEN backward digest IV DB - ENC_KEY_LEN encryption key Kf - ENC_KEY_LEN decryption key Kb - DIG_KEY_LEN forward digest key Khf - DIG_KEY_LEN backward digest key Khb - ENC_KEY_LEN forward tweak key Ktf - ENC_KEY_LEN backward tweak key Ktb - DIGEST_LEN nonce to use in the * - hidden service protocol - - * I am not sure that we need this any longer. + Length Purpose Notation + ------ ------- -------- + HASH_LEN forward authentication digest IV AF + HASH_LEN forward digest IV DF + HASH_LEN backward digest IV DB + ENC_KEY_LEN encryption key Kf + ENC_KEY_LEN decryption key Kb + DIG_KEY_LEN forward digest key Khf + DIG_KEY_LEN backward digest key Khb + ENC_KEY_LEN forward tweak key Ktf + ENC_KEY_LEN backward tweak key Ktb + DIGEST_LEN nonce to use in the + hidden service protocol(*) + + (*) I am not sure that if this is still needed. Excess bytes from K are discarded. 2.6. Ciphers - For hashing(*) we use GHASH with a DIG_KEY_LEN-bit key. We write + For hashing(*) we use GHASH(**) with a DIG_KEY_LEN-bit key. We write this as Digest(K,M) where K is the key and M the message to be hashed. @@ -128,19 +135,23 @@ Status: Open the message to be encrypted (resp., decrypted). (*) The terms hash and digest are used interchangeably. + (**) Proposal 308 suggested that using POLYVAL [GLL18] + would be more efficient here. This proposal will work just the + same if POLYVAL is used instead of GHASH. 3. Routing relay cells Let n denote the integer representing the destination node. For - I = 1...n, we set Tf'_{I} = DF_I and Tb'_{I} = DB_I - where DF_I and DB_I are generated according to Section 2.4. + I = 1...n, we set Tf'_{I} = DF_I, Tb'_{I} = DB_I, and + Ta'_I = AF_I where DF_I, DB_I, and AF_I are generated + according to Section 2.4. 3.1. Forward Direction The forward direction is the direction that CREATE/CREATE2 cells are sent. -3.1.1. Routing from the Origin +3.1.1. Routing from the origin When an OP sends a relay cell, they prepare the cell as follows: @@ -148,8 +159,9 @@ Status: Open The OP prepares the authentication part of the message: C_{n+1} = M - T_{n+1} = Digest(Khf_n,C_{n+1}) - N_{n+1} = T_{n+1} ^ E(Ktf_n,T_{n+1} ^ 0) + Ta_I = Digest(Khf_n,Ta'_I||C_{n+1}) + N_{n+1} = Ta_I ^ E(Ktf_n,Ta_I ^ 0) + Ta'_{I} = Ta_I Then, the OP prepares the multi-layered encryption: @@ -161,9 +173,9 @@ Status: Open The OP sends C_1 and N_1 to node 1. -3.1.2. Relaying Forward at Onion Routers +3.1.2. Relaying forward at onion routers - When a forward relay cell is received by OR I, it decrypts the + When a forward relay cell is received by OR_I, it decrypts the payload with the stream cipher, as follows: 'Forward' relay cell: @@ -180,14 +192,14 @@ Status: Open For more information, see section 4 below. -3.2. Backward Direction +3.2. Backward direction The backward direction is the opposite direction from CREATE/CREATE2 cells. -3.2.1. Relaying Backward at Onion Routers +3.2.1. Relaying backward at onion routers - When a backward relay cell is received by OR I, it encrypts the + When a backward relay cell is received by OR_I, it encrypts the payload with the stream cipher, as follows: 'Backward' relay cell: @@ -200,7 +212,7 @@ Status: Open with C_{n+1} = M and N_{n+1}=0. Once encrypted, the node passes C_I and N_I along the circuit towards the OP. -3.2.2. Routing to the Origin +3.2.2. Routing to the origin When a relay cell arrives at an OP, the OP decrypts the payload with the stream cipher as follows: @@ -240,17 +252,22 @@ Status: Open authentication is now included in the nonce part of the payload. The old 'Recognized' field is removed and the node always tries to - authenticate the message as follows: + authenticate the message as follows. - forward direction (executed by the end node): +4.1.1 forward direction (executed by the end node): + + Ta_I = Digest(Khf_n,Ta'_I||C_{n+1}) + Tag = Ta_I ^ D(Ktf_n,Ta_I ^ N_{n+1}) - T_{n+1} = Digest(Khf_n,C_{n+1}) - Tag = T_{n+1} ^ D(Ktf_n,T_{n+1} ^ N_{n+1}) + If Tag = 0: + Ta'_I = Ta_I + The message is authenticated. + Otherwise: + Ta'_I remains unchanged. + The message is not authenticated. - The message is recognized and authenticated - (i.e., M = C_{n+1}) if and only if Tag = 0. - backward direction (executed by the OP): +4.1.2 backward direction (executed by the OP): The message is recognized and authenticated (i.e., C_{n+1} = M) if and only if N_{n+1} = 0. @@ -264,14 +281,14 @@ Status: Open and version-heterogenic circuits When a cell is prepared to be routed from the origin (see Section - 3.1.1) the encrypted nonce N is appended to the encrypted cell - (occupying the last 16 bytes of the cell). If the cell is - prepared to be sent to a node supporting the new protocol, S is - combined with other sources to generate the layer's - nonce. Otherwise, if the node only supports the old protocol, n - is still appended to the encrypted cell (so that following nodes - can still recover their nonce), but a synchronized nonce (as per - the old protocol) is used in CTR-mode. + 3.1.1 above) the encrypted nonce N is appended to the encrypted + cell (occupying the last 16 bytes of the cell). If the cell is + prepared to be sent to a node supporting the new protocol, N is + used to generate the layer's nonce. Otherwise, if the node only + supports the old protocol, N is still appended to the encrypted + cell (so that following nodes can still recover their nonce), + but a synchronized nonce (as per the old protocol) is used in + CTR-mode. When a cell is sent along the circuit in the 'backward' direction, nodes supporting the new protocol always assume that @@ -371,7 +388,7 @@ Status: Open long as an honest node supporting the new protocol processes the message between two dishonest ones. -5.3 The Running Digest +5.3. The running digest Unlike the old protocol, the running digest is now computed as the output of a GHASH call instead of a hash function call @@ -385,3 +402,164 @@ Status: Open repeat with low probability. GHASH is a universal hash function, hence it gives such a guarantee assuming its key is chosen uniformly at random. + +6. Forward secrecy + + Inspired by the approach of Proposal 308, a small modification + to this proposal makes it forward secure. The core idea is to + replace the encryption key KF_n after de/encrypting the cell. + As an added benefit, this would allow to keep the authentication + layer stateless (i.e., without keeping a running digest for + this layer). + + Below we present the required changes to the sections above. + +6.1. Routing from the Origin (replacing 3.1.1 above) + + When an OP sends a relay cell, they prepare the + cell as follows: + + The OP prepares the authentication part of the message: + + C_{n+1} = M + T_{n+1} = Digest(Khf_n,C_{n+1}) + N_{n+1} = T_{n+1} ^ E(Ktf_n,T_{n+1} ^ 0) + + + Then, the OP prepares the multi-layered encryption: + For the final layer n: + (C_n,Kf'_n) = Encrypt(Kf_n,N_{n+1},C_{I+1}||0||0) (*) + T_n = Digest(Khf_I,Tf'_n||C_n) + N_n = T_I ^ E(Ktf_n,T_n ^ N_{n+1}) + Tf'_n = T_n + Kf_n = Kf'_n + + (*) CTR mode is used to generate two additional blocks. This + 256-bit value is denoted K'f_n and is used in subsequent + steps to replace the encryption key of this layer. + To achieve forward secrecy it is important that the + obsolete Kf_n is erased in a non-recoverable way. + + For layer I=(n-1)...1: + C_I = Encrypt(Kf_I,N_{I+1},C_{I+1}) + T_I = Digest(Khf_I,Tf'_I||C_I) + N_I = T_I ^ E(Ktf_I,T_I ^ N_{I+1}) + Tf'_I = T_I + + The OP sends C_1 and N_1 to node 1. + + Alternatively, if we want that all nodes use the same functionality + OP prepares the cell as follows: + + For layer I=n...1: + (C_I,K'f_I) = Encrypt(Kf_I,N_{I+1},C_{I+1}||0||0) (*) + T_I = Digest(Khf_I,Tf'_I||C_I) + N_I = T_I ^ E(Ktf_I,T_I ^ N_{I+1}) + Tf'_I = T_I + Kf_I = Kf'_I + + (*) CTR mode is used to generate two additional blocks. This + 256-bit value is denoted K'f_n and is used in subsequent + steps to replace the encryption key of this layer. + To achieve forward secrecy it is important that the + obsolete Kf_n is erased in a non-recoverable way. + + This scheme offers forward secrecy in all levels of the circuit. + +6.2. Relaying Forward at Onion Routers (replacing 3.1.2 above) + + When a forward relay cell is received by OR I, it decrypts the + payload with the stream cipher, as follows: + + 'Forward' relay cell: + + T_I = Digest(Khf_I,Tf'_I||C_I) + N_{I+1} = T_I ^ D(Ktf_I,T_I ^ N_I) + C_{I+1} = Decrypt(Kf_I,N_{I+1},C_I||0||0) + Tf'_I = T_I + + The OR then decides whether it recognizes the relay cell as described below. + Depending on the choice of scheme from 6.1 the OR uses the last two blocks + of C_{I+1} to update the encryption key or discards them. + + If the cell is recognized the OR also processes the contents of the relay + cell. Otherwise, it passes C_{I+1}||N_{I+1} along the circuit if the circuit + continues. + + For more information about recognizing and authenticating relay cells, + see 5.4.5 below. + +6.3. Relaying Backward at Onion Routers (replacing 3.2.1 above) + + When an edge node receives a message M to be routed back to the + origin, it encrypts it as follows: + + T_n = Digest(Khb_n,Tb'_n||M) + N_n = T_n ^ E(Ktb_n,T_n ^ 0) + (C_n,K'b_n) = Encrypt(Kb_n,N_n,M||0||0) (*) + Tb'_n = T_n + Kb_n = K'b_n + + (*) CTR mode is used to generate two additional blocks. This + 256-bit value is denoted K'b_n and will be used in + subsequent steps to replace the encryption key of this layer. + To achieve forward secrecy it is important that the obsolete + K'b_n is erased in a non-recoverable way. + + Once encrypted, the edge node sends C_n and N_n along the circuit towards + the OP. When a backward relay cell is received by OR_I (I<n), it encrypts + the payload with the stream cipher, as follows: + + 'Backward' relay cell: + + T_I = Digest(Khb_I,Tb'_I||C_{I+1}) + N_I = T_I ^ E(Ktb_I,T_I ^ N_{I+1}) + C_I = Encrypt(Kb_I,N_I,C_{I+1}) + Tb'_I = T_I + + Each node passes C_I and N_I along the circuit towards the OP. + + If forward security is desired for all layers in the circuit, all OR's + encrypt as follows: + T_I = Digest(Khb_I,Tb'_I||C_{I+1}) + N_I = T_I ^ E(Ktb_I,T_I ^ 0) + (C_I,K'b_I) = Encrypt(Kb_n,N_n,M||0||0) + Tb'_I = T_I + Kb_I = K'b_I + + +6.4. Routing to the Origin (replacing 3.2.2 above) + + When a relay cell arrives at an OP, the OP decrypts the payload + with the stream cipher as follows: + + OP receives relay cell from node 1: + + For I=1...n, where n is the end node on the circuit: + C_{I+1} = Decrypt(Kb_I,N_I,C_I) + T_I = Digest(Khb_I,Tb'_I||C_{I+1}) + N_{I+1} = T_I ^ D(Ktb_I,T_I ^ N_I) + Tb'_I = T_I + + And updates the encryption keys according to the strategy + chosen for 6.3. + + If the payload is recognized (see Section 4.1), + then: + + The sending node is I. Process the payload! + + +6.5. Recognizing and authenticating a relay cell (replacing 4.1.1 above): + + Authentication in the forward direction is done as follows: + + T_{n+1} = Digest(Khf_n,C_{n+1}) + Tag = T_{n+1} ^ D(Ktf_n,T_{n+1} ^ N_{n+1}) + + The message is recognized and authenticated + (i.e., M = C_{n+1}) if and only if Tag = 0. + + No changes are required to the authentication process when the relay + cell is sent backwards. +

1 0

[torspec/master] whitespace fixes on proposal 295.
by nickm＠torproject.org 23 Apr '20

23 Apr '20

commit 2ec807e10464c9881baef6318ff41ce58c07171e Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 23 15:21:46 2020 -0400 whitespace fixes on proposal 295. --- proposals/295-relay-crypto-with-adl.txt | 144 ++++++++++++++++---------------- 1 file changed, 71 insertions(+), 73 deletions(-) diff --git a/proposals/295-relay-crypto-with-adl.txt b/proposals/295-relay-crypto-with-adl.txt index d3414c4..a1752df 100644 --- a/proposals/295-relay-crypto-with-adl.txt +++ b/proposals/295-relay-crypto-with-adl.txt @@ -3,7 +3,6 @@ Title: Using ADL for relay cryptography (solving the crypto-tagging attack) Author: Tomer Ashur, Orr Dunkelman, Atul Luykx Created: 22 Feb 2018 Last-Modified: 13 Jan. 2020 - Status: Open @@ -39,11 +38,11 @@ Status: Open For authentication between the OP and the edge node we use the PIV scheme: https://eprint.iacr.org/2013/835 . - + A recent paper presented a birthday bound distinguisher - against the ADL scheme, thus showing that the RUP security + against the ADL scheme, thus showing that the RUP security proof is tight: https://eprint.iacr.org/2019/1359 . - + 2. Preliminaries @@ -110,7 +109,7 @@ Status: Open DIG_KEY_LEN backward digest key Khb ENC_KEY_LEN forward tweak key Ktf ENC_KEY_LEN backward tweak key Ktb - DIGEST_LEN nonce to use in the + DIGEST_LEN nonce to use in the hidden service protocol(*) (*) I am not sure that if this is still needed. @@ -136,15 +135,15 @@ Status: Open (*) The terms hash and digest are used interchangeably. (**) Proposal 308 suggested that using POLYVAL [GLL18] - would be more efficient here. This proposal will work just the - same if POLYVAL is used instead of GHASH. + would be more efficient here. This proposal will work just the + same if POLYVAL is used instead of GHASH. 3. Routing relay cells Let n denote the integer representing the destination node. For - I = 1...n, we set Tf'_{I} = DF_I, Tb'_{I} = DB_I, and - Ta'_I = AF_I where DF_I, DB_I, and AF_I are generated - according to Section 2.4. + I = 1...n, we set Tf'_{I} = DF_I, Tb'_{I} = DB_I, and + Ta'_I = AF_I where DF_I, DB_I, and AF_I are generated + according to Section 2.4. 3.1. Forward Direction @@ -255,7 +254,7 @@ Status: Open authenticate the message as follows. 4.1.1 forward direction (executed by the end node): - + Ta_I = Digest(Khf_n,Ta'_I||C_{n+1}) Tag = Ta_I ^ D(Ktf_n,Ta_I ^ N_{n+1}) @@ -281,13 +280,13 @@ Status: Open and version-heterogenic circuits When a cell is prepared to be routed from the origin (see Section - 3.1.1 above) the encrypted nonce N is appended to the encrypted + 3.1.1 above) the encrypted nonce N is appended to the encrypted cell (occupying the last 16 bytes of the cell). If the cell is prepared to be sent to a node supporting the new protocol, N is - used to generate the layer's nonce. Otherwise, if the node only - supports the old protocol, N is still appended to the encrypted - cell (so that following nodes can still recover their nonce), - but a synchronized nonce (as per the old protocol) is used in + used to generate the layer's nonce. Otherwise, if the node only + supports the old protocol, N is still appended to the encrypted + cell (so that following nodes can still recover their nonce), + but a synchronized nonce (as per the old protocol) is used in CTR-mode. When a cell is sent along the circuit in the 'backward' @@ -402,20 +401,20 @@ Status: Open repeat with low probability. GHASH is a universal hash function, hence it gives such a guarantee assuming its key is chosen uniformly at random. - + 6. Forward secrecy - Inspired by the approach of Proposal 308, a small modification - to this proposal makes it forward secure. The core idea is to + Inspired by the approach of Proposal 308, a small modification + to this proposal makes it forward secure. The core idea is to replace the encryption key KF_n after de/encrypting the cell. - As an added benefit, this would allow to keep the authentication - layer stateless (i.e., without keeping a running digest for - this layer). - + As an added benefit, this would allow to keep the authentication + layer stateless (i.e., without keeping a running digest for + this layer). + Below we present the required changes to the sections above. - + 6.1. Routing from the Origin (replacing 3.1.1 above) - + When an OP sends a relay cell, they prepare the cell as follows: @@ -424,7 +423,7 @@ Status: Open C_{n+1} = M T_{n+1} = Digest(Khf_n,C_{n+1}) N_{n+1} = T_{n+1} ^ E(Ktf_n,T_{n+1} ^ 0) - + Then, the OP prepares the multi-layered encryption: For the final layer n: @@ -433,13 +432,13 @@ Status: Open N_n = T_I ^ E(Ktf_n,T_n ^ N_{n+1}) Tf'_n = T_n Kf_n = Kf'_n - - (*) CTR mode is used to generate two additional blocks. This - 256-bit value is denoted K'f_n and is used in subsequent + + (*) CTR mode is used to generate two additional blocks. This + 256-bit value is denoted K'f_n and is used in subsequent steps to replace the encryption key of this layer. - To achieve forward secrecy it is important that the - obsolete Kf_n is erased in a non-recoverable way. - + To achieve forward secrecy it is important that the + obsolete Kf_n is erased in a non-recoverable way. + For layer I=(n-1)...1: C_I = Encrypt(Kf_I,N_{I+1},C_{I+1}) T_I = Digest(Khf_I,Tf'_I||C_I) @@ -447,27 +446,27 @@ Status: Open Tf'_I = T_I The OP sends C_1 and N_1 to node 1. - - Alternatively, if we want that all nodes use the same functionality + + Alternatively, if we want that all nodes use the same functionality OP prepares the cell as follows: - + For layer I=n...1: (C_I,K'f_I) = Encrypt(Kf_I,N_{I+1},C_{I+1}||0||0) (*) T_I = Digest(Khf_I,Tf'_I||C_I) N_I = T_I ^ E(Ktf_I,T_I ^ N_{I+1}) Tf'_I = T_I Kf_I = Kf'_I - - (*) CTR mode is used to generate two additional blocks. This - 256-bit value is denoted K'f_n and is used in subsequent + + (*) CTR mode is used to generate two additional blocks. This + 256-bit value is denoted K'f_n and is used in subsequent steps to replace the encryption key of this layer. - To achieve forward secrecy it is important that the - obsolete Kf_n is erased in a non-recoverable way. - + To achieve forward secrecy it is important that the + obsolete Kf_n is erased in a non-recoverable way. + This scheme offers forward secrecy in all levels of the circuit. - + 6.2. Relaying Forward at Onion Routers (replacing 3.1.2 above) - + When a forward relay cell is received by OR I, it decrypts the payload with the stream cipher, as follows: @@ -478,36 +477,36 @@ Status: Open C_{I+1} = Decrypt(Kf_I,N_{I+1},C_I||0||0) Tf'_I = T_I - The OR then decides whether it recognizes the relay cell as described below. - Depending on the choice of scheme from 6.1 the OR uses the last two blocks - of C_{I+1} to update the encryption key or discards them. - - If the cell is recognized the OR also processes the contents of the relay - cell. Otherwise, it passes C_{I+1}||N_{I+1} along the circuit if the circuit + The OR then decides whether it recognizes the relay cell as described below. + Depending on the choice of scheme from 6.1 the OR uses the last two blocks + of C_{I+1} to update the encryption key or discards them. + + If the cell is recognized the OR also processes the contents of the relay + cell. Otherwise, it passes C_{I+1}||N_{I+1} along the circuit if the circuit continues. For more information about recognizing and authenticating relay cells, see 5.4.5 below. - + 6.3. Relaying Backward at Onion Routers (replacing 3.2.1 above) When an edge node receives a message M to be routed back to the origin, it encrypts it as follows: - + T_n = Digest(Khb_n,Tb'_n||M) N_n = T_n ^ E(Ktb_n,T_n ^ 0) (C_n,K'b_n) = Encrypt(Kb_n,N_n,M||0||0) (*) Tb'_n = T_n Kb_n = K'b_n - - (*) CTR mode is used to generate two additional blocks. This - 256-bit value is denoted K'b_n and will be used in - subsequent steps to replace the encryption key of this layer. - To achieve forward secrecy it is important that the obsolete - K'b_n is erased in a non-recoverable way. - - Once encrypted, the edge node sends C_n and N_n along the circuit towards - the OP. When a backward relay cell is received by OR_I (I<n), it encrypts + + (*) CTR mode is used to generate two additional blocks. This + 256-bit value is denoted K'b_n and will be used in + subsequent steps to replace the encryption key of this layer. + To achieve forward secrecy it is important that the obsolete + K'b_n is erased in a non-recoverable way. + + Once encrypted, the edge node sends C_n and N_n along the circuit towards + the OP. When a backward relay cell is received by OR_I (I<n), it encrypts the payload with the stream cipher, as follows: 'Backward' relay cell: @@ -518,7 +517,7 @@ Status: Open Tb'_I = T_I Each node passes C_I and N_I along the circuit towards the OP. - + If forward security is desired for all layers in the circuit, all OR's encrypt as follows: T_I = Digest(Khb_I,Tb'_I||C_{I+1}) @@ -526,7 +525,7 @@ Status: Open (C_I,K'b_I) = Encrypt(Kb_n,N_n,M||0||0) Tb'_I = T_I Kb_I = K'b_I - + 6.4. Routing to the Origin (replacing 3.2.2 above) @@ -540,26 +539,25 @@ Status: Open T_I = Digest(Khb_I,Tb'_I||C_{I+1}) N_{I+1} = T_I ^ D(Ktb_I,T_I ^ N_I) Tb'_I = T_I - - And updates the encryption keys according to the strategy + + And updates the encryption keys according to the strategy chosen for 6.3. - + If the payload is recognized (see Section 4.1), then: The sending node is I. Process the payload! - - + + 6.5. Recognizing and authenticating a relay cell (replacing 4.1.1 above): - - Authentication in the forward direction is done as follows: + + Authentication in the forward direction is done as follows: T_{n+1} = Digest(Khf_n,C_{n+1}) Tag = T_{n+1} ^ D(Ktf_n,T_{n+1} ^ N_{n+1}) - + The message is recognized and authenticated (i.e., M = C_{n+1}) if and only if Tag = 0. - - No changes are required to the authentication process when the relay + + No changes are required to the authentication process when the relay cell is sent backwards. -

1 0

[torspec/master] proposal 316: flashflow.
by nickm＠torproject.org 23 Apr '20

23 Apr '20

commit ade20b92654f782c2a7c09da73d67aeca6e7f622 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 23 15:12:30 2020 -0400 proposal 316: flashflow. --- proposals/000-index.txt | 2 + proposals/316-flashflow.txt | 780 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 782 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index de45e48..c9325e7 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -236,6 +236,7 @@ Proposals by number: 313 Tor Relay IPv6 Statistics [DRAFT] 314 Allow Markdown for proposal format [OPEN] 315 Updating the list of fields required in directory documents [OPEN] +316 FlashFlow: A Secure Speed Test for Tor (Parent Proposal) [DRAFT] Proposals by status: @@ -252,6 +253,7 @@ Proposals by status: 311 Tor Relay IPv6 Reachability 312 Tor Relay Automatic IPv6 Address Discovery 313 Tor Relay IPv6 Statistics + 316 FlashFlow: A Secure Speed Test for Tor (Parent Proposal) NEEDS-REVISION: 212 Increase Acceptable Consensus Age [for 0.2.4.x+] 219 Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x] diff --git a/proposals/316-flashflow.txt b/proposals/316-flashflow.txt new file mode 100644 index 0000000..733bec2 --- /dev/null +++ b/proposals/316-flashflow.txt @@ -0,0 +1,780 @@ +Filename: 316-flashflow.txt +Title: FlashFlow: A Secure Speed Test for Tor (Parent Proposal) +Author: Matthew Traudt, Aaron Johnson, Rob Jansen, Mike Perry +Created: 23 April 2020 +Status: Draft + +1. Introduction + +FlashFlow is a new distributed bandwidth measurement system for Tor that +consists of a single authority node ("coordinator") instructing one or +more measurement nodes ("measurers") when and how to measure Tor relays. +A measurement consists of the following steps: + + 1. The measurement nodes demonstrate to the target relay permission to + perform measurements. + 2. The measurement nodes open many TCP connections to the target relay + and create a one-hop circuit to the target relay on each one. + 3. For 30 seconds the measurement nodes send measurement cells to the + target relay and verify that the cells echoed back match the ones + sent. During this time the relay caps the amount of background + traffic it transfers. Background and measurement traffic are + handled separately at the relay. Measurement traffic counts towards + all the standard existing relay statistics. + 4. For every second during the measurement, the measurement nodes + report to the authority node how much traffic was echoed back. The + target relay also reports the amount of per-second background + (non-measurement) traffic. + 5. The authority node sums the per-second reported throughputs into 30 + sums (one for each second) and calculates the median. This is the + estimated capacity of the relay. + +FlashFlow performs a measurement of every relay according to a schedule +described later in this document. Periodically it produces relay +capacity estimates in the form of a v3bw file, which is suitable for +direct consumption by a Tor directory authority. Alternatively an +existing load balancing system such as Simple Bandwidth Scanner could be +modified to use FlashFlow's v3bw file as input. + +It is envisioned that each directory authority that wants to use +FlashFlow will run their own FlashFlow deployment consisting of a +coordinator that they run and one or more measurers that they trust +(e.g. because they run them themselves), similar to how each runs their +own Torflow/sbws. Section 5.2 of this proposal describes long term plans +involving multiple FlashFlow deployments. + +FlashFlow is more performant than Torflow: FlashFlow takes 5 hours to +measure the entire existing Tor network from scratch (with 3 Gbit/s +measurer capacity) while Torflow takes 2 days; FlashFlow measures relays +it hasn't seen recently as soon as it learns about them (i.e. every new +consensus) while Torflow can take a day or more; and FlashFlow +accurately measures new high-capacity relays the first time and every +time while Torflow takes days/weeks to assign them their full fair share +of bandwidth (especially for non-exits). FlashFlow is more secure than +Torflow: FlashFlow allows a relay to inflate its measured capacity by up +to 1.33x (configured by a parameter) while Torflow allows weight +inflation by a factor of 89x [0] or even 177x [1]. + +After an overview in section 2 of the planned deployment stages, section +3, 4, and 5 discuss the short, medium, and long term deployment plans in +more detail. + +2. Deployment Stages + +FlashFlow's deployment shall be broken up into three stages. + +In the short term we will implement a working FlashFlow measurement +system. This requires code changes in little-t tor and an external +FlashFlow codebase. The majority of the implementation work will be +done in the short term, and the product is a complete FlashFlow +measurement system. Remaining pieces (e.g. better authentication) are +added later for enhanced security and network performance. + +In the medium term we will begin collecting data with a FlashFlow +deployment. The intermediate results and v3bw files produced will be +made available (semi?) publicly for study. + +In the long term experiments will be performed to study ways of using FF +v3bw files to improve load balancing. Two examples: (1) using FF v3bw +files instead of sbws's (and eventually phasing out torflow/sbws), and +(2) continuing to run sbws but use FF's results as a better estimate of +relay capacity than observed bandwidth. Authentication and other +FlashFlow features necessary to make it completely ready for full +production deployment will be worked on during this long term phase. + +3. FlashFlow measurement system: Short term + +The core measurement mechanics will be implemented in little-t tor, but +a separate codebase for the FlashFlow side of the measurement system +will also be created. This section is divided into three parts: first a +discussion of changes/additions that logically reside entirely within +tor (essentially: relay-side modifications), second a discussion of the +separate FlashFlow code that also requires some amount of tor changes +(essentially: measurer-side and coordinator-side modifications), and +third a security discussion. + +3.1 Little-T Tor Components + +The primary additions/changes that entirely reside within tor on the +relay side: + + - New torrc options/consensus parameters. + - New cell commands. + - Pre-measurement handshaking (with a simplified authentication + scheme). + - Measurement mode, during which the relay will echo traffic with + measurers, set a cap on the amount of background traffic it + transfers, and report the amount of transferred background traffic. + +3.1.1 Parameters + +FlashFlow will require some consensus parameters/torrc options. Each has +some default value if nothing is specified; the consensus parameter +overrides this default value; the torrc option overrides both. + +FFMeasurementsAllowed: A global toggle on whether or not to allow +measurements. Even if all other settings would allow a measurement, if +this is turned off, then no measurement is allowed. Possible values: 0, +1. Default: 0 (disallowed). + +FFAllowedCoordinators: The list of coordinator TLS certificate +fingerprints that are allowed to start measurements. Relays check their +torrc when they receive a connection from a FlashFlow coordinator to see +if it's on the list. If they have no list, they check the consensus +parameter. If nether exist, then no FlashFlow deployment is allowed to +measure this relay. Default: empty list. + +FFMeasurementPeriod: A relay should expect on average, to be measured by +each FlashFlow deployment once each measurement period. A relay will not +allow itself to be measured more than twice by a FlashFlow deployment in +any time window of this length. Relays should not change this option +unless they really know what they're doing. Changing it at the relay +will not change how often FlashFlow will attempt to measure the relay. +Possible values are in the range [1 hour, 1 month] inclusive. Default: 1 +day. + +FFBackgroundTrafficPercent: The maximum amount of regular +non-measurement traffic a relay should handle while being measured, as a +percent of total traffic (measurement + non-measurement). This +parameter is a trade off between having to limit background traffic and +limiting how much a relay can inflate its result by handling no +background traffic but reporting that it has done so. Possible values +are in the range [0, 99] inclusive. Default: 25 (a maximum inflation +factor of 1.33). + +FFMaxMeasurementDuration: The maximum amount of time, in seconds, that +is allowed to pass from the moment the relay is notified that a +measurement will begin soon and the end of the measurement. If this +amount of time passes, the relay shall close all measurement connections +and exit its measurement mode. Note this duration includes handshake +time, thus it necessarily is larger than the expected actual measurement +duration. Possible values are in the range [10, 120] inclusive. +Default: 45. + +3.1.2 New Cell Types + +FlashFlow will introduce a new cell command MEASURE. + +The payload of each MEASURE cell consists of: + + Measure command [1 byte] + Length [2 bytes] + Data [Length-3 bytes] + +The measure commands are: + + 0 -- MSM_PARAMS [forward] + 1 -- MSM_PARAMS_OK [backward] + 2 -- MSM_ECHO [forward and backward] + 3 -- MSM_BG [backward] + 4 -- MSM_ERR [forward and backward] + +Forward cells are sent from the measurer/coordinator to the relay. +Backward cells are sent from the relay to the measurer/coordinator. + +MSM_PARAMS and MSM_PARAMS_OK are used during the pre-measurement stage +to tell the target what to expect and for the relay to positively +acknowledge the message. MSM_ECHO cells are the measurement traffic; +the measurer generates them, sends them to the target, and the target +echos them back. The target send a MSM_BG cell once per second to report +the amount of background traffic it is handling. MSM_ERR cells are used +to signal to the other party that there has been some sort of problem +and that the measurement should be aborted. These measure commands are +described in more detail in the next section. + +The only cell that sometimes undergoes cell encryption is MSM_ECHO; no +other cell ever gets cell encrypted. (All cells are transmitted on a +regular TLS-wrapped OR connection; that encryption still exists.) + +The relay "decrypts" MSM_ECHO cells before sending them back to the +measurer; this mirrors the way relays decrypt/encrypt RELAY_DATA cells +in order to induce realistic cryptographic CPU load. The measurer +usually skips encrypting MSM_ECHO cells to reduce its own CPU load; +however, to verify the relay is actually correctly decrypting all cells, +the measurer will choose random outgoing cells, encrypt them, remember +the ciphertext, and verify the corresponding incoming cell matches. + +3.1.3 Pre-Measurement Handshaking/Starting a Measurement + +The coordinator connects to the target relay and sends it a MSM_PARAMS +cell. If the target is unwilling to be measured at this time or if the +coordinator didn't use a TLS certificate that the target trusts, it +responds with an error cell and closes the connection. Otherwise it +checks that the parameters of the measurement are acceptable (e.g. the +version is acceptable, the duration isn't too long, etc.). If the +target is happy, it sends a MSM_PARAMS_OK, otherwise it sends a MSM_ERR +and closes the connection. + +Upon learning the IP addresses of the measurers from the coordinator in +the MSM_PARAMS cell, the target whitelists their IPs in its DoS +detection subsystem until the measurement ends (successfully or +otherwise), at which point the whitelist is cleared. + +Upon receiving a MSM_PARAMS_OK from the target, the coordinator will +instruct the measurers to open their TCP connections with the target. If +the coordinator or any measurer receives a MSM_ERR, it reports the error +to the coordinator and considers the measurement a failure. It is also a +failure if any measurer is unable to open at least half of its TCP +connections with the target. + +The payload of MSM_PARAMS cells [XXX more may need to be added]: + + - version [1 byte] + - msm_duration [1 byte] + - num_measurers [1 byte] + - measurer_info [num_measurers times] + - ipv4_addr [4 bytes] + - num_conns [2 bytes] + +version dictates how this MSM_PARAMS cell shall be parsed. msm_duration +is the duration, in seconds, that the actual measurement will last. +num_measurers is how many measurer_info structs follow. For each +measurer, the ipv4_addr it will use when connecting to the target is +provided, as is num_conns, the number of TCP connections that measurer +will open with the target. Future versions of FlashFlow and MSM_PARAMS +will use TLS certificates instead of IP addresses. + +MSM_PARAMS_OK has no payload: it's just padding bytes to make the cell +514 bytes long. + +The payload of MSM_ECHO cells: + + - arbitrary bytes [max to fill up 514 byte cell] + +The payload of MSM_BG cells: + + - second [1 byte] + - sent_bg_bytes [4 bytes] + - recv_bg_bytes [4 bytes] + +second is the number of seconds since the measurement began. MSM_BG +cells are sent once per second from the relay to the FlashFlow +coordinator. The first cell will have this set to 1, and each +subsequent cell will increment it by one. sent_bg_bytes is the number of +background traffic bytes sent in the last second (since the last MSM_BG +cell). recv_bg_bytes is the same but for received bytes. + +The payload of MSM_ERR cells: + + - err_code [1 byte] + - err_str [possibly zero-len null-terminated string] + +The error code is one of: + + [... XXX TODO ...] + 255 -- OTHER + +The error string is optional in all cases. It isn't present if the first +byte of err_str is null, otherwise it is present. It ends at the first +null byte or the end of the cell, whichever comes first. + +3.1.4 Measurement Mode + +The relay considers the measurement to have started the moment it +receives the first MSM_ECHO cell from any measurer. At this point, the +relay + + - Starts a repeating 1s timer on which it will report the amount of + background traffic to the coordinator over the coordinator's + connection. + - Enters "measurement mode" and limits the amount of background + traffic it handles according to the torrc option/consensus + parameter. + +The relay decrypts and echos back all MSM_ECHO cells it receives on +measurement connections until it has reported its amount of background +traffic the same number of times as there are seconds in the measurement +(e.g. 30 per-second reports for a 30 second measurement). After sending +the last MSM_BG cell, the relay drops all buffered MSM_ECHO cells, +closes all measurement connections, and exits measurement mode. + +During the measurement the relay targets a ratio of background traffic +to measurement traffic as specified by a consensus parameter/torrc +option. For a given ratio r, if the relay has handled x cells of +measurement traffic recently, Tor then limits itself to y = xr/(1-r) +cells of non-measurement traffic this scheduling round. The target will +enforce that a minimum of 10 Mbit/s of measurement traffic is recorded +since the last background traffic scheduling round to ensure it always +allows some minimum amount of background traffic. + +3.2 FlashFlow Components + +The FF coordinator and measurer code will reside in a FlashFlow +repository separate from little-t tor. + +There are three notable parameters for which a FF deployment must choose +values. They are: + + - The number of sockets, s, the measurers should open, in aggregate, + with the target relay. We suggest s=160 based on the FF paper. + - The bandwidth multiplier, m. Given an existing capacity estimate for + a relay, z, the coordinator will instruct the measurers to, in + aggregate, send m*z Mbit/s to the target relay. We recommend m=2.25. + - The measurement duration, d. Based on the FF paper, we recommend + d=30 seconds. + +The rest of this section first discusses notable functions of the +FlashFlow coordinator, then goes on to discuss FF measurer code that +will require supporting tor code. + +3.2.1 FlashFlow Coordinator + +The coordinator is responsible for scheduling measurements, aggregating +results, and producing v3bw files. It needs continuous access to new +consensus files, which it can obtain by running an accompanying Tor +process in client mode. + +The coordinator has the following functions, which will be described in +this section: + + - result aggregation. + - schedule measurements. + - v3bw file generation. + +3.2.1.1 Aggregating Results + +Every second during a measurement, the measurers send the amount of +verified measurement traffic they have received back from the relay. +Additionally, the relay sends a MSM_BG cell each second to the +coordinator with amount of non-measurement background traffic it is +sending and receiving. + +For each second's reports, the coordinator sums the measurer's reports. +The coordinator takes the minimum of the relay's reported sent and +received background traffic. If, when compared to the measurer's reports +for this second, the relay's claimed background traffic is more than +what's allowed by the background/measurement traffic ratio, then the +coordinator further clamps the relay's report down. The coordinator adds +this final adjusted amount of background traffic to the sum of the +measurer's reports. + +Once the coordinator has done the above for each second in the +measurement (e.g. 30 times for a 30 second measurement), the coordinator +takes the median of the 30 per-second throughputs and records it as the +estimated capacity of the target relay. + +3.2.1.2 Measurement Schedule + +The short term implementation of measurement scheduling will be simpler +than the long term one due to (1) there only being one FlashFlow +deployment, and (2) there being very few relays that support being +measured by FlashFlow. In fact the FF coordinator will maintain a list +of the relays that have updated to support being measured and have opted +in to being measured, and it will only measure them. + +The coordinator divides time into a series of 24 hour periods, commonly +referred to as days. Each period has measurement slots that are longer +than a measurement lasts (30s), say 60s, to account for pre- and +post-measurement work. Thus with 60s slots there's 1,440 slots in a +day. + +At the start of each day the coordinator considers the list of relays +that have opted in to being measured. From this list of relays, it +repeatedly takes the relay with the largest existing capacity estimate. +It selects a random slot. If the slot has existing relays assigned to +it, the coordinator makes sure there is enough additional measurer +capacity to handle this relay. If so, it assigns this relay to this +slot. If not, it keeps picking new random slots until one has sufficient +additional measurer capacity. + +Relays without existing capacity estimates are assumed to have the 75th +percentile capacity of the current network. + +If a relay is not online when it's scheduled to be measured, it doesn't +get measured that day. + +3.2.1.2.1 Example + +Assume the FF deployment has 1 Gbit/s of measurer capacity. Assume the +chosen multiplier m=2. Assume there are only 5 slots in a measurement +period. + +Consider a set of relays with the following existing capacity estimates +and that have opted in to being measured by FlashFlow. + + - 500 Mbit/s + - 300 Mbit/s + - 250 Mbit/s + - 200 Mbit/s + - 100 Mbit/s + - 50 Mbit/s + +The coordinator takes the largest relay, 500 Mbit/s, and picks a random +slot for it. It picks slot 3. The coordinator takes the next largest, +300, and randomly picks slot 2. The slots are now: + + 0 | 1 | 2 | 3 | 4 + -------|-------|-------|-------|------- + | | 300 | 500 | + | | | | + +The coordinator takes the next largest, 250, and randomly picks slot 2. +Slot 2 already has 600 Mbit/s of measurer capacity reserved (300*m); +given just 1000 Mbit/s of total measurer capacity, there is just 400 +Mbit/s of spare capacity while this relay requires 500 Mbit/s. There is +not enough room in slot 2 for this relay. The coordinator picks a new +random slot, 0. + + 0 | 1 | 2 | 3 | 4 + -------|-------|-------|-------|------- + 250 | | 300 | 500 | + | | | | + +The next largest is 200 and the coordinator randomly picks slot 2 again +(wow!). As there is just enough spare capacity, the coordinator assigns +this relay to slot 2. + + 0 | 1 | 2 | 3 | 4 + -------|-------|-------|-------|------- + 250 | | 300 | 500 | + | | 200 | | + +The coordinator randomly picks slot 4 for the last remaining relays, in +that order. + + 0 | 1 | 2 | 3 | 4 + -------|-------|-------|-------|------- + 250 | | 300 | 500 | 100 + | | 200 | | 50 + +3.2.1.3 Generating V3BW files + +Every hour the FF coordinator produces a v3bw file in which it stores +the latest capacity estimate for every relay it has measured in the last +week. The coordinator will create this file on the host's local file +system. Previously-generated v3bw files will not be deleted by the +coordinator. A symbolic link at a static path will always point to the +latest v3bw file. + + $ ls -l + v3bw -> v3bw.2020-03-01-05-00-00 + v3bw.2020-03-01-00-00-00 + v3bw.2020-03-01-01-00-00 + v3bw.2020-03-01-02-00-00 + v3bw.2020-03-01-03-00-00 + v3bw.2020-03-01-04-00-00 + v3bw.2020-03-01-05-00-00 + +3.2.2 FlashFlow Measurer + +The measurers take commands from the coordinator, connect to target +relays with many sockets, send them traffic, and verify the received +traffic is the same as what was sent. Measurers need access to a lot of +internal tor functionality. One strategy is to house as much logic as +possible inside an compile-time-optional control port module that calls +into other parts of tor. Alternatively FlashFlow could link against tor +and call internal tor functions directly. + +[XXX for now I'll assume that an optional little-t tor control port +module housing a lot of this code is the best idea.] + +Notable new things that internal tor code will need to do on the +measurer (client) side: + + 1. Open many TLS+TCP connections to the same relay on purpose. + 2. Verify echo cells. + +3.2.2.1 Open many connections + +FlashFlow prototypes needed to "hack in" a flag in the +open-a-connection-with-this-relay function call chain that indicated +whether or not we wanted to force a new connection to be created. Most +of Tor doesn't care if it reuses an existing connection, but FF does +want to create many different connections. The cleanest way to +accomplish this will be investigated. + +On the relay side, these measurer connections do not count towards DoS +detection algorithms. + +3.2.2.2 Verify echo cells + +A parameter will exist to tell the measurers with what frequency they +shall verify that cells echoed back to them match what was sent. This +parameter does not need to exist outside of the FF deployment (e.g. it +doesn't need to be a consensus parameter). + +The parameter instructs the measurers to check 1 out of every N cells. + +The measurer keeps a count of how many measurement cells it has sent. It +also logically splits its output stream of cells into buckets of size N. +At the start of each bucket (when num_sent % N == 0), the measurer +chooses a random index in the bucket. Upon sending the cell at that +index (num_sent % N == chosen_index), the measurer records the cell. + +The measurer also counts cells that it receives. When it receives a cell +at an index that was recorded, it verifies that the received cell +matches the recorded sent cell. If they match, no special action is +taken. If they don't match, the measurer indicates failure to the +coordinator and target relay and closes all connections, ending the +measurement. + +3.2.2.2.1 Example + +Consider bucket_size is 1000. For the moment ignore cell encryption. + +We start at idx=0 and pick an idx in [0, 1000) to record, say 640. At +idx=640 we record the cell. At idx=1000 we choose a new idx in [1000, +2000) to record, say 1236. At idx=1236 we record the cell. At idx=2000 +we choose a new idx in [2000, 3000). Etc. + +There's 2000+ cells in flight and the measurer has recorded two items: + + - (640, contents_of_cellA) + - (1236, contents_of_cellB) + +Consider the receive side now. It counts the cells it receives. At +receive idx=640, it checks the received cell matches the saved cell from +before. At receive idx=1236, it again checks the received cell matches. +Etc. + +3.2.2.2.2 Motivation + +A malicious relay may want to skip decryption of measurement cells to +save CPU cycles and obtain a higher capacity estimate. More generally, +it could generate fake measurement cells locally, ignore the measurement +traffic it is receiving, and flood the measurer with more traffic that +it (the measurer) is even sending. + +The security of echo cell verification is discussed in section 3.3.1. + +3.3 Security + +In this section we discuss the security of various aspects of FlashFlow +and the tor changes it requires. + +3.3.1 Echo Cell Verification: Bucket Size + +A smaller bucket size means more cells are checked and FF is more likely +to detect a malicious target. It also means more bookkeeping overhead +(CPU/RAM). + +An adversary that knows bucket_size and cheats on one item out of every +bucket_size items will have a 1/bucket_size chance of getting caught in +the first bucket. This is the worst case adversary. While cheating on +just a single item per bucket yields very little advantage, cheating on +more items per bucket increases the likelihood the adversary gets +caught. Thus only the worst case is considered here. + +In general, the odds the adversary can successfully cheat in a single +bucket are + + (bucket_size-1)/bucket_size + +Thus the odds the adversary can cheat in X consecutive buckets are + + [(bucket_size-1)/bucket_size]^X + +In our case, X will be highly varied: Slow relays won't see very many +buckets, but fast relays will. The damage to the network a very slow +relay can do by faking being only slightly faster is limited. +Nonetheless, for now we motivate the selection of bucket_size with a +slow relay: + + - Assume a very slow relay of 1 Mbit/s capacity that will cheat 1 cell + in each bucket. Assume a 30 second measurement. + - The relay will handle 1*30 = 30 Mbit of traffic during the + measurement, or 3.75 MB, or 3.75 million bytes. + - Cells are 514 bytes. Approximately (e.g. ignoring TLS) 7300 cells + will be sent/recv over the course of the measurement. + - A bucket_size of 50 results in about 146 buckets over the course of + the 30s measurement. + - Therefore, the odds of the adversary cheating successfully as + (49/50)^(146), or about 5.2%. + +This sounds high, but a relay capable of double the bandwidth (2 Mbit/s) +will have (49/50)^(2*146) or 0.2% odds of success, which is quite low. + +Wanting a <1% chance that a 10 Mbit/s relay can successfully cheat +results in a bucket size of approximately 125: + + - 10*30 = 300 Mbit of traffic during 30s measurement. 37.5 million + bytes. + - 37,500,000 bytes / 514 bytes/cell = ~73,000 cells + - bucket_size of 125 cells means 73,000 / 125 = 584 buckets + - (124/125)^(584) = 0.918% chance of successfully cheating + +Slower relays can cheat more easily but the amount of extra weight they +can obtain is insignificant in absolute terms. Faster relays are +essentially unable to cheat. + +3.3.2 Weight Inflation + +Target relays are an active part of the measurement process; they know +they are getting measured. While a relay cannot fake the measurement +traffic, it can trivially stop transferring client background traffic +for the duration of the measurement yet claim it carried some. More +generally, there is no verification of the claimed amount of background +traffic during the measurement. The relay can claim whatever it wants, +but it will not be trusted above the ratio the FlashFlow deployment is +configured to know. This places an easy to understand, firm, and (if set +as we suggest) low cap on how much a relay can inflate its measured +capacity. + +Consider a background/measurement ratio of 1/4, or 25%. Assume the relay +in question has a hard limit on capacity (e.g. from its NIC) of 100 +Mbit/s. The relay is supposed to use up to 25% of its capacity for +background traffic and the remaining 75%+ capacity for measurement +traffic. Instead the relay ceases carrying background traffic, uses all +100 Mbit/s of capacity to handle measurement traffic, and reports ~33 +Mbit/s of background traffic (33/133 = ~25%). FlashFlow would trust this +and consider the relay capable of 133 Mbit/s. (If the relay were to +report more than ~33 Mbit/s, FlashFlow limits it to just ~33 Mbit/s.) +With r=25%, FlashFlow only allows 1.33x weight inflation. + +Prior work shows that Torflow allows weight inflation by a factor of 89x +[0] or even 177x [1]. + +The ratio chosen is a trade-off between impact on background traffic and +security: r=50% allows a relay to double its weight but won't impact +client traffic for relays with steady state throughput below 50%, while +r=10% allows a very low inflation factor but will cause throttling of +client traffic at far more relays. We suggest r=25% (and thus +1/(1-0.25)=1.33x inflation) for a reasonable trade-off between +performance and security. + +It may be possible to catch relays performing this attack, especially if +they literally drop all background traffic during the measurement: have +the measurer (or some party on its behalf) create a regular stream +through the relay and measure the throughput on the stream +before/during/after the measurement. This can be explored longer term. + +3.3.3 Incomplete Authentication + +The short term FlashFlow implementation has the relay set two torrc +options if they would like to allow themselves to be measured: a flag +allowing measurement, and the list of coordinator TLS certificate that +are allowed to start a measurement. + +The relay drops MSM_PARAMS cells from coordinators it does not trust, +and immediately closes the connection after that. A FF coordinator +cannot convince a relay to enter measurement mode unless the relay +trusts its TLS certificate. + +A trusted coordinator specifies in the MSM_PARAMS cell the IP addresses +of the measurers the relay shall expect to connect to it shortly. The +target adds the measurer IP addresses to a whitelist in the DoS +connection limit system, exempting them from any configured connection +limit. If a measurer is behind a NAT, an adversary behind the same NAT +can DoS the relay's available sockets until the end of the measurement. +The adversary could also pretend to be the measurer. Such an adversary +could induce measurement failures and inaccuracies. (Note: the whitelist +is cleared after the measurement is over.) + +4. FlashFlow measurement system: Medium term + +The medium term deployment stage begins after FlashFlow has been +implemented and relays are starting to update to a version of Tor that +supports it. + +We plan to host a FlashFlow deployment consisting of a FF coordinator +and a single FF measurer on a single 1 Gbit/s machine. Data produced by +this deployment will be made available (semi?) publicly, including both +v3bw files and intermediate results. + +Any development changes needed during this time would go through +separate proposals. + +5. FlashFlow measurement system: Long term + +In the long term, finishing-touch development work will be done, +including adding better authentication and measurement scheduling, and +experiments will be run to determine the best way to integrate FlashFlow +into the Tor ecosystem. + +Any development changes needed during this time would go through +separate proposals. + +5.1 Authentication to Target Relay + +Short term deployment already had FlashFlow coordinators using TLS +certificates when connecting to relays, but in the long term, directory +authorities will vote on the consensus parameter for which coordinators +should be allowed to perform measurements. The voting is done in the +same way they currently vote on recommended tor versions. + +FlashFlow measurers will be updated to use TLS certificates when +connecting to relays too. FlashFlow coordinators will update the +contents of MSM_PARAMS cells to contain measurer TLS certificates +instead of IP addresses, and relays will update to expect this change. + +5.2 Measurement Scheduling + +Short term deployment only has one FF deployment running. Long term this +may no longer be the case because, for example, more than one directory +authority decides to adopt it and they each want to run their own +deployment. FF deployments will need to coordinate between themselves +to not measure the same relay at the same time, and to handle new relays +as they join during the middle of a measurement period (during the day). + +The following is quoted from Section 4.3 of the FlashFlow paper. + + To measure all relays in the network, the BWAuths periodically + determine the measurement schedule. The schedule determines when and + by whom a relay should be measured. We assume that the BWAuths have + sufficiently synchronized clocks to facilitate coordinating their + schedules. A measurement schedule is created for each measurement + period, the length p of which determines how often a relay is + measured. We use a measurement period of p = 24 hours. + + To help avoid active denial-of-service attacks on targeted relays, + the measurement schedule is randomized and known only to the + BWAuths. Before the next measurement period starts, the BWAuths + collectively generate a random seed (e.g. using Tor’s + secure-randomness protocol). Each BWAuth can then locally determine + the shared schedule using pseudorandom bits extracted from that + seed. The algorithm to create the schedule considers each + measurement period to be divided into a sequence of t-second + measurement slots. For each old relay, slots for each BWAuth to + measure it are selected uniformly at random without replacement + from all slots in the period that have sufficient unallocated + measurement capacity to accommodate the measurement. When a new + relay appears, it is measured separately by each BWAuth in the first + slots with sufficient unallocated capacity. Note that this design + ensures that old relays will continue to be measured, with new + relays given secondary priority in the order they arrive. + +5.3 Experiments + + [XXX todo] + +5.4 Other Changes/Investigations/Ideas + +- How can FlashFlow data be used in a way that doesn't lead to poor load + balancing given the following items that lead to non-uniform client + behavior: + - Guards that high-traffic HSs choose (for 3 months at a time) + - Guard vs middle flag allocation issues + - New Guard nodes (Guardfraction) + - Exit policies other than default/all + - Directory activity + - Total onion service activity + - Super long-lived circuits +- Add a cell that the target relay sends to the coordinator indicating + its CPU and memory usage, whether it has a shortage of sockets, how + much bandwidth load it has been experiencing lately, etc. Use this + information to lower a relays weight, never increase. +- If FlashFlow and sbws work together (as opposed to FlashFlow replacing + sbws), consider logic for how much sbws can increase/decrease FF + results +- Coordination of multiple FlashFlow deployments: scheduling of + measurements, seeding schedule with shared random value. +- Other background/measurement traffic ratios. Dynamic? (known slow + relay => more allowed bg traffic?) +- Catching relays inflating their measured capacity by dropping + background traffic. +- What to do about co-located relays. Can they be detected reliably? + Should we just add a torrc option a la MyFamily for co-located relays? +- What is the explanation for dennis.jackson's scary graphs in this [2] + ticket? Was it because of the speed test? Why? Will FlashFlow produce + the same behavior? + +6. Citations + +[0] F. Thill. Hidden Service Tracking Detection and Bandwidth Cheating + in Tor Anonymity Network. Master’s thesis, Univ. Luxembourg, 2014. +[1] A. Johnson, R. Jansen, N. Hopper, A. Segal, and P. Syverson. + PeerFlow: Secure Load Balancing in Tor. Proceedings on Privacy + Enhancing Technologies (PoPETs), 2017(2), April 2017. +[2] Mike Perry: Graph onionperf and consensus information from Rob's + experiments https://trac.torproject.org/projects/tor/ticket/33076 +

1 0

[translation/tbmanual-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot
by translation＠torproject.org 23 Apr '20

23 Apr '20

commit b2708777aca7eea0201fd17bb9bafe3c59df5d24 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Apr 23 18:20:44 2020 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot --- contents+it.po | 69 +++++++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 54 insertions(+), 15 deletions(-) diff --git a/contents+it.po b/contents+it.po index 98ae6775a8..a58e5551ac 100644 --- a/contents+it.po +++ b/contents+it.po @@ -90,7 +90,7 @@ msgstr "Download" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) msgid "Running Tor Browser for the First Time" -msgstr "Avviare il browser Tor per la prima volta" +msgstr "Avviare Tor Browser per la prima volta" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) @@ -2478,7 +2478,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "#### The Tor Project website" -msgstr "" +msgstr "#### Sito web del Progetto Tor" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2504,7 +2504,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "#### Connect" -msgstr "" +msgstr "#### Connetti" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2512,6 +2512,8 @@ msgid "" "<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" "/android-connect.png\" alt=\"Connect to Tor Browser for Android\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-connect.png\" alt=\"Connect to Tor Browser for Android\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2531,7 +2533,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "#### Configure" -msgstr "" +msgstr "#### Configura" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2539,6 +2541,8 @@ msgid "" "<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" "/android-configure.png\" alt=\"Configure Tor Browser for Android\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-configure.png\" alt=\"Configure Tor Browser for Android\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2616,6 +2620,9 @@ msgid "" "/android-censored.png\" alt=\"Censored internet on Tor Browser for " "Android\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-censored.png\" alt=\"Censored internet on Tor Browser for " +"Android\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2638,6 +2645,9 @@ msgid "" "/android-select-a-bridge.png\" alt=\"Select a bridge on Tor Browser for " "Android\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-select-a-bridge.png\" alt=\"Select a bridge on Tor Browser for " +"Android\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2646,6 +2656,9 @@ msgid "" "/android-selected-a-bridge.png\" alt=\"Selected a bridge on Tor Browser for " "Android\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-selected-a-bridge.png\" alt=\"Selected a bridge on Tor Browser for " +"Android\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2661,6 +2674,9 @@ msgid "" "/android-provide-a-bridge.png\" alt=\"Provide a bridge on Tor Browser for " "Android\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-provide-a-bridge.png\" alt=\"Provide a bridge on Tor Browser for " +"Android\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2669,16 +2685,19 @@ msgid "" "/android-provided-a-bridge.png\" alt=\"Provide brigde addresses on Tor " "Browser for Android\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-provided-a-bridge.png\" alt=\"Provide brigde addresses on Tor " +"Browser for Android\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "### MANAGING IDENTITIES" -msgstr "" +msgstr "### GESTIRE LE IDENTITÀ" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "#### New Identity" -msgstr "" +msgstr "#### Nuova Identità" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2686,6 +2705,8 @@ msgid "" "<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" "/android-new-identity.png\" alt=\"New Identity on Tor Browser for Android\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-new-identity.png\" alt=\"New Identity on Tor Browser for Android\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2715,7 +2736,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "### SECURITY SETTINGS" -msgstr "" +msgstr "### IMPOSTAZIONI DI SICUREZZA" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2724,6 +2745,9 @@ msgid "" "/android-security-settings.gif\" alt=\"Security settings and security slider" " on Tor Browser for Android\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-security-settings.gif\" alt=\"Security settings and security slider" +" on Tor Browser for Android\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2763,7 +2787,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "### UPDATING" -msgstr "" +msgstr "### AGGIORNAMENTO" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2785,7 +2809,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "##### Google Play" -msgstr "" +msgstr "##### Google Play" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2794,6 +2818,9 @@ msgid "" "/android-update-google-play.png\" alt=\"Updating Tor Browser for Android on " "Google Play\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-update-google-play.png\" alt=\"Updating Tor Browser for Android on " +"Google Play\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2812,7 +2839,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "##### F-Droid" -msgstr "" +msgstr "##### F-Droid" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2821,6 +2848,9 @@ msgid "" "/android-update-f-droid.png\" alt=\"Updating Tor Browser for Android on " "F-droid\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-update-f-droid.png\" alt=\"Updating Tor Browser for Android on " +"F-droid\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2880,7 +2910,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "### UNINSTALLING" -msgstr "" +msgstr "### DISINSTALLAZIONE" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2896,6 +2926,9 @@ msgid "" "/android-uninstall-google-play.png\" alt=\"Uninstalling Tor Browser for " "Android on Google Play\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-uninstall-google-play.png\" alt=\"Uninstalling Tor Browser for " +"Android on Google Play\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2918,6 +2951,9 @@ msgid "" "/android-uninstall-f-droid.png\" alt=\"Uninstalling Tor Browser for Android " "on F-droid\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-uninstall-f-droid.png\" alt=\"Uninstalling Tor Browser for Android " +"on F-droid\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2938,6 +2974,9 @@ msgid "" "/android-uninstall-device-settings.png\" alt=\"Uninstalling Tor Browser for " "Android using device app settings\">" msgstr "" +"<img style=\"max-width:300px\" class=\"col-md-6\" src=\"../../static/images" +"/android-uninstall-device-settings.png\" alt=\"Uninstalling Tor Browser for " +"Android using device app settings\">" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -3003,7 +3042,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "#### Orfox" -msgstr "" +msgstr "#### Orfox" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -3036,12 +3075,12 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "Android was released." -msgstr "" +msgstr "Android è stato rilasciato." #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "#### Orbot" -msgstr "" +msgstr "#### Orbot" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -3079,7 +3118,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "### Tor Browser for iOS" -msgstr "" +msgstr "### Tor Browser per iOS" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body)

1 0

[translation/communitytpo-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=communitytpo-contentspot
by translation＠torproject.org 23 Apr '20

23 Apr '20

commit 8e2207e0aae792a07fc82f18a336ad2d28553e31 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Apr 23 18:15:34 2020 +0000 https://gitweb.torproject.org/translation.git/commit/?h=communitytpo-conten… --- contents+it.po | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/contents+it.po b/contents+it.po index d4a04f40b6..abd83005e2 100644 --- a/contents+it.po +++ b/contents+it.po @@ -4,7 +4,6 @@ # mattia_b89 <mattia.b89(a)gmail.com>, 2019 # Hiro 7 <hiro(a)torproject.org>, 2019 # Giuseppe Pignataro <rogepix(a)gmail.com>, 2019 -# Giandomenico Lombardi <transifex.com(a)l1t.it>, 2019 # Lorenzo Mazza <lor.mazza81(a)outlook.com>, 2019 # Giovanni Pellerano <giovanni.pellerano(a)evilaliv3.org>, 2019 # erinm, 2019 @@ -16,6 +15,7 @@ # Emma Peel, 2020 # Gabriele <gabboxl0(a)gmail.com>, 2020 # Him-Calan Je Distros <hicalje(a)protonmail.com>, 2020 +# Giandomenico Lombardi <transifex.com(a)l1t.it>, 2020 # msgid "" msgstr "" @@ -23,7 +23,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2019-12-11 12:15+CET\n" "PO-Revision-Date: 2019-12-11 10:50+0000\n" -"Last-Translator: Him-Calan Je Distros <hicalje(a)protonmail.com>, 2020\n" +"Last-Translator: Giandomenico Lombardi <transifex.com(a)l1t.it>, 2020\n" "Language-Team: Italian (https://www.transifex.com/otf/teams/1519/it/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -952,7 +952,7 @@ msgstr "" #: https//community.torproject.org/relay/types-of-relays/ #: (content/relay-operations/types-of-relays/contents+en.lrpage.body) msgid "# Exit relay" -msgstr "" +msgstr "# Nodo di uscita" #: https//community.torproject.org/relay/types-of-relays/ #: (content/relay-operations/types-of-relays/contents+en.lrpage.body) @@ -1031,7 +1031,7 @@ msgstr "" #: https//community.torproject.org/relay/types-of-relays/ #: (content/relay-operations/types-of-relays/contents+en.lrpage.body) msgid "# Bridge" -msgstr "" +msgstr "# Bridge" #: https//community.torproject.org/relay/types-of-relays/ #: (content/relay-operations/types-of-relays/contents+en.lrpage.body) @@ -1248,7 +1248,7 @@ msgstr "" #: https//community.torproject.org/relay/community-resources/ #: (content/relay-operations/community-resources/contents+en.lrpage.body) msgid "## Torservers.net" -msgstr "" +msgstr "## Torservers.net" #: https//community.torproject.org/relay/community-resources/ #: (content/relay-operations/community-resources/contents+en.lrpage.body) @@ -1337,7 +1337,7 @@ msgstr "" #: https//community.torproject.org/relay/community-resources/ #: (content/relay-operations/community-resources/contents+en.lrpage.body) msgid "## At your university" -msgstr "" +msgstr "## Alla tua università" #: https//community.torproject.org/relay/community-resources/ #: (content/relay-operations/community-resources/contents+en.lrpage.body) @@ -1366,7 +1366,7 @@ msgstr "" #: https//community.torproject.org/relay/community-resources/ #: (content/relay-operations/community-resources/contents+en.lrpage.body) msgid "## At your company or organization" -msgstr "" +msgstr "## Nella tua azienda o organizzazione" #: https//community.torproject.org/relay/community-resources/ #: (content/relay-operations/community-resources/contents+en.lrpage.body) @@ -1418,7 +1418,7 @@ msgstr "" #: https//community.torproject.org/relay/community-resources/ #: (content/relay-operations/community-resources/contents+en.lrpage.body) msgid "# Other resources" -msgstr "" +msgstr "# Altre risorse" #: https//community.torproject.org/relay/community-resources/ #: (content/relay-operations/community-resources/contents+en.lrpage.body) @@ -1451,7 +1451,7 @@ msgstr "" #: https//community.torproject.org/relay/technical-considerations/ #: (content/relay-operations/technical-considerations/contents+en.lrpage.title) msgid "Technical considerations" -msgstr "" +msgstr "Considerazioni tecniche" #: https//community.torproject.org/relay/technical-considerations/ #: (content/relay-operations/technical-considerations/contents+en.lrpage.subtitle) @@ -1639,22 +1639,22 @@ msgstr "" #: https//community.torproject.org/relay/technical-considerations/ #: (content/relay-operations/technical-considerations/contents+en.lrpage.body) msgid "* OVH SAS (AS16276)" -msgstr "" +msgstr "* OVH SAS (AS16276)" #: https//community.torproject.org/relay/technical-considerations/ #: (content/relay-operations/technical-considerations/contents+en.lrpage.body) msgid "* Online S.a.s. (AS12876)" -msgstr "" +msgstr "* Online S.a.s. (AS12876)" #: https//community.torproject.org/relay/technical-considerations/ #: (content/relay-operations/technical-considerations/contents+en.lrpage.body) msgid "* Hetzner Online GmbH (AS24940)" -msgstr "" +msgstr "* Hetzner Online GmbH (AS24940)" #: https//community.torproject.org/relay/technical-considerations/ #: (content/relay-operations/technical-considerations/contents+en.lrpage.body) msgid "* DigitalOcean, LLC (AS14061)" -msgstr "" +msgstr "* DigitalOcean, LLC (AS14061)" #: https//community.torproject.org/relay/technical-considerations/ #: (content/relay-operations/technical-considerations/contents+en.lrpage.body) @@ -1736,7 +1736,7 @@ msgstr "" #: https//community.torproject.org/relay/getting-help/ #: (content/relay-operations/getting-help/contents+en.lrpage.title) msgid "Getting help" -msgstr "" +msgstr "Ottieni aiuto" #: https//community.torproject.org/relay/getting-help/ #: (content/relay-operations/getting-help/contents+en.lrpage.subtitle) @@ -1763,7 +1763,7 @@ msgstr "" #: https//community.torproject.org/training/risks/ #: (content/training/risks/contents+en.lrpage.title) msgid "Risks" -msgstr "" +msgstr "Rischi" #: https//community.torproject.org/training/risks/ #: (content/training/risks/contents+en.lrpage.subtitle)

1 0

[chutney/master] Merge remote-tracking branch 'tor-github/pr/69'
by nickm＠torproject.org 23 Apr '20

23 Apr '20

commit 76ba7f8805af75df38fad35a5c3ba9052cde5e91 Merge: 38e8883 181466b Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 23 13:58:22 2020 -0400 Merge remote-tracking branch 'tor-github/pr/69' lib/chutney/TorNet.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

1 0

[chutney/master] Remove the bufsize argument
by nickm＠torproject.org 23 Apr '20

23 Apr '20

commit 181466b999ab8f0547d766d9e84570cb0d08b1a0 Author: MrSquanchee <usuraj35(a)gmail.com> Date: Thu Apr 23 17:30:28 2020 +0530 Remove the bufsize argument From subprocess.check_output() in run_tor(). --- lib/chutney/TorNet.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib/chutney/TorNet.py b/lib/chutney/TorNet.py index 6b5b88e..70b302b 100644 --- a/lib/chutney/TorNet.py +++ b/lib/chutney/TorNet.py @@ -244,8 +244,7 @@ def run_tor(cmdline, exit_on_missing=True): try: stdouterr = subprocess.check_output(cmdline, stderr=subprocess.STDOUT, - universal_newlines=True, - bufsize=-1) + universal_newlines=True) debug(stdouterr) except OSError as e: # only catch file not found error

1 0

[translation/tbmanual-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot
by translation＠torproject.org 23 Apr '20

23 Apr '20

commit 718de57f31f435584b299b141efde952294caf90 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Apr 23 17:51:02 2020 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot --- contents+it.po | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/contents+it.po b/contents+it.po index 0cd5486677..98ae6775a8 100644 --- a/contents+it.po +++ b/contents+it.po @@ -5,7 +5,6 @@ # Hiro 7 <hiro(a)torproject.org>, 2019 # Fabio Ottone, 2019 # SebastianoPistore <SebastianoPistore.info(a)protonmail.ch>, 2019 -# Giandomenico Lombardi <transifex.com(a)l1t.it>, 2019 # Thomas Di Cristofaro <inactive+ThomasDiCristofaro(a)transifex.com>, 2019 # fabio carletti <fabiocarlettiryuw(a)gmail.com>, 2019 # Emma Peel, 2020 @@ -13,6 +12,7 @@ # Davide Sant <spuuu(a)outlook.it>, 2020 # erinm, 2020 # Luke <94lukecatellani(a)gmail.com>, 2020 +# Giandomenico Lombardi <transifex.com(a)l1t.it>, 2020 # msgid "" msgstr "" @@ -20,7 +20,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2020-04-12 08:00+CET\n" "PO-Revision-Date: 2018-11-14 12:31+0000\n" -"Last-Translator: Luke <94lukecatellani(a)gmail.com>, 2020\n" +"Last-Translator: Giandomenico Lombardi <transifex.com(a)l1t.it>, 2020\n" "Language-Team: Italian (https://www.transifex.com/otf/teams/1519/it/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -90,7 +90,7 @@ msgstr "Download" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) msgid "Running Tor Browser for the First Time" -msgstr "" +msgstr "Avviare il browser Tor per la prima volta" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) @@ -110,7 +110,7 @@ msgstr "Ponti" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) msgid "Managing Identities" -msgstr "" +msgstr "Gestire le identità" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) @@ -159,7 +159,7 @@ msgstr "Problemi conosciuti" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.title) msgid "Mobile Tor" -msgstr "" +msgstr "Tor Mobile" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) @@ -169,7 +169,7 @@ msgstr "Diventare un traduttore Tor" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) msgid "Making Tor Browser Portable" -msgstr "" +msgstr "Rendere Tor Browser Portatile" #: https//tb-manual.torproject.org/menu/ #: (content/menu/contents+en.lrtopic.body) @@ -647,7 +647,7 @@ msgstr "" #: https//tb-manual.torproject.org/running-tor-browser/ #: (content/running-tor-browser/contents+en.lrtopic.body) msgid "<img class=\"col-md-6\" src=\"../../static/images/pluggable-transport.png\">" -msgstr "" +msgstr "<img class=\"col-md-6\" src=\"../../static/images/pluggable-transport.png\">" #: https//tb-manual.torproject.org/running-tor-browser/ #: (content/running-tor-browser/contents+en.lrtopic.body) @@ -1022,6 +1022,8 @@ msgid "" "<img class=\"col-md-6\" align=\"right\" hspace=\"5\" " "src=\"../../static/images/request-a-bridge.png\">" msgstr "" +"<img class=\"col-md-6\" align=\"right\" hspace=\"5\" " +"src=\"../../static/images/request-a-bridge.png\">" #: https//tb-manual.torproject.org/bridges/ #: (content/bridges/contents+en.lrtopic.body) @@ -1094,7 +1096,7 @@ msgstr "" #: https//tb-manual.torproject.org/bridges/ #: (content/bridges/contents+en.lrtopic.body) msgid "Click \"Connect\" to save your settings." -msgstr "" +msgstr "Clicca 'Connetti' per salvare le impostazioni." #: https//tb-manual.torproject.org/bridges/ #: (content/bridges/contents+en.lrtopic.body) @@ -2327,7 +2329,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "### Tor Browser for Android" -msgstr "" +msgstr "### Tor Browser per Android" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2384,7 +2386,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "#### Google Play" -msgstr "" +msgstr "#### Google Play" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) @@ -2396,7 +2398,7 @@ msgstr "" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body) msgid "#### F-Droid" -msgstr "" +msgstr "#### F-Droid" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body)

1 0

[chutney/master] add documentation for Node.specialize and Node.__init__
by nickm＠torproject.org 23 Apr '20

23 Apr '20

commit 38e8883410966a748624cd37ab520ff99d3c495f Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 23 12:53:22 2020 -0400 add documentation for Node.specialize and Node.__init__ --- lib/chutney/TorNet.py | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/lib/chutney/TorNet.py b/lib/chutney/TorNet.py index 6b5b88e..4119a18 100644 --- a/lib/chutney/TorNet.py +++ b/lib/chutney/TorNet.py @@ -427,6 +427,12 @@ class Node(object): # Users are expected to call these: def __init__(self, parent=None, **kwargs): + """Create a new Node. + + Initial fields in this Node's environment are set from 'kwargs'. + + Any fields not found there will be searched for in 'parent'. + """ self._parent = parent self._env = self._createEnviron(parent, kwargs) self._builder = None @@ -436,6 +442,9 @@ class Node(object): return [Node(self) for _ in range(N)] def specialize(self, **kwargs): + """Return a new Node based on this node's value as its defaults, + but with the values from 'kwargs' (if any) overriding them. + """ return Node(parent=self, **kwargs) def set_runtime(self, key, fn):

1 0

[translation/donatepages-messagespot] https://gitweb.torproject.org/translation.git/commit/?h=donatepages-messagespot
by translation＠torproject.org 23 Apr '20

23 Apr '20

commit d5208bde08dd310674b951678716f8295db7f7ea Author: Translation commit bot <translation(a)torproject.org> Date: Thu Apr 23 15:45:41 2020 +0000 https://gitweb.torproject.org/translation.git/commit/?h=donatepages-message… --- locale/fa/LC_MESSAGES/messages.po | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/locale/fa/LC_MESSAGES/messages.po b/locale/fa/LC_MESSAGES/messages.po index 467d9d61cd..f5a7e149de 100644 --- a/locale/fa/LC_MESSAGES/messages.po +++ b/locale/fa/LC_MESSAGES/messages.po @@ -727,7 +727,7 @@ msgstr "" #: tmp/cache_locale/c7/c763c19bb6abb9330294c550c8241bb3874e3b4e17fb6e7b15db26c60df8d5fe.php:253 msgid "Tor at the Heart of Internet Freedom" -msgstr "" +msgstr "تور در قبل آزادی اینترنت" #: tmp/cache_locale/c7/c763c19bb6abb9330294c550c8241bb3874e3b4e17fb6e7b15db26c60df8d5fe.php:257 msgid "Powering the Digital Resistance" @@ -1249,6 +1249,8 @@ msgid "" "Checks</a> or <a class=\"hyperlinks links\" href=\"/%langcode%/donor-faq" "#donate-anonymous\">Money Orders</a>" msgstr "" +"</a> یا <a class=\"hyperlinks links\" href=\"/%langcode%/donor-faq#donate-" +"anonymous\">سفارش های پولی</a> را بررسی می کند" #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:138 msgid "Stock Donation" @@ -2454,6 +2456,8 @@ msgid "" "The fastest way to find out if your company matches donations is usually by " "checking with your HR department." msgstr "" +"سریع ترین شیوه برای متوجه شدن این موضوع که شرکت شما چنین برنامه ای دارد این" +" است که از بخش منابع انسانی سوال بپرسید." #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:687 #: tmp/cache_locale/0e/0e65c68f2900f432bc062864e7bafc989d6286e272f5e98882a99f52ea4c5c89.php:506 @@ -2583,7 +2587,7 @@ msgstr "" #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:745 #: tmp/cache_locale/0e/0e65c68f2900f432bc062864e7bafc989d6286e272f5e98882a99f52ea4c5c89.php:556 msgid "Can I donate my airline miles, flight vouchers, or hotel points?" -msgstr "" +msgstr "آیا می توانم کوپن سفر، بلیط هواپیما یا اتاق هتل اهدا کنم؟" #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:751 #: tmp/cache_locale/0e/0e65c68f2900f432bc062864e7bafc989d6286e272f5e98882a99f52ea4c5c89.php:562 @@ -2591,6 +2595,8 @@ msgid "" "We would like to accept your miles, vouchers and hotel points, and in the " "future we may be able to." msgstr "" +"ما دوست داریم تا این موارد را بپذیریم و شاید در آینده قادر به انجام آن " +"باشیم." #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:757 #: tmp/cache_locale/0e/0e65c68f2900f432bc062864e7bafc989d6286e272f5e98882a99f52ea4c5c89.php:568 @@ -2638,6 +2644,8 @@ msgid "" "Your company could match donations made by its employees to the Tor Project" "--that would be wonderful." msgstr "" +"شرکت شما می تواند کمک های مالی انجام شده توسط کارمندانش را همخوانی کند - این" +" عالی خواهد بود." #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:787 #: tmp/cache_locale/0e/0e65c68f2900f432bc062864e7bafc989d6286e272f5e98882a99f52ea4c5c89.php:600 @@ -2645,6 +2653,8 @@ msgid "" "Your company may operate a corporate foundation that gives out grants, and " "if so, you should encourage it to fund us." msgstr "" +"شرکت شما ممکن است یک بنیاد شرکتی بگرداند که اگر چنین است، خوب است آن‌ها را " +"تشویق کنید تا به ما کمک کنند." #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:789 msgid "" @@ -3414,6 +3424,10 @@ msgid "" "in our defense against the growing threats to privacy, freedom of " "expression, and access to information online." msgstr "" +"قهرمانان حریم خصوصی چیزی حدود 1,000$ یا بیشتر اهدا می کنند که این یک منبع " +"سرمایه گذاری قابل اعتماد و مداوم خواهد بود و به ما در دفاع در برابر خطرات رو" +" به رشد در حریم خصوصی، آزادی و اظهار نظر و دسترسی به اطلاعات آنلاین کمک " +"خواهد کرد." #: tmp/cache_locale/02/023cc9edfe6c60b72788b97f6a123fde6020d003845e03b26b572d864d6eb3de.php:87 msgid ""

1 0