- tor-dev - lists.torproject.org

Proposition: Applying an AONT to Prop224 addresses?
by Alec Muffett 15 Apr '17

15 Apr '17

Hi, So: a bunch of us were discussing Prop224 Onion addresses, and their UX-malleability. Specifically: that there are small bit fields in the current Prop224 Onion Address schema (eg: version, and other future structure?) which can be tweaked or amended without otherwise changing the functionality of the address, or without much changing what the user sees in the (say) browser address bar. This is a point of significant concern because of issues like phishing and passing-off - by analogy: t0rpr0ject.0rg versus torproject.org - and other games that can be played with a prop224 address now, or in future, to game user experience. We discussed the existing "hash the public key before base-32 encoding" approach, but hashing breaks the prop224 key blinding. Ian Goldberg - thank you Ian - offered this attractive solution: apply a *reversible* "All Or Nothing Transform" (AONT) to the entire Prop224 Onion Address, prior to Base32 Encoding. This way, even a single-bit mutation of (say) version number will have a "diffusion" effect, impacting ~ N/2 of the bits whilst having O(1) cost and being reversible so as not to impact the rest of Prop224. The result would be onion addresses which are less "tamperable" / more deterministic, that closer to one-and-only-one published onion address will correspond to an onion endpoint. What does the panel think? - alec -- http://dropsafe.crypticide.com/aboutalecm

7 27

Interest in collaborating on a standard Ed25519 key blinding scheme?
by Tony Arcieri 15 Apr '17

15 Apr '17

I'm trying to gauge interest on the IRTF's CFRG mailing list regarding collaborating on a draft for a standard Ed25519 hierarchical derivation / key blinding scheme: https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA The post makes several mentions of Tor's work in the space in regard to the next-generation hidden services design. I think it'd be great if Tor were to collaborate on the design of such a scheme and adopt it for the new hidden services design. I see a lot of convergent evolution in this space and think it would be great if there were a single standard everyone could implement. Even if you don't, I think there are some ideas from similar schemes Tor should fold back into its own design, particularly in regard to how certain bits of the private scalar are "clamped". Some discussion of that here: https://moderncrypto.org/mail-archive/curves/2017/000862.html tl;dr: clamp the third highest bit of the root scalar to zero (in addition to the bits normally clamped in the non-canonical Ed25519 private scalar), and use 224-bit child scalars. -- Tony Arcieri

5 5

Re: [tor-dev] Interest in collaborating on a standard Ed25519 key blinding scheme?
by Oleg Andreev 15 Apr '17

15 Apr '17

> From: George Kadianakis > Date: Wed, Apr 12, 2017 at 7:57 AM > > An update: > > After lots of discussions in the Amsterdam Tor meeting, the following > approach was suggested for cleansing keys of their torsion components > that is more friendly towards hierarchical key-derivation schemes: > https://moderncrypto.org/mail-archive/curves/2017/000866.html > > However, my current intuition is to just not do this for hidden service > ed25519 blinded keys. Those keys are only used for signing descriptors > which should be safe to do, and we don't plan to use them for D-H any > time soon. If we or some crazy app EVER decides to use those ephemeral > keys for key exchange, we would need to use a special DH function that > kills the tensor component of keys before using them, as suggested by > Trevor here: https://moderncrypto.org/mail-archive/curves/2017/000874.html > > Please let me know if you think this is not a good idea! Thanks for the update, George. TL;DR: your scheme seems to be just fine for signatures, and even torsion-safety issues are not huge issues IMHO. For wide applicability reasons, I am trying to make our scheme ChainKD [1] to fit as many use cases as possible and therefore very interested in Tor's requirements and rationale regarding Tor's key blinding proposal. L;R: After studying the situation with key derivation schemes for Ed25519, my impression is that the central issue is not even safety, but compatibility with existing Ed25519 implementations. People who have to integrate a key derivation scheme in their protocol are often not the same people who write the underlying primitives such as scalar multiplication. This means, that it's safer to be conservative and keep the derivation scheme as compatible with EdDSA as possible so that assumptions that implementors may take by just reading the EdDSA spec without knowing about key derivation schemes, do not cause compatibility problems. Since it's not a trivial task to even learn the landscape of problems around Ed25519 compatibility- and safety-wise, it'd help if we can figure all of that once, implement and reuse the result w/o having to go through this again and again. Hence, our interest in standardizing the scheme that satisfies as many requirements as possible. <comic relief> https://xkcd.com/927/ </comic relief> Following the feedback in BIP32-Ed25519 paper [2], I've updated our ChainKD [1] scheme to make it safely "compatible" with DH use cases (among those is asymmetric encryption such as ECIES). In the Design Rationale section [3] I try to describe the issues with low/high bits and torsion-safe representative and why we choose to keep those bits as defined in Curve25519 instead of "torsion-safe representative" and why we use BIP32-style blinding-by-addition instead of blinding-by-multiplication. One piece of feedback affecting our proposal is missing, though: I'd like to ask Tor developers what is the rationale and requirements for their key blinding proposal. Specifically, why do you choose to blind via multiplication instead of addition: s' = b*s; P' = b*P (Tor's proposal) vs s' = s + b; P' = P + b*G (BIP32, ChainKD) (G -- base point, P -- pubkey, s -- secret scalar, P = s*G, b -- blinding scalar) I know of a few reasons to use addition over multiplication (e.g. performance and bit-compatibility with EdDSA), but would love to learn if that hurts some protocols. PS. I've just joined the list and replying to a forwarded message. I apologize if I break the thread. [1] ChainKD, revised: https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications… [2] BIP32-Ed25519: https://drive.google.com/open?id=0ByMtMw2hul0EMFJuNnZORDR2NDA [3] ChainKD rationale: https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications…

