- tor-dev - lists.torproject.org

New python Tor client implementation
by James Brown 24 Oct '19

24 Oct '19

4 4

Comparing Proposals 295 and 308
by Tomer Ashur 23 Oct '19

23 Oct '19

Dear all, Some time ago I sent to this mailing list a proposal for using the ADL construction to solve the crypto tagging attack and it was registered as Proposal 295. Then, about a month ago Jean Paul Degabriele sent another proposal aiming for the same, which was registered as Proposal 308. We’ve now had the chance to compare both proposals and we provide our observations below. But before we discuss the pros and cons of each proposal, I’d like to re-state our goal for Proposal 295. Our aim was to build something that: 1. does not lose any security guarantees that are already in place; 2. prevents successful crypto-tagging; and 3. does not introduce new weaknesses. We *did not* consider advanced security goals such as forward secrecy and/or non-repudiation which was also mentioned earlier on this mailing list. In achieving these goals, the two proposals are almost the same: for the encryption part, both use layered encryption where the nonce is tweaked with a digest of the ciphertext, and sent in encrypted form to the next node as part of the ciphertext. The only meaningful difference I could find is that instead of using the output of the universal hash function (i.e., GHASH) as a running digest as is done in Proposal 295, Proposal 308 uses the encrypted nonce. Jean Paul made the correct observation that our security proof did not account for key-dependent input, but we believe that this can be resolved by rewriting the proof. In either case, this is a subtlety and common ground can be found. On a high level, both proposals use the same mechanism to avoid crypto-tagging. Where the proposals differ is in the authentication part. Proposal 295 makes a functional separation between the encryption part and the authentication part, cf. Lines 150-152 (authentication) and Lines 156-160 (layered encryption). Conversely, Proposal 308 does not offer such separation, and the authentication and encryption of the last node are done in a single pass (cf. Lines 227-230 and Lines 244-252). This comes with what we think are two highly unwanted side effects defeating the purpose of using the ADL construction to begin with: the authentication of the last node depends solely on the proper execution of the IF statement on Line 266. As a result, if this line is skipped for some reason (e.g., because an adversary corrupted the last node, a bug, or as a result of over-optimization), modified messages may leave the network. Moreover, the last layer is malleable which means that a difference introduced to the ciphertext entering the last node will be preserved through the final decryption (given that the IF statement on Line 266 is skipped). This is because the decryption nonce does not depend on the authentication process (in the lingo of Proposal 308 this is called a “dynamic nonce”). Comparing this to Proposal 295 we see that the same cannot happen. Any change introduced at any point (including the ciphertext entering the last node) will completely destroy the payload in an irrecoverable way (the same happens in the “static layers” of Proposal 308; only the dynamic layer is malleable). For the record, a corollary of all of this is that if Sf_I is leaked (e.g., via a side channel in the generation process of Nf_I that is used by the IF statement), the adversary now has the secret it needs to decrypt the ciphertext regardless of the authentication process. Not being able to do this is exactly what’s captured by the RUP property used in Proposal 295 in which the only way to obtain N_4 (the counterpart of Proposal 308’s Nf_I) is via a successful digest of an unmodified ciphertext. The place where Proposal 308 nicely extends over Proposal 295 is in the forward secrecy domain. In an email to this mailing list we conjectured that if certain changes are made to Proposal 295 it will provide forward secrecy in addition to its crypto-tagging resistance. Jean Paul suggested an attack against this conjecture, but I find that the attack is not very convincing. Indeed, once the keys are leaked, the last message can be recovered. But I don’t think that there’s anything surprising in the fact that the set of keys that would have normally decrypted a message will also do so if leaked to an adversary. A more reasonable definition for forward secrecy would be that no message can be decrypted *after* the state (including ephemeral secrets) that was used to generate this message was replaced. Admittedly, Proposal 308 replaces this state earlier than Proposal 295 (immediately after processing the message vs. after processing the next message), which may be desirable, but is anyway not disastrous. That being said, this discussion is theoretic in nature since of the two proposals, only Proposal 308 offers an actual mechanism. For Proposal 295 we only offer a conjecture. We also tend to somewhat agree that frequent re-keying is a better way to achieve forward secrecy. Regardless of which is the better way, both can be built on top of the encryption mechanism we offered in Proposal 295 whose goal is to resist crypto-tagging. In the interest of moving forward we propose to implement Proposal 295 as suggested or something close to it (e.g., using POLYVAL) to counter crypto-tagging, then discuss alternatives to achieving forward secrecy and add those on top of the ADL construction via Proposal 308. A few side notes: 1. Proposal 308 argues that POLYVAL is more suited than GHASH to our this use-case. This is an implementation issue. GHASH or POLYVAL or any other collision resistant hash function are all the same to us. 2. I'm pretty sure there's a typo on Line 250 in Proposal 308 and that the text should be Y_I = Tf_{I+1} ^ X_I. Otherwise, I can't see how the protocol decrypts on Line 285. 3. The lengths in Section 2.2 (marked for revision) are given in bytes, but then in Section 2.3 they are treated as bits. 4. Line 230 has unbalanced parenthesis. Tomer

