Building anonymization layer and toolset for libp2p based protocols

This post briefly explains why we are building/developing libp2p-mix as an anonymization layer for libp2p-based protocols. It also addresses several common questions, such as:

  • Why not use Tor for anonymization, as it is well-proven and has been in use for a long time?
  • Why not use existing generalized mixnet implementations such as Nym or Hopr?

This post can serve as a discussion space to clarify these and other questions.

This post collates earlier research conducted by @ksr , @akshaya , and others to explain why this direction was taken. It’s possible that some links or references may have been missed.
@ksr and @akshaya @haelius , feel free to add any additional details or artifacts that could provide further clarity. Also do correct/suggest changes if anything i have indicated below is not accurate.

Objective

The libp2p framework doesn’t currently provide any tools for sender/receiver anonymity, making libp2p protocols vulnerable to surveillance. To improve anonymity for libp2p users—such as Logos Messaging and Logos Storage, which are part of the Logos Technology Stack—we are developing an anonymity toolset to build an anonymization layer over libp2p-based networks. The ultimate goal is to provide utilities that anonymize all network-layer interactions in the Logos Technology stack.

As part of this effort, we have developed libp2p-mix, a protocol that provides enhanced anonymity. We have begun integrating it with Logos Messaging as a proof of concept to improve sender anonymity for publishers sending messages via Waku/Logos Messaging.

Why Not Use Tor or Dandelion?

The Tor Project is well-known for providing anonymity while browsing the internet, using onion routing to ensure web servers cannot identify clients. However, Tor has several weaknesses that make it unsuitable as an anonymization layer for our use cases:

  • Weak timing correlation resistance: Timing analysis attacks are possible (example).
  • Lack of fixed packet sizes: Variable packet sizes make it easy for observers to fingerprint traffic, enabling fingerprinting-based attacks.
  • Persistent circuits: The use of persistent circuits may not be suitable for request-response style libp2p protocols, which are stateless by design.
  • Susceptible to intersection attacks: Particularly vulnerable in low-traffic conditions.
  • TCP-only transport: Tor primarily supports TCP-based transports, which doesn’t provide the flexibility needed for libp2p protocols that can use other transports such as QUIC or local mesh transports.

There was an earlier attempt to enable message publishing over Tor via Gossipsub-Tor-Push, but as noted in the security/privacy considerations section, the weaknesses above make Tor a suboptimal candidate.

Similarly, there was an earlier attempt to use Dandelion++ for message publishing over Waku, but it was discarded in favor of Gossipsub-Tor-Push, which offers better anonymity guarantees.

However, considering the additional weaknesses of Tor mentioned above, a mixnet addresses these issues more effectively by providing:

  • Different paths for each message
  • Fixed packet sizes
  • Random delays at each hop
  • Cover traffic

Why Not Use Existing Generalized Mixnet Implementations?

Given that mixnets provide better anonymity properties, why didn’t we plan to use existing generalized mixnet implementations such as Nym or Hopr?

  • Not designed for libp2p: These mixnets are designed to act as VPNs for general web traffic, not for libp2p-specific traffic, which is peer-to-peer in nature.
  • Token dependency: They are tightly bound to their own tokens, which restricts usage.
  • For example, with HOPR, you would need to run a HOPR node and a Gnosis node.
  • Packet size optimization: Packet sizes may not be optimized for Logos-specific use cases.

Additional Benefits of libp2p-mix

Designing our own anonymization layer using libp2p-mix provides several advantages that are built into the protocol design:

  • Protocol Agnostic: Wraps around existing libp2p protocols without requiring major implementation changes.
  • Pluggable Components: Allows for customizable spam protection, peer discovery, and incentivization mechanisms.
  • Flexibility: Enables building different types of mix networks (e.g., circuit-based mixnets for Logos Storage, free-route non-circuit-based mixnets for Logos Messaging, and other mixnet types for different use cases).
  • Selective anonymity: Gives us flexiblity to selectively anonymize messages sent over same transport to a peer. (e.g only lightpush messages published can be anonymized whereas gossipsub messages sent out need not be anonymized)

Here is a reference to a quick anonymity analysis conducted with AI assistance. Also performed a quick comparison of Tor vs mixnets (even considering building circuits using mix). Note that detailed review and further research are needed to validate these findings.

7 Likes

Also found this interesting attack using BGP which seems to affect Tor. At a high level this feels like it shouldn’t affect a mixnet, but requires further analysis.