2 1

Re: [tor-dev] [Twisted-Python] txtorcon versioning
by meejah 13 Apr '17

13 Apr '17

Manish Tomar <manish.tomar(a)gmail.com> writes: > If you don't mind, could you describe your reasoning behind this > decision? I am always curious to learn any concrete reasons behind > this. If this seems spammy to the mailing list, please feel free to > respond only to me. Mostly because I don't want to ever have breaking changes, so then you're "not supposed" to upgdate the big version number. I haven't found that "semantic versioning" has been working very well for the release-style of txtorcon. Other, less important reasons: Twisted does this; it's easier to tell "how new" a release is; and big version numbers are cool (just kidding). -- meejah

1 0

Release: sandboxed-tor-browser-0.0.5
by Yawning Angel 13 Apr '17

13 Apr '17

Hello, I just tagged sandboxed-tor-browser 0.0.5. Binaries will be built when the next Tor Browser build happens (soon). Astute readers will notice that I skipped the release announcement for 0.0.4, which was tagged yesterday. This is due to changes related to e10s being enabled in the next alpha release, that were caught after the 0.0.4 tag was created. Changes in version 0.0.5 - 2017-04-13: * Bug 21764: Use bubblewrap's `--die-with-parent` when supported. * Fix e10s Web Content crash on systems with grsec kernels. * Add `prlimit64` to the firefox system call whitelist. Changes in version 0.0.4 - 2017-04-12: * Bug 21928: Force a reinstall if an existing hardened bundle is present. * Bug 21929: Remove hardened/ASAN related code. * Bug 21927: Remove the ability to install/update the hardened bundle. * Bug 21244: Update the MAR signing key for 7.0. * Bug 21536: Remove asn's scramblesuit bridge from Tor Browser. * Fix compilation with Go 1.8. * Use Config.Clone() to clone TLS configs when available. The main major change is the eradication of support for the `hardened` series, as the Tor Browser team will be dropping it starting from the next release (#20814). The impact on `sandboxed-tor-browser` + `hardened` users is thus: * (< 0.0.4) Will not correctly transition to the alpha channel. Sorry. The bundle may or may not be rendered non-functional by the transition update, I don't have a good way to test the Tor Browser auto update infrastructure with updates that haven't been released yet. * (>= 0.0.4) When `sandboxed-tor-browser` is launched, it will detect the `hardened` bundle and force a reinstall. This will eradicate the existing bundle directory obliterating user customization, bookmarks, and downloads (unless the download directory is overridden). A warning dialog box is displayed prior to booting the user back to the installation screen. Known issues: * Sending SIGINT to `sandboxed-tor-browser` (or likely otherwise killing the process) will leave the firefox process running on ESR52 + e10s builds, *unless* bubblewrap is version 0.1.8 or newer. Exiting firefox normally works as intended. Regards, -- Yawning Angel

1 0

txtorcon versioning
by meejah 13 Apr '17

13 Apr '17

I will soon release the next version of txtorcon with a ton of cool new features. This will be called 0.19.0. More details: http://timaq4ygg2iegci7.onion/releases.html Going forward, versioning will switch to a "CalVer.org" variant. At one point, I thought of breaking a few now-regrettable APIs. However, I will not do this. The next version after 0.19.0 will be 17.x.y Changes in any existing APIs will be done by first introducing the new thing, deprecating the old thing and eventually removing the old thing. The new documentation's "programming guide" includes some notes on API stability. I have not to date broken/changed any existing API. Also at this point nothing is deprecated (but there are "preferred" APIs). The onion services APIs *will* change for the 17.x release. New code should follow the recommendations in the programming guide. Existing code will continue to work for the forseeable future. thanks, meejah

2 2

GNU Guix and Tor Browser Packaging
by bancfc＠openmailbox.org 11 Apr '17

11 Apr '17

There is a serious Tor Browser packaging effort [3][4] being done by ng0 (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles and most importantly reproducible builds. I have checked with Guix's upstream and they are working on making a binary mirror available over a Tor Hidden Service. [2] Also planned is resilience [2] to the attack outlined in the TUF threat model. [1] Back to the topic of Tor Browser packaging. While there are good reasons for Debian's pakaging policies they make packaging of fast evolving software (and especially with TBB's reliance on a opaque binary VM for builds) impractial. Both we and Micah have been doing a good effort to automate downloading and validating TBB but I still believe its a maintenance burden and Guix may be a way out of that for Linux distros in general. What are your thoughts on this? *** [0] https://www.gnu.org/software/guix/ [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html

2 2

Re: [tor-dev] Contents of tor-dev digest...
by Mike Guidry 11 Apr '17

11 Apr '17

I am not trolling you. I attached a PDF which explains how to trace TOR connections over the internet. It is not a joke. I have some other vulnerabilities at that URL I am releasing. I'll include here: Michael Guidry March 15, 2017 Tracing connections online from the virtual landscape to the physical world Hacking is the intrusion of a computer by an unwanted guest, and is usually used to express gaining access to corporate, or government networks. It requires either installing using malware, phishing, or directly connecting to machines and attacking their software with exploits. It is currently impossible to accurately trace hackers online unless they use the same software, and techniques for all their targets. It has become a major problem within the last decade due to globalization, and corporate networks directly connected to the Internet. Tracing Transmission Control Protocol (TCP) connections across the Internet is inaccurate due to how routing is performed across global backbones. The global routing table is modified constantly with nodes, and routes being adjusted for optimization, or quality of service needs. TCP is the most used protocol therefore it is the only protocol which really matters to attempt to trace. User Datagram Protocol (UDP) is state less therefore less reliable for tracking, however has the same vulnerability. UDP is usually used by hackers for exfiltration, or remote control after other actions have been performed. It is currently impossible to track connections over the Internet accurately. Several cases relate to The Onion Router (TOR) sites aka “Dark Web,” which were somehow uncovered using private technologies. Technologies used for those cases do not work properly over regular hacking via proxies online. Its an issue for the landscape of political hacking worldwide which has been increasing annually across the globe. China, for example, has been having a lot of blame lately due to Internet Protocol (IP) addresses assigned within its borders being used in massive amounts of attacks. Some of these attacks have been supposedly verified, however it is impossible for China to have performed them all. Proxy servers being used in chains may just be victims themselves. The problem arises due to possible evidence planting being similar to proxying through their others networks, or borders. It is completely different comparing cyber war to traditional conflicts due to evidence being traceable, and soldiers physical evidence being easily recovered. Hacking back is a concept any government, or corporation is now detailing within their playbook to understand how the liabilities may affect them. It is the terminology used to attack the source of an intrusion by means of hacking itself. Repercussions of hacking a country due to incorrectly assuming an attack was originating there is highly possible. Cyber war policies exists for a lot of nations, and it may easily escalate their attention on whom they believe is performing the attacks. The same happens with ‘proxy wars’ currently within the middle east, etc. Proxy wars traditionally will have global evidence allowing verification of weapon deliveries, or monetary exchanges to determine the origin of funding. Soldiers training methods, and other strategies may be impossible to cloak. It is generally accepted once verified, and escalation is directed towards the proper perpetrator. Internet Service Providers (ISP) have the ability to perform various tasks internally to determine the pathways through their networks which would reflect lateral hacking movements. Connections leaving a single network that enter the realm of dynamic routing via Border Gateway Protocol (BGP) become a nightmare. The percentage of accuracy decreases exponentially as each separate network is used to route the connection to its destination. It becomes nearly impossible to trace after just a few gateways at least publicly, or academically. Unorthodox methods are required to allow tracing of connections under these circumstances. Distributed Denial of Service (DDoS) is a solution that allows you to turn the internet’s own packet distribution system into a tracking mechanism. Most people do not consider performing DDoS attacks for positive reasons. DDoS may have been used by targets to “quarantine” their hacking source temporarily from the Internet. This strategy is beyond the scope of this technique, and is literally only a bandaid for a single attack originating from possibly just a proxy. DDoS is also illegal in most nations which have advanced their cyber crime laws. The fact that this technique requires many computers performing attacks strategically placed across the globe also ensures that they will be performed from countries where these laws are being enforced. The attack requires attacking all networks that you wish to verify against therefore you are immediately breaking laws on the destination side of most of the world simultaneously. It should not be used lightly, or regularly without cause and understanding. DDoS attacks transmit more data to a destination than a that network can handle which forces it to stop responding in a timely fashion. The latency is so high that the TCP timeouts are reached, and connections break. New connections are also impossible during these attacks. It has only had negative effects since it began being used globally regularly. This technique could be considered a reverse DDoS. The approach is to attack the entire world in a very strategically timed manner using worldwide machines. Each separate DDoS attack using machines worldwide would use different synchronization, and timing information which would allow embedding information directly into the latency it causes on those networks. The purpose is to compare that latency with the hack taking place to verify its source location. If the attack disrupts networks your attempting to verify against for milliseconds up to a few seconds then you can perform several of these sequentially to embed information in this timing itself. DDoS then becomes a positive useful solution even though technically illegal to a currently difficult problem. You wouldn’t necessarily have to attack the entire world. Conceptually it would be better to use databases of networks wishing to verify against. Residential, and commercial IP delegations throughout most nations would cover a large portion. Government hacking groups have their IPs leaked often as well. It is possible to just perform the attacks on these particular sets of IP addresses rather than the world as a whole. It is also equally possible to perform the attacks on entire ISPs, and countries to quickly determine although this would not be accurate due to possible proxies in between being within that country. If the technique is used on a major ISP network rather than a gateway going into an office then it is possible that a proxy exists within their network which would read off as a false positive. Accuracy relies on the networks your verifying against to be actual end user machines which would have human attackers. If you were to attack a network, or router of a network which has an office then it is highly likely they are going to notice other hackers using their network to hack externally on scales which would involve this type of solution. If you were to attack an entire country then you are going to have a problem of not recognizing from timing alone whether or not a proxy (of possibly several) just exist in that country. It is imperative to understand this, and always attempt to get as close to the networks in question being verified. Original message: Are you trolling us? I don't get it! On Sun, Apr 09, 2017 at 08:19:28PM -0400, Mike Guidry wrote: > Hello, > > Here is a document I've wrote regarding a concept to trace connections even > through TOR. If you have any questions feel free to respond, and I'll > attempt to explain. I have also considered a way to mitigate this > situation being allowing TOR to be traced by using 'Transactional > Requests.' I'll proceed to write it up, and post soon. > > I have released some other short papers as well. It contains several files > regarding a few vulnerabilities, and a couple concepts regarding things > like quantum resistant cryptography, etc.. > > URL: https://mega.nz/#F!QnZRXKyS!oluyILlMPpyJjPS57w7axQ > > Feel free to e-mail me directly.. > > Thanks, > Mike Guidry

2 4

Re: [tor-dev] Tracing TCP Connections online..
by Mike Guidry 10 Apr '17

10 Apr '17

re: grarpamp I am writing a possible countermeasure which uses transactional requests. You submit entire requests which are processed by the exit node. Several other situations can take place while routing to the exit node. It would also only require exit nodes to have updated to the newer feature. I'll post as soon as I'm finished.. Thanks, Mike Guidry ----- >This appears to describe an active network modulation attack (node DoS). >Either hammer tree on nodes of the expected path and trace the modulation, >or on all but the expected path to find unmodulated. >It generally requires GPA, deploying nodes, or being one end of the path... >in order to observe the results. >And it's old news. >As noted before, since Tor (and all other current anonymous overlays) >nodes do not perform their own independant buffering, reclocking and >contracting for expected hop parameters... this vulnerability will remain. >Anyone wanting to research, code, deploy, and present on >such countermeasures would certainly be welcomed.

1 0

Control-port filtering: can it have a reasonable threat model?
by Nick Mathewson 10 Apr '17

10 Apr '17

Hi! As you may know, the Tor control port assumes that if you can authenticate to it, you are completely trusted with respect to the Tor instance you have authenticated to. But there are a few programs and tools that filter access to the Tor control port, in an attempt to provide more restricted access. When I've been asked to think about including such a feature in Tor in the past, I've pointed out that while filtering commands is fairly easy, defining a safe subset of the Tor control protocol is not. The problem is that many subsets of the control port protocol are sufficient for a hostile application to deanonymize users in surprising ways. But I could be wrong! Maybe there are subsets that are safer than others. Let me try to illustrate. I'll be looking at a few filter sets for example. ===== Filters from https://github.com/subgraph/roflcoptor/filters : 1. gnome-shell.json This filter allows "SIGNAL NEWNYM", which can potentially be used to deanonymize a user who is on a single site for a long time by causing that user to rebuild new circuits with a given timing pattern. 2. onioncircuits.json Allows "GETINFO circuit-status" and "GETINFO stream-status", which expose to the application a complete list of where the user is visiting and how they are getting there. 3. onionshare-gui.json Allows "SETEVENTS HS_DESC", which is exposes to the application every hidden service which the user is visiting. 4. ricochet.json Allows "SETEVENTS HS_DESC", for which see "onionshare-gui" above. 5. tbb.json Allows "SETEVENTS STREAM" and "GETINFO circuit-status", for which see "onioncircuits" above. ===== Filters from https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/to… : 1. onioncircuits.yml See onioncircuits.json above; it allows the same GETINFO stuff. 2. onionshare.yml As above, appears to allow HS_DESC events. It allows "GETINFO onions/current", which can expose a list of every onion service locally hosted, even those not launched through onionshare. 3. tor-browser.yml As "tbb.json" above. 4. tor-launcher.yml Allows setconf of bridges, which allows the app to pick a hostile bridge on purpose. Similar issues with Socks*Proxy. The app can also use ReachableAddresses to restrict guards on the . Allows SAVECONF, which lets the application make the above changes permanent (for as long as the torrc file is persisted) ===== So above, I see a few common patterns: * Many restrictive filters still let the application learn enough about the user's behavior to deanonymize them. If the threat model is intended to resist a hostile application, then that application can't be allowed to communicate with the outside world, even over Tor. * Many restrictive filters block SETCONF and SAVECONF. These two changes together should be enough to make sure that a hostile application can only deanonymize _current_ traffic, not future Tor traffic. Is that the threat model? It's coherent, at least. * Some applications that care about their own onion services inadvertantly find themselves informed about everyone else's onion services. I wonder if there's a way around that? * The NEWNYM-based side-channel above is a little scary. And where do we go forward from here? The filters above seem to have been created by granting the applications only the commands that they actually need, and by filtering all the other commands. But if we'd like filters that actually provide some security against hostile applications using the control port, we'll need to take a different tactic: we'll need to define the threat models that we're trying to work within, and see what we can safely expose under those models. Here are a few _possible_ models we could think about, but I'd like to hear from app developers and filter authors and distributors more about what they think: A. Completely trusted controller. (What we have now) B. Controller is untrusted, but is blocked from exfiltrating information. B.1. Controller can't connect to the network at all. B.2. Controller can't connect to the network except over tor. C. Controller is trusted wrt all current private information, but future private information must remain secure. D. Controller is trusted wrt a fraction of the requests that the clients are handling. (For example, all requests going over a single SOCKSPort, or all ADD_ONION requests that it makes itself.) E. Your thoughts here....? signing-off-before-this-turns-into-a-capabilities-based-system, -- Nick

8 10