2 1

Optimistic SOCKS Data
by Tom Ritter 15 Oct '19

15 Oct '19

The attached is a draft proposal for allowing tor to lie to an application about the SOCKS connection enabling it to send data optimistically. It's going to need some fleshing out in ways I am not familiar with, but I wanted to get something out to start as we think that this is probably the best path forward for bringing back Tor Browser's optimistic SOCKS behavior. -tom

6 11

maint-0.4.2 is now a separate branch; master is now 0.4.3.x
by Nick Mathewson 11 Oct '19

11 Oct '19

Hi! If you're writing a patch that needs to go into Tor 0.4.2.x, please base it on the new "maint-0.4.2" branch. The "master" branch is now for developing the new and exciting Tor 0.4.3.x. If you use git-pull-all.sh, git-push-all.sh, or git-merge-forward.sh, please be sure to update to the latest versions in the master branch; they know about the maint-0.4.2 and release-0.4.2 branches. cheers, -- Nick

1 0

Exposing onion service errors to Tor Browser
by George Kadianakis 02 Oct '19

02 Oct '19

Hello list, we've recently been thinking about how to expose onion-service-related errors to Tor Browser so that we can give more useful error pages to users. We currently return "Unable to connect" error pages for any kind of onion service error, and I think we can do better. This is a thread to think about the errors we want to expose, how that should look like, and what options we should give to the users when it happens. Relevant master tickets are #30022, #30025 and #30000. We decided (in #14389) that Tor will export these errors through the SOCKS port, and the relevant spec is proposal 304 [0]. As part of #30090 antonela started making a table of potential errors. I'm gonna use that in this thread and also add a few more. Let's go: = Client-level errors = These are errors on the user side of things: === 1) Typo error on address === This can be detected by Tor using the checksum or if the address is too big or too small. TODO: We will need to add a new error code to prop304. Not sure if the error code should distinguish between checksum fail or length fail. There is no recovery here since the address is busted. The user needs to find the right one. === 2) Missing Client Authorization === This is prop304's 'F4' error (see #30382), and it means that we can't decrypt the descriptor because it requires client auth, but we don't have it configured. The recovery here is the whole point of #30237 where we make a dialog for the user to insert their client auth credentials. === 3) Wrong Client Authorization === This is prop304's 'F5' error, and it means that there client auth credentials configured for this onion are wrong. The user recovery here is unclear but it might be that they need to change their client auth credentials. IMO, we should not try to make the perfect UX here, and we should just go with something super simple. = Service-level errors = These are errors on the onion service side: === 4) Service Descriptor Can Not be Found === This is prop304's 'F0' error, and it means that we could not find the descriptor of the service on the directory servers. This means that the service is not up right now (or, more unlikely, that some bug has happened somewhere). The user recovery here is unclear. The user can try to reconnect in case the service got up in the meanwhile, but this is not so likely in a small period of time. Perhaps we can give the user the option to reconnect every 10 seconds or so? Does this make sense from a UX PoV? Again this equivalent to a "Remote host is down" error and we should use it as such. = Network-level errors = These are errors caused by the network (directory servers, intro points, rendezvous points) or even the service itself. It's kinda unclear given all the hops involved. === 5) Onion Service Descriptor Is Invalid === This is prop304's 'F1' error and it means that we got a descriptor back from the directory but it's corrupted. This is very unlikely to happen since directory servers do not keep corrupted descriptors, so it usually means that some bug happened somewhere (or that the directory is bad or confused). In terms of recovery and error page, this is kinda an "Oops. Internal error." situation where this is rare and weird and hence we don't know what's the best recovery option. We can give the option to reconnect but it's likely not gonna help much. Again this should never really appear, so let's not stress too much over it. === 6) Onion Service Introduction Failed === This is prop304's 'F2' error and it means that for some reason the introduction did not complete. This could be because the onion service is not up anymore, or it could be because the network is screwed in some way (e.g. the service is DoSed). The recovery here might be some 'reconnect' button which could be helpful in case of a DoS situation, but it would not help much if the service is not up anymore. === 7) Onion Service Rendezvous Failed === This is prop304's 'F3' error and it means that the rendezvous did not complete. This usually means that the service is having a bad time, and is either DoSed or it generally cannot cope. The recovery again here is some 'reconnect' button, since if we did the introduction successfuly, the service is up, and reconnecting might work at some point. This one and (6) are very related and perhaps they can be handlded identically, since exposing terms like "intro" and "rend" to users will not be nice. Still we might want to expose a technical error value somewhere for debugging purposes when users come to us. ======================================================================= I think the above set of errors will satisfy all our needs. In particular: - #30022 (typos ticket) needs error (1) from above. - #30025 (client errors ticket) needs errors (4), (5), (6), (7) from above. - #30000 (client auth) needs errors (2) and (3) from above. In terms of error page, I'm not sure how it should look like. Perhaps along with the error description and the recovery path, we should provide some education about onion services to the users? In terms of unsafe paths, I don't see any of these errors being dangerous in terms of causing security issues if you attempt to reconnect or anything. The Tor protocol takes care of this in the layer below. The worst thing you can do is slightly damage the network from too many reconnects, but I think that's OK since people who use the TB are legitimate users and not DoS attackers. === Hope this was useful! [0]: https://github.com/torproject/torspec/blob/master/proposals/304-socks5-exte…

3 3

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

Please sent me a video that how to get dark web please

3 3

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

What should I do

1 0

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

Okay

1 0

Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography
by Jean Paul Degabriele 23 Sep '19

23 Sep '19

Hello tor-devs, Martijn Stam and myself have previously worked on analysing the security of proposal 261. Together with Martijn's PhD student, Alessandro Melloni, we have now written a proposal for an onion encryption scheme as an alternative to Proposals 261 and 295. It builds on the GCM-RUP construction from [ADL17] but it offers a number of improvements over proposal 295. In addition to addressing the issues described below we expect it to offer better performance. We are currently working on a security proof and potential efficiency optimisations for this scheme. In the meantime, we would be very happy to hear what you think and any feedback you may have. If something is unclear, please let us know. Best, Martijn, Alessandro, and Jean Paul --------------------- In our assessment of proposal 295 we identified the following issues: a) Improper use of the universal hash function. The proposal suggested using GHASH, a universal hash function, to compute the digest. Universal hash functions require their input to be independent of the hash key for security to hold. This is also a basic requirement in the tweakable block cipher construction, underlying the PIV and RUP constructions. However, the construction requires feeding back the digest (which is key-dependent) back into the input of the hash. Note that such feedback was not present in [ADL17] and the security proof breaks down with this modification. b) Lack of Forward Security for any type of hash function that is used. If instantiated with GHASH, proposal 295 does not provide forward security (as it is easy to invert given the hash key). The designers suggested (on the Tor dev mailing list) that forward security could be achieved by instantiating the hash function with SHA2 or SHAKE instead. Clearly this degrades the efficiency of the scheme but, as we argue below, it still does not suffice to achieve forward security Specifically, even if the hash function is instantiated with an ideal hash function (a random oracle), the construction succumbs to the following attack. Assume that the last OR in a circuit of length n has already processed some cells and that its current state is (Kf_n, Kb_n, Ktf_n, Ktb_n, Khf_n, Khb_n, Tf'_n, Tf'_{n+1}, Tb'_n, Tb'_{n+1}). An adversary, who has collected previous ciphertexts and nonces (C, N), then corrupts it. The adversary has enough information to recover the last message received by OR_n, which it computes as follows: N_{n+1} = Tf'_n ^ D(Ktf_n, Tf'_n ^ N_n) M = Decrypt(Kf_n, N_{n+1}, C_n). Clearly this breaks forward security, and it is enabled by the fact that the current digest needs to be saved for computing the next digest for when another ciphertext is received. [ADL17] Tomer Ashur, Orr Dunkelman, Atul Luykx, "Boosting Authenticated Encryption Robustness with Minimal Modifications", CRYPTO 2017.

3 3

Timing of opening pre-emptive circuits?
by Jeremy Rand 20 Sep '19

20 Sep '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Tor-Dev, I'm curious what the timing is of Tor's opening of preemptive circuits. Specifically, consider the following attack: 1. A new stream is assigned to a clean circuit. 2. Because of the above, that clean circuit is now a dirty circuit. 3. Because of the above, the number of clean circuits is now decreased by 1. 4. Because of the above, the number of clean circuits is now lower than the number that Tor wants to have open. 5. Because of the above, Tor opens a new preemptive circuit. 6. An attacker who can observe the circuit in (1) and the circuit in (5) can deduce by temporal proximity that those 2 circuits belong to the same client. This attack seemed obvious enough to me that I assumed that Tor must have some kind of countermeasure to it, e.g. random delays in opening preemptive circuits. However, the tor-path specification doesn't mention any such countermeasure, and based on a brief search through the Tor source code, all I can find is that Tor opens preemptive circuits using a function that always gets called once per second (with no mention of any delay beyond that one-second interval, random or otherwise). So, does Tor make any effort to mitigate the above attack? If so, what mitigations are present, and where would I find them (in both the spec and the source code)? If not, is there any documented reason (e.g. "the attack is too hard to pull off" or "we want to mitigate it but haven't gotten to it yet") for the lack of mitigation? Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile(a)airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy(a)veclabs.net is having technical issues at the moment. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEVB3fdzAraEcoBtkSs/LRZXhtZXAFAl2CoycACgkQs/LRZXht ZXDyjhAAk3F6fJUvNl4FHws6IIBHWXby/zC7MLzr9zR3sIC3RY4f/I7XBDTKKfMg iOehJlBEksm5sRz6nlybUBivsJ0WRL8VCT3rEK3+LQM7JrYNvGajolEw2apBUeB3 +Vg+Quo5JzTZrjCtXljxdps/hhC1YwEyN6pxxn2137q4XAsRPQgSCcWpsBuDTffb LFRwyGrNxk6chbpQc0GIWQRoeElxFwaLbUrZdGtaaEjBXY2oWoan1TUB34MAVNzF 1o6DlaO2JQ7weHVHoXlTlXS7gt84/WyY0xaHUY9ONHwrhgDPGv3N5+Fa2Em+PvGx ik+4iSCzPf6aKY0iUv1AsWKiaq8rRsMToyNzNZ048uYHk2IK2Zrbqh4Nm44RTzKD 84tJU71calRdNhbwuvmgsYKh26Ad9ALf9BzDeiweA3c5ZP0JP0OlLcAN9c056WT3 FQbChA1edZkWkPvBjGtl4l7ROIx6wkNpWgaQsYUCMveszB2Rm38BQw5sYLh8i6ha AlT3UVs/GJscSSsfmHGrTisao444Etp4J/+SFe1aNJwfOogbEfgJ1jRf8V5dlYEb rcicgkwmnBf01vnVaUO9C6/lToUa9i7r3BD3s6OQW24qz2ixieS3K6NxxxqMrVQ1 vFArleJIYA/FsDM2NPbeaUQA9z5GJj5X3FcPUPLLF+y5G/0HE14= =aBRL -----END PGP SIGNATURE-----

2 2