(versione italiana)

Anonymity is a word with many meanings, so let's quickly make clear which kind of anonymity we mean. We intend the protection of the metadata of who is talking to whom in a social constellation, defending the principle of freedom of association in an increasingly surveilled world.

A video summary of this page is available from ChaosWest: Three and a Half Ways to Enhance Metadata Protection Beyond Tor.

Why did secushare pick GNUnet rather than Tor or similar technologies?

Social scalability is the issue

The most critical reason to pick GNUnet is the long-term need of secushare to have a strategy for many-to-many scalability. Both Tor and I2P can scale well in the number of one-to-one communications, but this only re-enforces the client/server paradigm which is threatening the privacy and thus the democratic civil rights of billions of human beings. Actual scalable, serverless, distributed social interaction requires a pubsub system over a distributed scalable multicast backbone, natively capable of spawning distribution trees somewhat like BitTorrent. You can also compare it to cloud technology, only that the cloud is diverse and belongs to its users (easily said but quite hard to implement). In unison with the GNUnet team we are working on this. cjdns could be a nice intermediate solution on this front if anonymity wasn't a goal.

Sybil attacks hit you when it's too late to change the entire architecture

As also discussed in comparison, both I2P and Tor have some open issues with their use of Distributed Hashtable (DHT) technology prone to sybil attacks. GNUnet has designed its routing (core) and GNU Name System (GNS) in ways that are resistant to such attacks.

Shaping the traffic of socket-oriented applications

Also, both Tor and I2P suffer from their will to deliver best-effort real-time service, making the traffic susceptible to shaping and fingerprinting and therefore traceable by a global active attacker such as certain spook agencies. The measures discussed in the Tor community for dealing with this problem are just what GNUnet has already been providing from the start: a constant bandwidth stream between nodes which in Tor would only be network load while in GNUnet it is used to deliver unrelated yet useful information such as file sharing replication or low-priority social networking chatter. These measures can make parts of the journey along the onion circuit resistant to fingerprinting. There is also a proposal to improve Tor's resistance against traffic fingerprinting called alpha mixing, but it has been lying around unimplemented since 2006. A decade later, research has come up with other ways to protect onion routing against fingerprinting attacks. These strategies make even more sense when deployed in GNUnet, since decoy traffic isn't just overhead, it is useful to other purposes.

So, is GNUnet more anonymous than Tor or I2P?

Both Tor and GNUnet provide us with excellent code quality and sound conceptual foundations coming from a scientific background. Yet, an authority-free onion routing strategy for GNUnet is still in the making. That doesn't mean that GNUnet is not enhancing anonymity already. The secushare/GNUnet anonymity strategy stands on four feet:

  1. the cover traffic from file sharing, DHT and eventually multicast,
  2. the framing of application data (explained below),
  3. mixnets for high-latency applications (see below),
  4. unpredictable routing provided by CADET now, onion routing later.

While Tor puts all bets on strategy 4 and I2P is somewhere closer to strategy 2, we think to achieve anonymity it's best to use all strategies and only leave out some of them when inevitable.

For example we can afford not to have a permanent bandwidth allocation if we have framing and onion routing, thus allowing for distributed social networking apps on mobile phones.

Or we can afford to reduce the onion routing for real-time traffic if we can segment and mix it with file sharing data, this way also defeating phoneme detection attacks on voice traffic. (1) (2) (3) (4) (5)

Or we can surf the insecure web and risk fingerprinting attacks if the traffic then goes through onion routes over constant bandwidth channels.

*There is an advantage in synergy if we use one coherent stack to replace the broken Internet rather than try to have separate tools attempt to solve the challenges of anonymous real-time and bulk data exchange separately.*

And nothing keeps us from securing our best secrets like our political views, commentaries and intimate nudities by using all strategies at once.

