July 2018 - tor-commits - lists.torproject.org

[translation/support-faq] Update translations for support-faq
by translation＠torproject.org 05 Jul '18

05 Jul '18

commit e0c97b906f8290657dd8bf323488b7cc98a42718 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Jul 5 07:19:09 2018 +0000 Update translations for support-faq --- tr.json | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tr.json b/tr.json index f4e15e3c8..5e1614b3c 100644 --- a/tr.json +++ b/tr.json @@ -9,7 +9,7 @@ "id": "#sss-2", "control": "sss-2", "title": "Sitemiz bir sansürleyici tarafından engelleniyor. Tor Browser kullanıcıların sitemize erişmelerine yardımcı olur mu?", - "description": "Tor Browser can certainly help people access your website in places where it is blocked. Most of the time, simply downloading the Tor Browser and then using it to navigate to the blocked site will allow access. In places where there is heavy censorship, we have a number of censorship circumvention options available, including pluggable transports. For more information, please see the Tor Browser User Manual section on censorship." + "description": "Erişimin engellendiği durumlarda Tor Browser kişilerin web sitenize erişmelerine kesinlikle yardımcı olabilir. Çoğu zaman, sadece Tor Tarayıcısını indirip, engellenen siteye gitmek için kullanmak erişime izin verecektir. Ağır bir sansürün olduğu yerlerde, takılabilir taşımacılık da dahil olmak üzere bir dizi sansür atlatma seçeneğimiz mevcut. Daha fazla bilgi için, lütfen sansür üzerindeki Tor Tarayıcı Kullanım Kılavuzu bölümüne bakın." }, "faq-3": { "id": "#sss-3", @@ -21,12 +21,12 @@ "id": "#sss-4", "control": "sss-4", "title": "Tor tarayacısını hangi platformlar için uygun?", - "description": "Tor Browser is currently available on Windows, Linux and macOS (OS X). For Android, The Guardian Project maintains the Tor-powered apps Orbot and Orfox. There is no official version of Tor for iOS yet, though we recommend Onion Browser." + "description": "Tor Browser şu anda Windows, Linux ve macOS'ta (OS X) mevcuttur. Android için The Guardian Project, Tor-powered uygulamaları olan Orbot ve Orfox'u sürdürüyor. Henüz iOS için resmi bir sürümü yok, ancak Onion Browser'ı öneriyoruz." }, "faq-5": { "id": "#sss-5", "control": "sss-5", "title": "VPN'le tor kullanabilirmiyim?", - "description": "Generally speaking, we don't recommend using a VPN with Tor unless you're an advanced user who knows how to configure both in a way that doesn't compromise your privacy. Learn more about combining Tor + VPN." + "description": "Genel olarak, gizliliğinizden ödün vermeyen bir şekilde ikisini bir arada nasıl yapılandırılacağını bilen ileri düzey bir kullanıcı değilseniz, Tor ile bir VPN kullanmanızı önermiyoruz. Tor + VPN'yi birleştirmeyle ilgili daha fazla bilgi edinin." } }

1 0

[translation/support-connecting] Update translations for support-connecting
by translation＠torproject.org 05 Jul '18

05 Jul '18

commit 9e35ec052610f28daa2910d9986ed26384a1907d Author: Translation commit bot <translation(a)torproject.org> Date: Thu Jul 5 07:19:01 2018 +0000 Update translations for support-connecting --- tr.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tr.json b/tr.json index 9388eb3fc..9321608ce 100644 --- a/tr.json +++ b/tr.json @@ -14,7 +14,7 @@ "connecting-3": { "id": "#baglanti-3", "control": "baglanti-3", - "title": "I cannot reach X.onion!", + "title": "X.onion'a ulaşamıyorum!", "description": "If you cannot reach the onion service you desire, make sure that you have entered the 16-character onion address correctly: even a small mistake will stop Tor Browser from being able to reach the site. If you are still unable to connect to the onion service, please try again later. There may be a temporary connection issue, or the site operators may have allowed it to go offline without warning.You can also ensure that you're able to access other onion services by connecting to <a href=\"http://3g2upl4pq6kufc4m.onion\">DuckDuckGo</a>'s Onion Service." } }

1 0

[translation/support-tbb] Update translations for support-tbb
by translation＠torproject.org 05 Jul '18

05 Jul '18

