- tor-dev - lists.torproject.org

Ready to Integrate/Review New Marionette Version into Tor
by John Helmsen 26 Jul '18

26 Jul '18

Gentlemen and Ladies, We are now ready to integrate Marionette, or at least have it evaluated, as a bridge for the Tor browser in its Pythonless form. At the Tor meeting in March, we successfully operated Marionette as a bridge by implementing the PT v2.0 specification (Thanks ahf!). Now we have a new version of Marionette which operates as a stand-alone binary (NO PYTHON!). I checked that it still forms a bridge, like at the Tor meeting. We also have a wider variety of transports enabled. We are in the process of writing the documentation for Marionette, but the documentation on the web page should be sufficient for at least getting a full evaluation started. We'd like to have the evaluation complete by the end of next month, hopefully the middle of next month, and stand ready to make any and all changes necessary. A full set of documentation will also be written for designing your own protocols. This is in process. Please let us know what you need. John Helmsen

4 9

Sandboxed Tor Browser should be officially developed
by juanjo 26 Jul '18

26 Jul '18

I do not understand why Sandboxed Tor Browser is now deprecated when it should be the new thing in security features. It works well and stopped already some 0days in the past and today I see that not only is officially "*WARNING: Active development is on indefinite hiatus"* (https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux) the last commit is from 3 months ago, but still it works well. And today I see that for the Firefox 60 ESR this support will be removed (https://gitweb.torproject.org/builders/tor-browser-build.git/commit/?id=dc3…) Is there a hidden agenda to allow LEA/governments to exploit Tor Browser users easily? Because I don't think maintaining the sandboxed version is that much work and it is a great protection for many users. So please, make Sandboxed Tor Browser an official thing.

9 12

Proposal 295: Using the ATL construction for relay cryptography (solving the crypto-tagging attack)
by Nick Mathewson 24 Jul '18

24 Jul '18

Hi, all! I've got the privilege to relay the following proposal from Tomer Ashur: it reflects a whole lot of work. I didn't make any changes, other than wrapping the lines: please let me know if corrupted anything. 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

3 4

Could tor drop privileges even earlier? (before trying to access anything on the filesystem beyond its torrc files)
by nusenu 23 Jul '18

23 Jul '18

Fedora/CentOS starts the tor service as root and drops privileges to user 'toranon' due to the torrc 'User' parameter by default. Also by default the tor service runs in a SELinux confined domain (tor_t). That means root in that domain can NOT access just any files regardless of DAC filesystem permissions (DAC_OVERRIDE is not granted by default). Which results in the situation that during startup (before privileges are dropped and user is switched to 'toranon') tor can not access the hiddenservicedir without allowing DAC_OVERRIDE or changing filesystem permissions, but it could if at that point privileges were already switched to the user specified in the torrc file. From my point of view the nicest solution would be if tor drops privileges before it accesses anything on the filesystem - which would solve above problem. Would that introduce other problems? Is there a specific reason why tor drops privileges later? (this is about running tor and tor in --verify-config mode) context: https://bugzilla.redhat.com/show_bug.cgi?id=1602171 (I consider this problem solved via the workaround but I'm still interested in the above question) -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 1

restoring 'cypherpunks' trac account with more anti-automation?
by nusenu 23 Jul '18

23 Jul '18

Hi, is there any timeline when the cypherpunks trac account will be restored? I would suggest to require _every_ single submission (and maybe even the login itself) by that account to go through the captcha test (not just in case there are to many URLs in the submitted comment) to reduce the vandalism. thanks! -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 3

Entreaty for spreading awareness about ProxAllium, a useful frontend for Tor
by Damon (TheDcoder) 21 Jul '18

21 Jul '18

Hello everyone! First I would like to apologize if I am posting this in the wrong place, as I am not sure where I should post this. So this mailing list seemed to be the best option available. As some of you may (most likely not) know me as the developer of a small tool called [ProxAllium](https://proxallium.org/) which is a nice frontend for Tor, it is a nice alternative to keeping Tor Browser up and running if you want to use Tor's SOCKS proxy. I started work on it almost 2 years ago, and I had the idea to develop this for more than 2 years... I consider it fairly stable now that I have been using it that length of time. Recently one of my newer users expressed disappointment that they didn't find any reference to ProxAllium while they were doing some research on how to operate a Tor bridge on Windows, they have suggested I do more "advertising". I have realized that my tool might be useful to a lot of people and many of them would not even be aware of its existence which would be a shame, as it would increase the regular usage of Tor if it was easy to start Tor casually, to [torify](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO) applications. I was hesitant to write this email as I had previously thought that ProxAllium was not good enough for Tor standards. But then I realized I was applying a somewhat artificial logic and thus preventing its growth in usage. I am aware that it has a few fundamental issues (like being written in a closed source language) but I think it is good enough to be used as a helper tool. I am planning a rewrite in a better language (and with a FOSS toolchain) so that it can be cross-platform and more performance efficient. Currently I am struggling with motivation to work on ProxAllium as I am not getting enough input from users. The purpose of this email is to earnestly request that the Tor project consider helping to spread awareness of ProxAllium by adding references to it in places like the wiki and the "projects" list on the website. I am not seeking official endorsement, but a mere mention so that everyone involved can benefit from Tor. I am ready to provide any kind of assistance to the fullest extent I can. Thank you for reading, hopefully I didn't come across as too arrogant or pushy with my proposal, English is not my native language and I struggle with writing in the vein in which I am thinking :) With Regards, Damon H. (TheDcoder)

2 1

Brief state of sbws thoughts
by Matt Traudt 20 Jul '18

20 Jul '18

Teor, Juga There's a lot of things fighting for my attention right now, so you might have noticed I've slowed way down on attending to sbws tickets/PRs/etc. I think time will free up in the next few days. I think sbws is in a very good place code-wise right now. I don't think much more **has** to be done to the code. Even though I enjoy adding things like the state file (GHPR#236 [2]), I don't think that was a good use of my time. It looks like there's a lot of check boxes Juga has made regarding making a Debian package[0]. Those should get checked. These are important. However, I think the absolute most important thing for us to be spending our time on right now is deciding what "good" results are and verifying sbws produces "good" results. To accomplish this, I think one of the two suggestions I made in a comment on GH#182 [1] (quoted here) is what we should be doing. 1. Run torflow and sbws side-by-side (but not at the same time) to remove more variables. This has the added benefit of us having access to the raw scanner results from torflow before it does whatever magic scaling it does. OR 2. Ask for access to raw scanner results from someone running torflow. I fear sbws is doomed to die the death of the new bandwidth scanners before it if we don't start seriously verifying sbws is "good" or if I personally slowly stop working/coordinating work on it. Thanks Matt [0]: https://trac.torproject.org/projects/tor/ticket/26848 [1]: https://github.com/pastly/simple-bw-scanner/issues/182#issuecomment-4042500… [2]: https://github.com/pastly/simple-bw-scanner/pull/236

4 3

Proposal 293: Other ways for relays to know when to publish
by Nick Mathewson 17 Jul '18

17 Jul '18

Filename: 293-know-when-to-publish.txt Title: Other ways for relays to know when to publish Author: Nick Mathewson Created: 30-May-2018 Status: Open Target: 0.3.5 1. Motivation In proposal 275, we give reasons for dropping the published-on field from consensus documents, to improve the performance of consensus diffs. We've already changed Tor (as of 0.2.9.11) to allow us to set those fields far in the future -- but unfortunately, there is still one use case that requires them: relays use the published-on field to tell if they are about to fall out of the consensus and need to make new descriptors. Here we propose two alternative mechanisms for relays to know that they should publish descriptors, so we can enact proposal 275 and set the published-on field to some time in the distant future. 2. Mechanism One: The StaleDesc flag Authorities should begin voting aon a new StaleDesc flag. When authorities vote, if the most recent published_on date for a descriptor has over DESC_IS_STALE_INTERVAL in the past, the authorities should vote to give the StaleDesc flag to that relay. If any relay sees that it has the StaleDesc flag, it should upload some time in the first half of the voting interval. (Implementors should take care not to re-upload over and over, though: Relays won't lose the flag until the next voting interval is reached.) (Define DESC_IS_STALE_INTERVAL as equal to FORCE_REGENERATE_DESCRIPTOR_INTERVAL.) 3. Mechanism Two: Uploading more frequently when rejected. Tor relays should remember the last time at which they uploaded a descriptor that was accepted by a majority of dirauths. If this time is more than FAST_RETRY_DESCRIPTOR_INTERVAL in the past, we mark our descriptor as dirty from mark_my_descriptor_dirty_if_too_old(). 4. Implications for proposal 275 Once most relays are running verions that support the features above, and once authorities are generating consensuses with the StaleDesc flag, there will no longer be a need to keep the published time in consensus documents accurate -- we can start setting it to some time in the distant future, per proposal 275.

3 2

Proposal: Expose raw bwauth votes
by Tom Ritter 16 Jul '18

16 Jul '18

I'm not sure, but I think https://trac.torproject.org/projects/tor/ticket/21377 needed a proposal so I tried to write one up. -tom

5 8

[release] Onionoo 6.1-1.15.0
by Iain Learmonth 16 Jul '18

16 Jul '18

Hi, Onionoo's protocol was extended and has a minor version jump to 6.1. Download available at: https://dist.torproject.org/onionoo/6.1-1.15.0/ Protocol changes (also summarized in [0]): Added a new "os" parameter to filter relays and bridges by operating system, extended the "as" and "country" parameters by a special country code and AS number to return relays that were not found in the GeoIP database, and deprecated the "host_name" field in details documents in favor of the new "verified_host_names" and "unverified_host_names" fields for more accurate DNS results on July 16, 2018. Software changes are summarized in the changelog [1]. The changes are already deployed on all onionoo.torproject.org instances. Please direct comments and questions to the metrics-team mailing list [2]. Thanks, Iain -- on behalf of the Metrics Team. [0] https://metrics.torproject.org/onionoo.html#versions_6_1 [1] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0