Since GNUnet is already implementing two of the strategies (#1 and #2 above), it is currently not scientifically obvious, whether it serves a better or worse job at achieving anonymity than Tor, under the condition that you do not disable the anonymous file sharing service (which is stellar, by the way).

We have reason to assume that once onion routing over GNUnet comes available, GNUnet should become safer than its predecessors, even with file sharing disabled.

Authority-free Onion Routing

While Tor currently depends on a circle of friends to decide which relay nodes are trustworthy to elevate to guard node, exit node or directory server status, we are working on ways to let the software take these decisions itself.

Given a large distributed private social graph we expect we can come up with social and authority-free onion routing strategies right out of the data available to secushare. The PISCES paper has shown that strategies of this kind can work, better however if the social graph stays private.

In the meantime the GNUnet team is pursuing a strategy based on byzantine consensus called BRAHMS. If that is foreign to you, think of it as what happens when Bitcoin miners agree on what goes into the blockchain next. Summarizing, we have two possible strategies to achieve authority-free onion routing over GNUnet in the coming future. The ultimate trick could turn out to be to combine them.

What are the downsides of GNUnet?

It's the size of the community. With technologies that serve a purpose in many people's lives, a whole lot of attention is given to the already established rather than upcoming ones that are trying to address the issues the established ones cannot solve. A lot of financing and interest heading in the wrong directions by the nature of the attention economy. So if you join us, you are already working on improving GNUnet and secushare.

Other aspects that may disturb are rather superficial, like the primary choice of programming language, the process architecture and so on. Unfortunately a lot of developers choose the project to contribute to by entertainment factor rather than efficiency to solve a problem, so we are working on making secushare and GNUnet more fun to code for.

Another thing you may perceive as a downside is that application developers need to change their habits in order to achieve better anonymity, but that isn't an issue specific to GNUnet:

Framing Data to Detect Fingerprinting Attacks

APIs should not be as simple to use as those of Tor and I2P. This is because the problem of best-effort delivery urgency is already introduced by the POSIX socket API. The idea that you can just push things into that socket at any frequency you like and it will somehow pop out at the other end of the tube. This already bears a potential for fingerprinting the traffic the moment the generation of unencrypted packets isn't on the same machine as the anonymity router, as is regularly the case between websites and exit nodes. Or if the counterpart of your interaction is intentionally trying to de-anonymize you.

So all the nifty hidden service port mapping and SOCKS proxy emulation that Tor and I2P provide could be a problem. GNUnet does offer a similar best-effort service called gnunet-vpn, but using it possibly means introducing those security vulnerabilities into your applications over GNUnet. The safer choice is to design your applications in such a way that your messages are properly framed and GNUnet can optimize on delivering them as a complete package, never get confused by data arriving at the socket in nastily timing-fingerprinted bits, forcing the entire anonymization system to somehow provide a.. best-effort delivery.

Knowing exactly how much needs to be packed up and delivered is better than having to guess, so GNUnet can provide the same low-latency fast service, but isn't vulnerable to fingerprinting while doing so. Also, if a protocol demands a certain structured form of content, the GNUnet backend of a node that is being attacked can detect an attempt to throw fingerprinted breadcrumbs at it and reject to interact with the attacker further on.

Does this mean we won't surf the web over GNUnet?

Maybe Tor will remain the tool of choice to access the unsafe World Wide Web and browsing the web in a guaranteed anonymous way may never be possible again. Or maybe, if we combine the other two strategies being cover traffic and onion routing, we can afford to leave out framing.

Something we can certainly do is to produce a new kind of secure web which leverages the pubsub philosophy of secushare. A web that has no artificial best-effort requirements. This is described a bit in the business document, but it actually applies to any kind of content we like to share with people.

How can we hide the social relations from an adversary that sees all the traffic in-between?

Depends on how much obfuscation we configure into our software. Each message can be sent directly or over intermediate hops. If you use secushare correctly, you have a large second degree social network, even if you only know one or two people as a beginner. So there is always people chit-chatting about last night's party and multicasting photographs. There is a basic degree of cover data floating around, at least between those nodes that serve the purpose of obfuscating things (maybe you don't want to participate in that with your mobile phone, maybe you do). Also we will have server nodes that relay more than others. When they resend things, they delay it a bit, so it gets confused between all the other traffic.

As described above, GNUnet's habit of allocating a fixed bandwidth of data exchange between nodes makes it resistant to traffic shaping and fingerprinting attacks that Tor and I2P suffer from. GNUnet does not provide onion routing yet, however, so a node that participates long enough in the GNUnet backbone could de-anonymize participants over time. To mitigate that risk the secushare application can however choose to send data over trusted people, ideally providing social-graph based onion routing.

Social Onion Routing the secushare way

When using onion routing each person is addressed via the other end of one of its onion circuits rather than its actual node location. In the source code this doesn't even make a difference: in both cases there is a "PeerID" which knows how to deliver data to its destination, regardless of how long or short an onion route follows. Therefore in our code the PeerID may contain the onion meeting point rather than the factual node address of a person (unless a direct communication is fine for some purposes, but "direct" is merely a special case of onion routing with zero hops in-between, so it must not make any difference in the code and be not obviously discernable by outside observers).

Also our onion routing does not necessarily need to be using Tor's three hops. Even if we only have one onion hop, that hop would not know that the next node is already the last one. How much this may reduce the anonymity isn't researched as yet, but it only affects people who have chosen convenience over anonymity while some apps like video telephony may not seriously leave us a choice.

Other circuits may have more hops than usual with Tor. The PISCES paper mentioned above worked out a method for better onion routing which involves the social graph and an increased number of hops rather then the traditional three. Within Tor it is not recommended to use four-hops circuits, because the unusual behaviour could single the user out of the masses. This worry of course does not apply if all nodes use rather unpredictable numbers of hops for their circuits. What remains are circuits, the onion skins are optional.

secushare is a tool meant to throw in a reasonable amount of anonymity where it is easily feasible while giving people a user experience of a properly performing Internet. While people currently need to separate tools to decide if they are going to do something over Tor or in the nude, in secushare this choice is intelligently automated and never really fully naked. Even if only two GNUnet nodes are exchanging a large chunk of data, that data may still be a submission to a mixnet which the receiving node will forward elsewhere at a completely different point in time.

We are also discussing the possibilities of optimization of anonymity when combining onion routing with multicast. And then it also makes sense to make topological choices for onion hops to reduce latency. If you have a thousand nodes to choose from in your city, why use a direct connection for a phone call if you can have an onion-routed one? Tor developers see a threat in reducing anonymity this way, which is still subject to be proven or disproven, but if the alternative is to totally give into convenience, we have nothing to lose in preferring topologically optimized onion routing.

Mixnets: Enhanced Anonymity for High-Latency Applications

We have been discussing the idea of implementing mixnets into GNUnet, allowing each node to shuffle around messages internally before forwarding them on. This is surely going to introduce too high latency for some purposes, but some social networking needs should actually be fine with this. In any case, an attacker should not be able to tell the difference between a high security transmission and a single hop weather discussion banality.

What about combining Tor and GNUnet?

It is likely that putting Tor between the GNUnet nodes would not scale well because of the reasons discussed above, but Tor could still be used to better hide the current whereabouts of a user. Such an approach has been discussed in-depth in a thread on the tor-talk mailing list starting in December 2014 thru January 2015. Efforts in adding GNS and GNUnet routing support into Tor routers are heading that way, opening up for ways to use Tor as a door-opener into a distributed social network without requiring everyone to install the GNUnet codebase first.

Last Change: 2018-06-12