commit f2de8f27bb87e70b96cbb054eed281c3478dfdaf Author: Translation commit bot <translation(a)torproject.org> Date: Thu Jul 5 06:49:35 2018 +0000 Update translations for support-tbb --- tr.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tr.json b/tr.json index 44cbf9201..cdce6dd72 100644 --- a/tr.json +++ b/tr.json @@ -86,8 +86,8 @@ "tbb-14": { "id": "#torbrowser-14", "control": "torbrowser-14", - "title": "Should I install a new add-on or extension in Tor Browser, like AdBlock Plus or uBlock Origin?", - "description": "It's strongly discouraged to install new add-ons in Tor Browser, because they can compromise both your privacy and your security. Plus, Tor Browser already comes installed with two add-ons — HTTPS Everywhere and NoScript — which give you added protection." + "title": "Tor Browser'da, AdBlock Plus veya uBlock Origin gibi yeni bir eklenti veya uzantı kurmalı mıyım?", + "description": "Tor Browser'da yeni eklentiler yüklemek kesinlikle tavsiye edilmez, çünkü hem gizliliğinizi hem de güvenliğinizi tehlikeye atabilirler. Ayrıca, Tor Browser zaten size ek koruma sağlayan iki eklenti olan HTTPS Everywhere ve NoScript ile birlikte gelir." }, "tbb-15": { "id": "#torbrowser-15",

1 0

[translation/support-faq] Update translations for support-faq
by translation＠torproject.org 05 Jul '18

05 Jul '18

commit 4c0b09e8cc074db74c92ee531bdea185455fb6f8 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Jul 5 06:49:06 2018 +0000 Update translations for support-faq --- tr.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tr.json b/tr.json index 66a6b47cb..f4e15e3c8 100644 --- a/tr.json +++ b/tr.json @@ -14,8 +14,8 @@ "faq-3": { "id": "#sss-3", "control": "sss-3", - "title": "Should I install a new add-on or extension in Tor Browser, like AdBlock Plus or uBlock Origin?", - "description": "It's strongly discouraged to install new add-ons in Tor Browser, because they can compromise both your privacy and your security. Plus, Tor Browser already comes installed with two add-ons — HTTPS Everywhere and NoScript — which give you added protection." + "title": "Tor Browser'da, AdBlock Plus veya uBlock Origin gibi yeni bir eklenti veya uzantı kurmalı mıyım?", + "description": "Tor Browser'da yeni eklentiler yüklemek kesinlikle tavsiye edilmez, çünkü hem gizliliğinizi hem de güvenliğinizi tehlikeye atabilirler. Ayrıca, Tor Browser zaten size ek koruma sağlayan iki eklenti olan HTTPS Everywhere ve NoScript ile birlikte gelir." }, "faq-4": { "id": "#sss-4",

1 0

[torspec/master] Replace proposal 295 with the right version :/
by nickm＠torproject.org 04 Jul '18

04 Jul '18

commit 09220cc5b7da9aae30549f0d58cd9de0d9db447d Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jul 4 16:41:58 2018 -0400 Replace proposal 295 with the right version :/ --- proposals/000-index.txt | 4 +- proposals/295-relay-crypto-with-atl.txt | 469 ++++++++++++++++---------------- 2 files changed, 230 insertions(+), 243 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index d9c7e93..6b3295f 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -215,7 +215,7 @@ Proposals by number: 292 Mesh-based vanguards [ACCEPTED] 293 Other ways for relays to know when to publish [OPEN] 294 TLS 1.3 Migration [DRAFT] -295 Using the ATL construction for relay cryptography (solving the crypto-tagging attack) [OPEN] +295 Using ADL-GCM for relay cryptography (solving the crypto-tagging attack) [OPEN] Proposals by status: @@ -245,7 +245,7 @@ Proposals by status: 287 Reduce circuit lifetime without overloading the network 289 Authenticating sendme cells to mitigate bandwidth attacks 293 Other ways for relays to know when to publish [for 0.3.5] - 295 Using the ATL construction for relay cryptography (solving the crypto-tagging attack) + 295 Using ADL-GCM for relay cryptography (solving the crypto-tagging attack) ACCEPTED: 188 Bridge Guards and other anti-enumeration defenses 249 Allow CREATE cells with >505 bytes of handshake data diff --git a/proposals/295-relay-crypto-with-atl.txt b/proposals/295-relay-crypto-with-atl.txt index 74e31b1..73eb98b 100644 --- a/proposals/295-relay-crypto-with-atl.txt +++ b/proposals/295-relay-crypto-with-atl.txt @@ -1,10 +1,9 @@ Filename: 295-relay-crypto-with-atl.txt -Title: Using the ATL construction for relay cryptography (solving the crypto-tagging attack) +Title: Using ADL-GCM for relay cryptography (solving the crypto-tagging attack) Author: Tomer Ashur Created: 09 Apr 2018 Status: Open - 0. Context Although Crypto Tagging Attacks were identified already in the @@ -13,8 +12,8 @@ Status: Open improved relay encryption protocols for Tor cells) Nick Mathewson discussed two approaches to stymie tagging attacks and generally improve Tor's cryptography. In Proposal 261 (AEZ for relay - cryptography) Nick put forward a concrete approach which uses the - tweakable wide-block cipher AEZ. + cryptography) Mathewson puts forward a concrete approach which uses + the tweakable wide-block cipher AEZ. 1. Motivation @@ -27,250 +26,238 @@ Status: Open describes an improved algorithm for circuit encryption based on CTR-mode which is already used in Tor, and an additional component for hashing. When this additional component is GHash, a GCM-based - solution can be used from the OpenSSL library. If a solution that is - based solely on components that already exist in Tor is desirable, - SHA-1 can be used for hashing (however, this is highly discouraged as - SHA-1 is broken!). + solution can be used from the OpenSSL library. Incidentally, and similar to Proposal 261, this proposal employs the ENCODE-then-ENCIPHER approach thus it improves Tor's E2E integrity by using (sufficiently enough) redundancy. - For more information about the scheme and a security proof for its - RUP-security see + For more information about the scheme and a security proof for its + RUP-security see + + Tomer Ashur, Orr Dunkelman, Atul Luykx: Boosting Authenticated + Encryption Robustness with Minimal Modifications. CRYPTO (3) + 2017: 3-33 available online at https://eprint.iacr.org/2017/239 . + +2.1. Cryptographic algorithms + + As an encryption primitive we use AES. We denote one call to the + primitive by E(·), e.g., + + Z = E_k(X) + + where k is a K-bit key, X is the input to AES and Z is the output. We + omit k where it is irrelevant or is clear from context. While we + propose to set K=256 to ensure long-term post-quantum resistance, we + stress that the solution also works for other key lengths. + + To encrypt, we use AES is counter mode and a nonce N to produce a + random bit stream, e.g., - Tomer Ashur, Orr Dunkelman, Atul Luykx: Boosting Authenticated - Encryption Robustness with Minimal Modifications. CRYPTO (3) 2017: - 3-33 available online at https://eprint.iacr.org/2017/239 . + CTR(N) = E(N)||E(N+1)||...||E(N+l) = z_1||z_2||...||Z_{n+1} = Z -2.1 An instructive 1-node circuit + and XOR Z with the message M to produce the ciphertext C, e.g., + + C = Z ^ M + + For authentication, we use the universal hash function GHASH and a + key k, e.g., + + T = H(K||X) = H_k(X) + + where K is a 256-bit key, X an arbitrary length string, and T a + unique authentication tag for X. While we propose to set K=256 to + ensure long-term post-quantum resistance, we stress that the solution + works for any universal hash function as well as for keys of length + K!=256. + +3. The proposed solution + +3.1 An overview of the proposed solution Noting that in CTR-mode the nonce is essential for the encryption/decryption operations, the proposed solution is based on - encrypting its value in such a way that any change to the ciphertext - or the tag (e.g., through a tagging attack) would randomize the nonce - and result in a random value as the output of CTR-mode. - - The basic crypto components of the proposal are: - * a block cipher E(·) - * A universal hash function, H(·); - - Using the block cipher E(·) and a non-repeating nonce N, one can - construct the CTR mode-of-operation: - - CTR(N) = E(N)||E(N+1)||...||E(N+l) - - For simplicity, let us for now consider normal encryption using - CTR-mode (This is akin to building a circuit with a single node. In - the sequel we will see what happens when this idea is used in a 3-node - circuit): - - * Input: a nonce N, a message M = (m_0,...,m_l) - 1. (z_0,...,z_l) = CTR(N) - 2. (c_0,...,c_l) = (z_0 ^ m_0, ... z_l ^ m_l) - - The client sends C = (c_0,...,c_l) to the receiver which repeats Step - (1) to generate the random stream Z = (z_0,...,z_l) and recovers the - message through M = C ^ Z. A protocol using this scheme is vulnerable - to the crypto tagging attack due to the malleability of - CTR-mode. Indeed, since Z depends only on N rather than on the - message M itself, a change to a ciphertext bit affects the respective - plaintext bit and nothing else. - - Our solution is based on the idea that linking N and C makes it - impossible to change C without affecting N (and hence Z) in such a - way that it is impossible to recover M. This can be done by extending - the protocol in the following way: - - 3. X = H(C) - 4. S = X ^ E(N ^ X) - - Now, instead of sending C, the client sends C||S to the receiver. To - decrypt, the receiver first repeats Step (3) to obtain X, then - inverts Step (4) to obtain N: N = D(S ^ X) ^ X (where D(·) is the - inverse function of E(·)). Then, having obtained N, the receiver - continues to decrypt C as before. If the receiver already knows N - (e.g., in the case of a synchronized nonce), they can authenticate C - by comparing N = D(S ^ X) ^ X to the nonce they expect. - - Let us consider what happens when a change is made to C. Let C' be a - variant of C with one or more bits flipped. Since H(·) is a universal - hash function, X' = H(C' ≠ C) is random. Trying to execute D(S ^ X') - ^ X' would result in a random N' ≠ N which in turn would result in a - random Z' (and hence a random M'). Similarly for a change in S. - -2.2 Extending to a 3-node Tor circuit - - The Tor protocol uses layered encryption to encapsulate the - message. Generally speaking, this can be written as: - - * input: synchronized nonces (N^0, N^1, N^2), a message M = (m_0,...,m_l) - 1. (z^2_0,...,z^2_l) = CTR(N^2) - 2. (c^2_0,...,c^2_l) = (z^2_0 ^ m_0, ... z^2_l ^ m_l) - 3. (z^1_0,...,z^1_l) = CTR(N^1) - 4. (c^1_0,...,c^1_l) = (z^1_0 ^ c^2_0, ... z^1_l ^ c^2_l) - 5. (z^0_0,...,z^0_l) = CTR(N^0) - 6. (c^0_0,...,c^0_l) = (z^0_0 ^ c^1_0, ... z^0_l ^ c^0_l) - - The crypto-tagging stems from the fact that a change to C affects M - directly since all z^j_i depend only on N^j rather than on C^j. - - An extension of the 1-layer solution presented in Section 2.1 would - look like this: - - * Input: a nonce N, a message M = (m_0,...,m_l) - 1. (z^2_0,...,z^2_l) = CTR(N) - 2. (c^2_0,...,c^2_l) = (z^2_0 ^ m_0, ... z^2_l ^ m_l) - 3. X^2 = H(C^2) - 4. S^2 = X^2 ^ E(N^2 ^ X^2) - - 5. (z^1_0,...,z^1_l) = CTR(S^2) - 6. (c^1_0,...,c^1_l) = (z^1_0 ^ c^2_0, ... z^1_l ^ c^2_l) - 7. X^1 = H(C^1) - 8. S^1 = X^1 ^ E(S^2 ^ X^1) - - 9. (z^0_0,...,z^0_l) = CTR(S^1) - 10. (c^0_0,...,c^0_l) = (z^0_0 ^ c^1_0, ... z^1_l ^ c^0_l) - 11. X^0 = H(C^0) - 12. S^0 = X^0 ^ E(S^1 ^ X^0) - - The client sends the message C^0||S^0 = ((c^0_0,...,c^0_l)||S^0) to - the guard. To decrypt, the guard repeats Step (11) and inverts Step - (12) to obtain S^1 which it uses to generate Z^0 and decrypt C^0 into - C^1. The guard then forwards C^1||S^1 to the middle node which - repeats this process and forwards C^2||S^2 to the exit. The exit - removes the final encryption layer and processes the cell as in the - old protocol. - - Let us now consider what happens when the crypto tagging attack is - applied to this protocol. Without loss of generality, after inverting - Step (11) the guard tags either C^1 or S^1 and forwards C'^1||S'^1 to - the middle node. The middle node, unaware of the change follows the - protocol to decrypt C'^1||S'^1 which results in a random string as - per the explanation above. Since both CircID and CMD are not part of - the payload, the middle node can still forward the random string - (unaware of this fact) to the exit node. Upon receiving the random - string, the exit node decrypts it, sees that the 'Rec' field is not - all-zero and acts accordingly. - - -3. Design considerations - -3.1 Choice of primitives - - We stress that the proposed protocol is primitive agnostic. - - Noting that Tor currently uses AES_CTR we tried to design a solution - that requires only minimal changes. Most importantly, the encryption - is still performed using CTR-mode, and can be instantiated using - AES_CTR (however, the solution works just as well with any other - block cipher). - - The hashing of the ciphertext requires a universal hash function. The - GCM mode of operation uses CTR+GHash and is available from the - OpenSSL crypto library which is already used within Tor. Any - available universal hash function can be used instead of GHash if the - latter introduces an unacceptable latency. - - The nonce-encryption step uses a tweakable block cipher. In the - example above we used the XEX trick to transform a "regular" block - cipher into a tweakable block cipher which allows reusing whatever - underlying primitive is used in CTR-mode. A tweakable block cipher - can be used directly (with X as the tweak) if one is available but - this is not required. - -3.2 Security requirements - - In Proposal 202, Nick Mathewson outlined the security requirements - for any solution. We copy them here verbatim and discuss how each of - them is addressed in the proposed solution: - - * " ... we'd like any attacker who controls a node on the circuit - not to have a good way to learn any other nodes, even if he/she - controls those nodes" - By construction, once processed by an - honest node the cell's payload is completely destroyed, thus - unlinking any relation between what is seen by nodes further - down the circuit and the original message. An adversary - controlling the exit node can still see that the circuit turned - into junk (borrowing the professional jargon of Proposal 202); - this seems unavoidable (if any of the other proposals somehow - solved this, we would like to know so we can see if it can - somehow be adapted here. - - * "no relay should be able to alter a cell between an honest sender - and an honest recipient in a way that they cannot detect" - Any - alternation of a cell between a sender and a recipient will be - decrypted to junk and never delivered to the recipient. (**) - - * "Relay cells should be secret: nobody but the sender and - recipient of a relay cell should be able to learn what it says." - - since the protocol is an extension of the existing one, - whatever secrecy was present before remains so. - - * "... Circuits should resist transparent, recoverable tagging - attacks... " - that's the whole point. Once a change was injected - and passed to an adjacent honest node, no node further down the - circuit can recover the relay cell. - - * "... The above properties should apply to sequences of cells - too... " - this one is more tricky. To the best of my - understanding this property is currently ensured through the - 'Digest' field in the payload. Keeping this field, our solution - can provide the same functionality as before. However, - re-arranging the 'Rec' and 'Digest' fields in a way similar to - Proposal 261 would reduce the overhead but would require - developing a different solution. It seems possible though. (*) - - In addition to supporting these security requirements, this proposal - improves Tor's E2E authentication by replacing the broken SHA-1 with - an ENCODE-then-ENCIPHER authentication. By introducing redundancy to - the cell (either through the 'Rec' and 'Digest' fields or otherwise) - the exit node can verify that the cell was not altered en route. This - is similar to what is done in Proposal 261 but without the trouble of - using a tweakable wide-block cipher. - - (*) a possible solution would be to digest X as part of H(C) but - this requires further discussion. - - (**) my understanding is that a single circuit can be used for - more than one TCP stream. If this is not the case, then the - recipient receives a random string and can identify that this is - not a valid message. - - -3.3 Feature requirements - - - In addition to security requirements, Proposal 202 also discusses - some feature requirements. We discuss two of them here as the others - seems to be trivially supported (although this needs to be verified - by someone who understands Tor better than me). - - - * "Any new approach should be able to coexist on a circuit with the - old approach" - following the IRC discussion, we had an internal - discussion and we think that the proposed solution works even if - only the middle node supports the new protocol. This involves - encrypting the nonce only for the middle nonce. We came up with - two ways to achieve this, both have their pro's and con's and - should be discussed once we agree on the general idea. - - Since the Crypto tagging attack requires a collusion between a - corrupted guard and a corrupted exit, it does not make sense to - discuss what happens when one of them runs the new protocol. - - * "Cell length needs to be constant as cells move through the - network." - The solution was designed to allow for a fixed cell - size. this should be discussed though. - -4. Specifications - TBD - -5. Compatibility - See Section 3.3 - -6. Implementation - TBD - -7. Performance and scalability notes - TBD + linking the nonce and the transmitted data in such a way that any + change to the data (e.g., through a tagging attack) randomizes the + nonce and results in a random value Z' != Z for CTR(N' != N). + +3.1.1. 'Forward' direction (same direction as CREATE): + + When preparing a message to be sent in the forward direction, the + client is responsible for encrypting all layers. The client starts by + digesting the message to create a synthetic tweak T_0 = H_{k_fM}(M) + and uses this tweak to encrypt an all-zero string to create a + synthetic IV: S_0 = T_0 ^ E_{k_fE}(0 ^ T_0). + + The message and the synthetic IV (i.e., M||S_0) are passed as input + to the first encryption layer which uses S_0 to produce the random + stream Z = CTR_k1(S_0) and the ciphertext C = Z ^ M. Then, a tweak T + = H_k2(C) is generated by digesting the ciphertext of this + layer. Finally, S_0 is encrypted using AES and the tweak T to produce + an encrypted nonce S = T ^ E_k3(N ^ T) which is appended to the the + ciphertext and is used as the nonce for the next encryption layer. + + After encrypting 3 times, the client sends C||S to the guard. Whereas + the protocol previously required that the nonce be kept in sync + between each node and the client, this is no longer required as it + can now be recovered from C||S. To decrypt, the node first computes T + = H_k2(C) then uses it to obtain S = D_k3(S ^ T) ^ T. Finally, CTR(S) + is used to decrypt C into M. The once-decrypted nonce is appended to + the data and M||S is sent to the next node which repeats this + process. + + The exit verifies the integrity of the message by digesting it and + using the resulting T to decrypt S_0 into N. If N=0, the message is + authenticated. Otherwise, if the message has been changed by an + adversary, N!=0 and the circuit is destroyed. + +3.1.2 'Back' direction (opposite direction from CREATE): + + When sending back a message from the exit to the client, each node + adds an additional layer of encryption. The exit starts by digesting + the message to create a synthetic tweak T_0 = H_{k_bM}(M) and uses + this tweak to encrypt an all-zero string to create a synthetic IV: + S_0 = T_0 ^ E_{k_bE}(0 ^ T_0). The synthetic IV is then used to + produce the random stream Z = CTR_k1(S_0) and uses that to encrypt + the plaintext through C = Z ^ M. The nonce is appended to the + ciphertext and C||S_0 is sent to the next node. + + Receiving a message from the exit, the middle starts by producing a + tweak T = H_k2(C). The tweak is then used to encrypt the nonce + through S = T ^ E_k3(N ^ T) which is then used to produce the random + stream Z' = CTR_k1(S). Finally, the message is encrypted via C' = Z' + ^ C and the encrypted nonce is appended to C'. The message C'||S is + sent to the next node which repeats this procedure. + + When the message arrives at the client, the client peels each layer + using the nonce that is appended at the end of the message. The + decrypted layer is used to compute the tweak T = H_k2(P), which is + used to decrypt this layer's nonce into the next layer's nonce. + + The client verifies the integrity of the message by digesting it and using + the resulting T to decrypt S_0 into N. If N=0, the message is + authenticated. Otherwise, if the message has been changed by an adversary, + N!=0 and the circuit is destroyed. + +3.2 Circuit management + +3.2.1 Creating circuits + + The general process of creating a circuit remains the same (see + tor-spec.txt), except for step 5 where instead of creating a pair of + keys (kf_1,kb_1) for forward and backward communication, + respectively, 2 triplets of keys (kf_1,kf_2,kf_3) and + (kb_1,kb_2,kb_3) are created for communication in the forward and + backward directions, respectively. Two additional pairs of + "authentication keys" (k_fM,k_fE) and (k_bM,k_bE) are created between + the client and the exit in the forward and backward directions, + respectively. + + note: the keys can be created by running KDF-RFC5869 3 times in each + direction, or by running it once in each direction to create a + master-key and derive the rest as subkeys from this master key + +3.2.2 Routing relay cells + + When an OR receives a RELAY or RELAY_EARLY cell, it checks the cell's + circID and determines whether it has a corresponding circuit along + that connection. If not, the OR drops the cell. + + Otherwise, if the OR is not at the OP edge of the circuit (that is, + either an 'exit node' or a non-edge node), it de/encrypts the payload + with the stream cipher, as follows (the message structure is C||S): + + 'Forward' relay cell (same direction as CREATE) + (input structure is: C||S): + + 1. T = H_{kf_2}(T'||C); digest ciphertext (T' is a running digest + of all previous cells, i.e., last round's T) + + 2. N = T ^ D_{kf_3}(S ^ T); decrypt nonce + + 3. M = CTR_{kf_1}(N) ^ C; decrypt message + (output structure is M||N) + + 'Back' relay cell (opposite direction from CREATE) + (input structure is: M||N): + + 1. T = H_{kb_2}(T'||M); digest ciphertext (T' is a running digest + of all previous cells, i.e., last round's T) + + 2. S = T ^ E_{kb_3}(N ^ T); encrypt nonce + + 3. C = CTR_{kb_1}(S) ^ M; encrypt message + (output structure is C||S) + + Note that in counter mode, decrypt (D) and encrypt (E) are the same + operation. + + The OR then decides whether it recognizes the relay cell, by + inspecting the payload as described in Section 4.1 below. If the OR + recognizes the cell, it processes the contents of the relay cell. + Otherwise, it passes the decrypted relay cell along the circuit if + the circuit continues. If the OR at the end of the circuit + encounters an unrecognized relay cell, an error has occurred: the OR + sends a DESTROY cell to tear down the circuit. + +4. Application connections and stream management + +4.1 Relay cells + + Within a circuit, the OP and the exit node use the contents of RELAY + packets to tunnel end-to-end commands and TCP connections ("Streams") + across circuits. End-to-end commands can be initiated by either + edge; streams are initiated by the OP. + + The payload of each unencrypted RELAY cell consists of: + Relay command [1 byte] + 'Recognized' [2 bytes] + StreamID [2 bytes] + Length [2 bytes] + Data [PAYLOAD_LEN-23 bytes] + + The 'recognized' field is used for a simple indication if the cell + still encrypted or not. When sending cells, the unencrypted + 'recognized' MUST be set to zero. + + When receiving and decrypting cells the 'recognized' will always be + zero if we're the endpoint that the cell is destined for. For cells + that we should relay, the 'recognized' field will usually be nonzero, + but will accidentally be zero with P=2^-32. + + The old Digest field is removed, since sufficient information for + authentication is now included in the all-zero string used to create the + nonce for the first encryption layer. + + The 'Length' field of a relay cell contains the number of bytes in + the relay payload which contain real payload data. The remainder of + the payload is padded with NUL bytes. + +4.2 Appending the encrypted nonce + + When a cell is prepared by the client to be sent in the 'forward' + direction, as explained in Section 3.2.2, the encrypted nonce S 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 used as the nonce for the next round's + encryption. Otherwise, if the next node only supports the old + protocol, S is still appended to the encrypted cell, but a + synchronized nonce (as per the old protocol) is used for encryption. + + When a cell is sent along the circuit in the 'backward' direction, + nodes supporting the new protocol always assume that the last 16 + bytes of the input are the nonce used by the previous node, which + they process as per Section 3.2.2. If the previous node also supports + the new protocol, these cells are indeed the nonce. If the previous + node only supports the old protocol, these bytes are either encrypted + NUL bytes or encrypted data. + +4.3 Authenticating the message + + End-to-end authentication is performed in both directions in the same + way. Once the final layer of encryption is removed, the + message-to-be-authenticated is digested and this digest is used to + decrypt the nonce used in this layer. If the decrypted nonce is + all-zero, the message is authentic. Otherwise, if a change was made + to the ciphertext or the encrypted nonce somewhere along the circuit, + the nonce decrypts into a random value and the circuit is destroyed.

1 0

[translation/tails-misc] Update translations for tails-misc
by translation＠torproject.org 04 Jul '18

04 Jul '18

commit aee7dabadf223b70983393878a484a845b75fd90 Author: Translation commit bot <translation(a)torproject.org> Date: Wed Jul 4 19:46:40 2018 +0000 Update translations for tails-misc --- ar.po | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/ar.po b/ar.po index 11782ee59..2575bf0e7 100644 --- a/ar.po +++ b/ar.po @@ -28,7 +28,7 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2018-03-12 19:03+0100\n" -"PO-Revision-Date: 2018-07-03 14:27+0000\n" +"PO-Revision-Date: 2018-07-04 19:32+0000\n" "Last-Translator: Khaled Hosny <khaledhosny(a)eglug.org>\n" "Language-Team: Arabic (http://www.transifex.com/otf/torproject/language/ar/)\n" "MIME-Version: 1.0\n" @@ -132,31 +132,31 @@ msgstr "فشل تنصيب البرمجيات الإضافية" msgid "" "The installation failed. Please check your additional software " "configuration, or read the system log to understand better the problem." -msgstr "" +msgstr "فشل التنصيب. رجاء راجع ضبط البرمجيات الإضافية، أو طالع سجل النظام لمعرفة المشكلة أفضل." #: config/chroot_local-includes/usr/local/sbin/tails-additional-software:177 msgid "Your additional software are installed" -msgstr "" +msgstr "البرمجيات الإضافية منصبة." #: config/chroot_local-includes/usr/local/sbin/tails-additional-software:178 msgid "Your additional software are ready to use." -msgstr "" +msgstr "البرمجيات الإضافية جاهزة للاستخدام." #: config/chroot_local-includes/usr/local/sbin/tails-additional-software:194 #: config/chroot_local-includes/usr/local/sbin/tails-additional-software:204 msgid "Your additional software upgrade failed" -msgstr "" +msgstr "فشلت ترقية البرمجيات الإضافية." #: config/chroot_local-includes/usr/local/sbin/tails-additional-software:195 msgid "" "The check for upgrades failed. This might be due to a network problem. " "Please check your network connection, try to restart Tails, or read the " "system log to understand better the problem." -msgstr "" +msgstr "فشل التماس الترقيات. قد يكون هذا بسبب عطل في الشبكة. رجاء تحقق من اتصال الإنترنت، أو جرب إعادة تشغيل تيلز، أو طالع سجل النظام لمعرفة المشكلة أفضل." #: config/chroot_local-includes/usr/local/sbin/tails-additional-software:201 msgid "Your additional software are up to date" -msgstr "" +msgstr "البرمجيات الإضافية محدثة." #: config/chroot_local-includes/usr/local/sbin/tails-additional-software:202 msgid "The upgrade was successful."

1 0

[tor-browser/tor-browser-60.1.0esr-8.0-1] Revert "Bug 20283: Tor Browser should run without a `/proc` filesystem."
by gk＠torproject.org 04 Jul '18

04 Jul '18

commit 2edb3478a22331e0fc882e25874b9403ee2575ee Author: Georg Koppen <gk(a)torproject.org> Date: Wed Jul 4 16:51:23 2018 +0000 Revert "Bug 20283: Tor Browser should run without a `/proc` filesystem." This reverts commit 5bd6e492edc3fc4df748d1228360c80fee38e276. --- js/src/util/NativeStack.cpp | 60 +++------------------------------------------ 1 file changed, 4 insertions(+), 56 deletions(-) diff --git a/js/src/util/NativeStack.cpp b/js/src/util/NativeStack.cpp index a695cb3bcd6c..2507374a36da 100644 --- a/js/src/util/NativeStack.cpp +++ b/js/src/util/NativeStack.cpp @@ -13,24 +13,10 @@ # if defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__DragonFly__) # include <pthread_np.h> # endif -# if defined(SOLARIS) || defined(AIX) -# include <ucontext.h> -# endif # if defined(ANDROID) && !defined(__aarch64__) # include <sys/types.h> # include <unistd.h> # endif -# if defined(XP_LINUX) && !defined(ANDROID) && defined(__GLIBC__) -# include <dlfcn.h> -# include <sys/syscall.h> -# include <sys/types.h> -# include <unistd.h> -static pid_t -gettid() -{ - return syscall(__NR_gettid); -} -# endif #else # error "Unsupported platform" #endif @@ -48,6 +34,8 @@ js::GetNativeStackBaseImpl() #elif defined(SOLARIS) +#include <ucontext.h> + JS_STATIC_ASSERT(JS_STACK_GROWTH_DIRECTION < 0); void* @@ -60,6 +48,8 @@ js::GetNativeStackBaseImpl() #elif defined(AIX) +#include <ucontext.h> + JS_STATIC_ASSERT(JS_STACK_GROWTH_DIRECTION < 0); void* @@ -71,48 +61,6 @@ js::GetNativeStackBaseImpl() context.uc_stack.ss_size; } -#elif defined(XP_LINUX) && !defined(ANDROID) && defined(__GLIBC__) -void* -js::GetNativeStackBaseImpl() -{ - // On the main thread, get stack base from glibc's __libc_stack_end rather than pthread APIs - // to avoid filesystem calls /proc/self/maps. Non-main threads spawned with pthreads can read - // this information directly from their pthread struct, but the main thread must go parse - // /proc/self/maps to figure the mapped stack address space ranges. We want to avoid reading - // from /proc/ so that firefox can run in sandboxed environments where /proc may not be mounted - if (gettid() == getpid()) { - void** pLibcStackEnd = (void**)dlsym(RTLD_DEFAULT, "__libc_stack_end"); - // If __libc_stack_end is not found, architecture specific frame pointer hopping will need - // to be implemented. - MOZ_RELEASE_ASSERT(pLibcStackEnd, "__libc_stack_end unavailable, unable to setup stack range for JS"); - void* stackBase = *pLibcStackEnd; - MOZ_RELEASE_ASSERT(stackBase, "invalid stack base, unable to setup stack range for JS"); - // We don't need to fix stackBase, as it already roughly points to beginning of the stack - return stackBase; - } else { - // Non-main threads have the required info stored in memory, so no filesystem calls are made. - pthread_t thread = pthread_self(); - pthread_attr_t sattr; - pthread_attr_init(&sattr); - pthread_getattr_np(thread, &sattr); - // stackBase will be the *lowest* address on all architectures. - void* stackBase = nullptr; - size_t stackSize = 0; - int rc = pthread_attr_getstack(&sattr, &stackBase, &stackSize); - if (rc) { - MOZ_CRASH("call to pthread_attr_getstack failed, unable to setup stack range for JS"); - } - MOZ_RELEASE_ASSERT(stackBase, "invalid stack base, unable to setup stack range for JS"); - pthread_attr_destroy(&sattr); - -# if JS_STACK_GROWTH_DIRECTION > 0 - return stackBase; -# else - return static_cast<char*>(stackBase) + stackSize; -# endif - } -} - #else /* XP_UNIX */ void*

1 0

[tor-browser/tor-browser-60.1.0esr-8.0-1] Bug 859782 - Firefox cannot start without /proc (chroot). r=sfink, evilpie, jld
by gk＠torproject.org 04 Jul '18

04 Jul '18

commit dbca4ee64600d9ab17e7c9abdc7dac76562def01 Author: Richard Pospesel <richard(a)torproject.org> Date: Tue Jun 19 08:00:58 2018 -0600 Bug 859782 - Firefox cannot start without /proc (chroot). r=sfink,evilpie,jld Firefox uses the current stack frame address and the stack size as a sort of heuristic for various things in the javascript engine. The js::GetNativeStackBaseImpl() function is used to get the base stack address (ie the address from which the stack grows, so this can be either the first or last memory address of the stack memory space depending on the CPU architecture). On Linux, this function is implemented using the pthreads APIs. For non-main threads, the queried thread info is stored in memory. The main thread does not have this information on hand, so it gets the stack memory range via the /proc/self/maps file ( see glibc's pthread_get_attr_np.c ). Fortunately (per discussions with the firefox devs in #jsapi) the base address only needs to be approximation. In reality, environment variables, args, and other things are stored in space between the end/beginning of the mapped stack memory and the 'top' of the stack space used by stack frames. We can get the top of this usable stack from __libc_stack_end, which is a void* set by glibc during program initialization. Non-main threads still get their stack-base through the usual pthreads APIs. This fixes bug 20283 on our side. --- js/src/util/NativeStack.cpp | 64 ++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 60 insertions(+), 4 deletions(-) diff --git a/js/src/util/NativeStack.cpp b/js/src/util/NativeStack.cpp index 2507374a36da..300b5259b5e5 100644 --- a/js/src/util/NativeStack.cpp +++ b/js/src/util/NativeStack.cpp @@ -13,10 +13,24 @@ # if defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__DragonFly__) # include <pthread_np.h> # endif +# if defined(SOLARIS) || defined(AIX) +# include <ucontext.h> +# endif # if defined(ANDROID) && !defined(__aarch64__) # include <sys/types.h> # include <unistd.h> # endif +# if defined(XP_LINUX) && !defined(ANDROID) && defined(__GLIBC__) +# include <dlfcn.h> +# include <sys/syscall.h> +# include <sys/types.h> +# include <unistd.h> +static pid_t +gettid() +{ + return syscall(__NR_gettid); +} +# endif #else # error "Unsupported platform" #endif @@ -34,8 +48,6 @@ js::GetNativeStackBaseImpl() #elif defined(SOLARIS) -#include <ucontext.h> - JS_STATIC_ASSERT(JS_STACK_GROWTH_DIRECTION < 0); void* @@ -48,8 +60,6 @@ js::GetNativeStackBaseImpl() #elif defined(AIX) -#include <ucontext.h> - JS_STATIC_ASSERT(JS_STACK_GROWTH_DIRECTION < 0); void* @@ -61,6 +71,52 @@ js::GetNativeStackBaseImpl() context.uc_stack.ss_size; } +#elif defined(XP_LINUX) && !defined(ANDROID) && defined(__GLIBC__) +void* +js::GetNativeStackBaseImpl() +{ + + // On the main thread, get stack base from glibc's __libc_stack_end rather than pthread APIs + // to avoid filesystem calls /proc/self/maps. Non-main threads spawned with pthreads can read + // this information directly from their pthread struct, but the main thread must go parse + // /proc/self/maps to figure the mapped stack address space ranges. We want to avoid reading + // from /proc/ so that firefox can run in sandboxed environments where /proc may not be mounted + if (gettid() == getpid()) { + void** pLibcStackEnd = (void**)dlsym(RTLD_DEFAULT, "__libc_stack_end"); + + // If __libc_stack_end is not found, architecture specific frame pointer hopping will need + // to be implemented. + MOZ_RELEASE_ASSERT(pLibcStackEnd, "__libc_stack_end unavailable, unable to setup stack range for JS"); + void* stackBase = *pLibcStackEnd; + MOZ_RELEASE_ASSERT(stackBase, "invalid stack base, unable to setup stack range for JS"); + + // We don't need to fix stackBase, as it already roughly points to beginning of the stack + return stackBase; + } + + // Non-main threads have the required info stored in memory, so no filesystem calls are made. + pthread_t thread = pthread_self(); + pthread_attr_t sattr; + pthread_attr_init(&sattr); + pthread_getattr_np(thread, &sattr); + + // stackBase will be the *lowest* address on all architectures. + void* stackBase = nullptr; + size_t stackSize = 0; + int rc = pthread_attr_getstack(&sattr, &stackBase, &stackSize); + if (rc) { + MOZ_CRASH("call to pthread_attr_getstack failed, unable to setup stack range for JS"); + } + MOZ_RELEASE_ASSERT(stackBase, "invalid stack base, unable to setup stack range for JS"); + pthread_attr_destroy(&sattr); + +# if JS_STACK_GROWTH_DIRECTION > 0 + return stackBase; +# else + return static_cast<char*>(stackBase) + stackSize; +# endif +} + #else /* XP_UNIX */ void*

1 0

[fpcentral/master] Bug 26623: recognize esr60 versions of Tor Browser
by gk＠torproject.org 04 Jul '18

04 Jul '18

commit a88dbe42b1478ba4a2142c3c8ae08d80511a7f73 Author: Nicolas Vigier <boklm(a)torproject.org> Date: Tue Jul 3 19:44:23 2018 +0200 Bug 26623: recognize esr60 versions of Tor Browser --- fingerprint/acceptable/torbrowser80.json | 64 ++++++++++++++++++++++++++++++++ fingerprint/tags/browser.py | 9 ++++- 2 files changed, 72 insertions(+), 1 deletion(-) diff --git a/fingerprint/acceptable/torbrowser80.json b/fingerprint/acceptable/torbrowser80.json new file mode 100644 index 0000000..4c6522e --- /dev/null +++ b/fingerprint/acceptable/torbrowser80.json @@ -0,0 +1,64 @@ +{ + "mainTag": "Tor Browser 8.0", + "math": { + "asinh(1)": 0.8813735870195429, + "acosh(1e300)": "Infinity", + "atanh(05)": 0.5493061443340548, + "expm1(1)": 1.7182818284590455, + "cbrt(100)": 4.641588833612778, + "log1p(10)": 2.3978952727983707, + "sinh(1)": 1.1752011936438016, + "cosh(10)": 11013.232920103324, + "tanh(1)": 0.7615941559557649 + }, + "plugins": "", + "dnt": "NC", + "buildID": "20100101", + "screen": { + "width": [1000,800,600,400,200], + "height": [1000,900,800,700,600,500,400,300,200], + "depth": 24, + "availTop": 0, + "availLeft": 0, + "availHeight": [1000,900,800,700,600,500,400,300,200], + "availWidth": [1000,800,600,400,200], + "left": 0, + "top": 0 + }, + "storage": { + "local": "yes", + "session": "yes" + }, + "timezone": 0, + "cookies": "yes", + "platform": "Win32", + "Accept-Encoding": "gzip, deflate, br", + "Accept-Language": "en-US,en;q=0.5", + "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", + "Content-Type": "", + "Content-Length": "", + "audio": { + "nt_vc_output": { + "ac-sampleRate": 0, + "ac-state": 0, + "ac-maxChannelCount": 0, + "ac-numberOfInputs": 0, + "ac-numberOfOutputs": 0, + "ac-channelCount": 0, + "ac-channelCountMode": 0, + "ac-channelInterpretation": 0, + "an-fftSize": 0, + "an-frequencyBinCount": 0, + "an-minDecibels": 0, + "an-maxDecibels": 0, + "an-smoothingTimeConstant": 0, + "an-numberOfInputs": 0, + "an-numberOfOutputs": 0, + "an-channelCount": 0, + "an-channelCountMode": 0, + "an-channelInterpretation": 0 + }, + "pxi_output": 0, + "pxi_full_buffer_hash": "158e8189a3551fe4f2e564ac377b0f1e588a1ab3" + } +} diff --git a/fingerprint/tags/browser.py b/fingerprint/tags/browser.py index 405b8c8..daae5c1 100644 --- a/fingerprint/tags/browser.py +++ b/fingerprint/tags/browser.py @@ -5,6 +5,7 @@ tor4 = "Tor 4.X" tor5 = "Tor 5.X" tor6 = "Tor 6.X" torbrowser70 = "Tor Browser 7.0" +torbrowser80 = "Tor Browser 8.0" chrome = "Chrome" firefox = "Firefox" #NB: A Tor browser cannot have the Firefox tag edge = "Edge" @@ -20,7 +21,13 @@ class Browser(Tag): def checkTags(self, fp): ua = fp["User-Agent"] #We check first for UA from Tor browsers - if ua == "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0": + if ua == "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0": + return [torbrowser80] + elif ua == "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0": + return [torbrowser80] + elif ua == "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0": + return [torbrowser80] + elif ua == "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0": return [torbrowser70] elif ua == "Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0": return [tor6]

1 0

[torspec/master] Add proposal 295 from Tomer Ashur.
by nickm＠torproject.org 03 Jul '18

03 Jul '18

commit b0d5698c49cb143c60c012655c282adde2722048 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jul 3 17:38:26 2018 -0400 Add proposal 295 from Tomer Ashur. --- proposals/000-index.txt | 2 + proposals/295-relay-crypto-with-atl.txt | 276 ++++++++++++++++++++++++++++++++ 2 files changed, 278 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index d82839d..d9c7e93 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -215,6 +215,7 @@ Proposals by number: 292 Mesh-based vanguards [ACCEPTED] 293 Other ways for relays to know when to publish [OPEN] 294 TLS 1.3 Migration [DRAFT] +295 Using the ATL construction for relay cryptography (solving the crypto-tagging attack) [OPEN] Proposals by status: @@ -244,6 +245,7 @@ Proposals by status: 287 Reduce circuit lifetime without overloading the network 289 Authenticating sendme cells to mitigate bandwidth attacks 293 Other ways for relays to know when to publish [for 0.3.5] + 295 Using the ATL construction for relay cryptography (solving the crypto-tagging attack) ACCEPTED: 188 Bridge Guards and other anti-enumeration defenses 249 Allow CREATE cells with >505 bytes of handshake data diff --git a/proposals/295-relay-crypto-with-atl.txt b/proposals/295-relay-crypto-with-atl.txt new file mode 100644 index 0000000..74e31b1 --- /dev/null +++ b/proposals/295-relay-crypto-with-atl.txt @@ -0,0 +1,276 @@ +Filename: 295-relay-crypto-with-atl.txt +Title: Using the ATL construction for relay cryptography (solving the crypto-tagging attack) +Author: Tomer Ashur +Created: 09 Apr 2018 +Status: Open + + +0. Context + + Although Crypto Tagging Attacks were identified already in the + original Tor design, it was not before the rise of the Procyonidae in + 2012 that their severity was fully realized. In Proposal 202 (Two + improved relay encryption protocols for Tor cells) Nick Mathewson + discussed two approaches to stymie tagging attacks and generally + improve Tor's cryptography. In Proposal 261 (AEZ for relay + cryptography) Nick put forward a concrete approach which uses the + tweakable wide-block cipher AEZ. + +1. Motivation + + For motivations, see proposal 202. + +2. Summary and preliminaries + + This proposal suggests an alternative approach to Proposal 261 using + the notion of Release (of) Unverified Plaintexts (RUP-security). It + describes an improved algorithm for circuit encryption based on + CTR-mode which is already used in Tor, and an additional component + for hashing. When this additional component is GHash, a GCM-based + solution can be used from the OpenSSL library. If a solution that is + based solely on components that already exist in Tor is desirable, + SHA-1 can be used for hashing (however, this is highly discouraged as + SHA-1 is broken!). + + Incidentally, and similar to Proposal 261, this proposal employs the + ENCODE-then-ENCIPHER approach thus it improves Tor's E2E integrity by + using (sufficiently enough) redundancy. + + For more information about the scheme and a security proof for its + RUP-security see + + Tomer Ashur, Orr Dunkelman, Atul Luykx: Boosting Authenticated + Encryption Robustness with Minimal Modifications. CRYPTO (3) 2017: + 3-33 available online at https://eprint.iacr.org/2017/239 . + +2.1 An instructive 1-node circuit + + Noting that in CTR-mode the nonce is essential for the + encryption/decryption operations, the proposed solution is based on + encrypting its value in such a way that any change to the ciphertext + or the tag (e.g., through a tagging attack) would randomize the nonce + and result in a random value as the output of CTR-mode. + + The basic crypto components of the proposal are: + * a block cipher E(·) + * A universal hash function, H(·); + + Using the block cipher E(·) and a non-repeating nonce N, one can + construct the CTR mode-of-operation: + + CTR(N) = E(N)||E(N+1)||...||E(N+l) + + For simplicity, let us for now consider normal encryption using + CTR-mode (This is akin to building a circuit with a single node. In + the sequel we will see what happens when this idea is used in a 3-node + circuit): + + * Input: a nonce N, a message M = (m_0,...,m_l) + 1. (z_0,...,z_l) = CTR(N) + 2. (c_0,...,c_l) = (z_0 ^ m_0, ... z_l ^ m_l) + + The client sends C = (c_0,...,c_l) to the receiver which repeats Step + (1) to generate the random stream Z = (z_0,...,z_l) and recovers the + message through M = C ^ Z. A protocol using this scheme is vulnerable + to the crypto tagging attack due to the malleability of + CTR-mode. Indeed, since Z depends only on N rather than on the + message M itself, a change to a ciphertext bit affects the respective + plaintext bit and nothing else. + + Our solution is based on the idea that linking N and C makes it + impossible to change C without affecting N (and hence Z) in such a + way that it is impossible to recover M. This can be done by extending + the protocol in the following way: + + 3. X = H(C) + 4. S = X ^ E(N ^ X) + + Now, instead of sending C, the client sends C||S to the receiver. To + decrypt, the receiver first repeats Step (3) to obtain X, then + inverts Step (4) to obtain N: N = D(S ^ X) ^ X (where D(·) is the + inverse function of E(·)). Then, having obtained N, the receiver + continues to decrypt C as before. If the receiver already knows N + (e.g., in the case of a synchronized nonce), they can authenticate C + by comparing N = D(S ^ X) ^ X to the nonce they expect. + + Let us consider what happens when a change is made to C. Let C' be a + variant of C with one or more bits flipped. Since H(·) is a universal + hash function, X' = H(C' ≠ C) is random. Trying to execute D(S ^ X') + ^ X' would result in a random N' ≠ N which in turn would result in a + random Z' (and hence a random M'). Similarly for a change in S. + +2.2 Extending to a 3-node Tor circuit + + The Tor protocol uses layered encryption to encapsulate the + message. Generally speaking, this can be written as: + + * input: synchronized nonces (N^0, N^1, N^2), a message M = (m_0,...,m_l) + 1. (z^2_0,...,z^2_l) = CTR(N^2) + 2. (c^2_0,...,c^2_l) = (z^2_0 ^ m_0, ... z^2_l ^ m_l) + 3. (z^1_0,...,z^1_l) = CTR(N^1) + 4. (c^1_0,...,c^1_l) = (z^1_0 ^ c^2_0, ... z^1_l ^ c^2_l) + 5. (z^0_0,...,z^0_l) = CTR(N^0) + 6. (c^0_0,...,c^0_l) = (z^0_0 ^ c^1_0, ... z^0_l ^ c^0_l) + + The crypto-tagging stems from the fact that a change to C affects M + directly since all z^j_i depend only on N^j rather than on C^j. + + An extension of the 1-layer solution presented in Section 2.1 would + look like this: + + * Input: a nonce N, a message M = (m_0,...,m_l) + 1. (z^2_0,...,z^2_l) = CTR(N) + 2. (c^2_0,...,c^2_l) = (z^2_0 ^ m_0, ... z^2_l ^ m_l) + 3. X^2 = H(C^2) + 4. S^2 = X^2 ^ E(N^2 ^ X^2) + + 5. (z^1_0,...,z^1_l) = CTR(S^2) + 6. (c^1_0,...,c^1_l) = (z^1_0 ^ c^2_0, ... z^1_l ^ c^2_l) + 7. X^1 = H(C^1) + 8. S^1 = X^1 ^ E(S^2 ^ X^1) + + 9. (z^0_0,...,z^0_l) = CTR(S^1) + 10. (c^0_0,...,c^0_l) = (z^0_0 ^ c^1_0, ... z^1_l ^ c^0_l) + 11. X^0 = H(C^0) + 12. S^0 = X^0 ^ E(S^1 ^ X^0) + + The client sends the message C^0||S^0 = ((c^0_0,...,c^0_l)||S^0) to + the guard. To decrypt, the guard repeats Step (11) and inverts Step + (12) to obtain S^1 which it uses to generate Z^0 and decrypt C^0 into + C^1. The guard then forwards C^1||S^1 to the middle node which + repeats this process and forwards C^2||S^2 to the exit. The exit + removes the final encryption layer and processes the cell as in the + old protocol. + + Let us now consider what happens when the crypto tagging attack is + applied to this protocol. Without loss of generality, after inverting + Step (11) the guard tags either C^1 or S^1 and forwards C'^1||S'^1 to + the middle node. The middle node, unaware of the change follows the + protocol to decrypt C'^1||S'^1 which results in a random string as + per the explanation above. Since both CircID and CMD are not part of + the payload, the middle node can still forward the random string + (unaware of this fact) to the exit node. Upon receiving the random + string, the exit node decrypts it, sees that the 'Rec' field is not + all-zero and acts accordingly. + + +3. Design considerations + +3.1 Choice of primitives + + We stress that the proposed protocol is primitive agnostic. + + Noting that Tor currently uses AES_CTR we tried to design a solution + that requires only minimal changes. Most importantly, the encryption + is still performed using CTR-mode, and can be instantiated using + AES_CTR (however, the solution works just as well with any other + block cipher). + + The hashing of the ciphertext requires a universal hash function. The + GCM mode of operation uses CTR+GHash and is available from the + OpenSSL crypto library which is already used within Tor. Any + available universal hash function can be used instead of GHash if the + latter introduces an unacceptable latency. + + The nonce-encryption step uses a tweakable block cipher. In the + example above we used the XEX trick to transform a "regular" block + cipher into a tweakable block cipher which allows reusing whatever + underlying primitive is used in CTR-mode. A tweakable block cipher + can be used directly (with X as the tweak) if one is available but + this is not required. + +3.2 Security requirements + + In Proposal 202, Nick Mathewson outlined the security requirements + for any solution. We copy them here verbatim and discuss how each of + them is addressed in the proposed solution: + + * " ... we'd like any attacker who controls a node on the circuit + not to have a good way to learn any other nodes, even if he/she + controls those nodes" - By construction, once processed by an + honest node the cell's payload is completely destroyed, thus + unlinking any relation between what is seen by nodes further + down the circuit and the original message. An adversary + controlling the exit node can still see that the circuit turned + into junk (borrowing the professional jargon of Proposal 202); + this seems unavoidable (if any of the other proposals somehow + solved this, we would like to know so we can see if it can + somehow be adapted here. + + * "no relay should be able to alter a cell between an honest sender + and an honest recipient in a way that they cannot detect" - Any + alternation of a cell between a sender and a recipient will be + decrypted to junk and never delivered to the recipient. (**) + + * "Relay cells should be secret: nobody but the sender and + recipient of a relay cell should be able to learn what it says." + - since the protocol is an extension of the existing one, + whatever secrecy was present before remains so. + + * "... Circuits should resist transparent, recoverable tagging + attacks... " - that's the whole point. Once a change was injected + and passed to an adjacent honest node, no node further down the + circuit can recover the relay cell. + + * "... The above properties should apply to sequences of cells + too... " - this one is more tricky. To the best of my + understanding this property is currently ensured through the + 'Digest' field in the payload. Keeping this field, our solution + can provide the same functionality as before. However, + re-arranging the 'Rec' and 'Digest' fields in a way similar to + Proposal 261 would reduce the overhead but would require + developing a different solution. It seems possible though. (*) + + In addition to supporting these security requirements, this proposal + improves Tor's E2E authentication by replacing the broken SHA-1 with + an ENCODE-then-ENCIPHER authentication. By introducing redundancy to + the cell (either through the 'Rec' and 'Digest' fields or otherwise) + the exit node can verify that the cell was not altered en route. This + is similar to what is done in Proposal 261 but without the trouble of + using a tweakable wide-block cipher. + + (*) a possible solution would be to digest X as part of H(C) but + this requires further discussion. + + (**) my understanding is that a single circuit can be used for + more than one TCP stream. If this is not the case, then the + recipient receives a random string and can identify that this is + not a valid message. + + +3.3 Feature requirements + + + In addition to security requirements, Proposal 202 also discusses + some feature requirements. We discuss two of them here as the others + seems to be trivially supported (although this needs to be verified + by someone who understands Tor better than me). + + + * "Any new approach should be able to coexist on a circuit with the + old approach" - following the IRC discussion, we had an internal + discussion and we think that the proposed solution works even if + only the middle node supports the new protocol. This involves + encrypting the nonce only for the middle nonce. We came up with + two ways to achieve this, both have their pro's and con's and + should be discussed once we agree on the general idea. + + Since the Crypto tagging attack requires a collusion between a + corrupted guard and a corrupted exit, it does not make sense to + discuss what happens when one of them runs the new protocol. + + * "Cell length needs to be constant as cells move through the + network." - The solution was designed to allow for a fixed cell + size. this should be discussed though. + +4. Specifications + TBD + +5. Compatibility + See Section 3.3 + +6. Implementation + TBD + +7. Performance and scalability notes + TBD

1 0