Anonymous IPFS

[Stebalien]

We've received many requests for anonymity support in go-ipfs. This issue tracks the issue and the related concerns.

First, there was a significant amount of work put into a tor transport. Unfortunately, reliable anonymity requires more than just TOR:

• Even if it's identity changes, an IPFS node is easily fingerprintable through the content it stores.
• IPFS would need an "anonymous" mode that only enables features known to not leak information:
  • No local discovery.
  • No transports except TOR.
  • Etc.
• A complete top-to-bottom security audit.
• Private routing (DHT 2.0 notes#291 (comment), DHT 2.0 notes#291 (comment)) to make the network non-enumerable.

Unfortunately, this is a lot of work and we have no plans on working on this till after the IPFS 1.0 release. Getting this wrong could put users in serious danger so it's not something we'll even experiment with till we're ready.

[agowa]

I'd like to add some thoughts about TOR, anonymity and onion transport integration for ipfs.
If we take a look at tor, it basically is an overlay network that allows two nodes to connect to each other regardless of the underlying network conditions. Hidden services identify them selves using there public key.

What that means if we use tor (not focused on anonymity):

• We do not need to care about NAT traversal within IPFS
• We do not need to care about IPv4 or IPv6 only nodes.
• The anonymity part could be left to people needing anonymity like with other hidden services e.g. by running nginx or apache.
• We could use 0 or 1 hop routes in the default case allowing others to establish direct connections to us if possible, therefore anyone requiring ip anonymity could just increase this in the tor client config to require the connection to pass through other tor nodes first, but focusing on performance for anyone else.
• We could announce ipfs nodes as (or as a kind of) tor relays.
• We would add legitimate traffic to the tor network, to protect those who need to hide. Adding plausible deniability.
• And all other points you listed regarding anonymous mode could be solved by an operator running ipfs in a vm/container and tor in another and only allowing the tor vm/container to make outbound connections. ipfs would therefore be forced to use tor and all other features could just leak the internal ip of the ipfs vm. No further access would be possible. In fact that is the minimum setup for hidden services to stay anonymous even if someone could own your hidden service. And it also protects from stuff like the apache status page information disclosure bug.
• We do not need to protect ipfs nodes from being fingerprinted, as hidden services are already identifiable. Adding a recommendation of using ipfs without persistent configuration (e.g. ipfs init) before each use for pure clients without any content could be added (as that is the only scenario that would be anonymous.
• If one would like to go hard core, the tor client could be patched to allow outbound traffic of an hidden service to also originate from the hidden service address and therefore the connection could be the authentication. And that could be a nice feature for ipfs nodes that sync data between hidden services. Or just a simple way to add secure node to node authentication (like ipsec).
• Accessing ipfs/ipns resources could be fully anonymous depending on the needs of the client without the server operator needing to change anything.

Summary:
I just want to say, that I see value in adding tor support early on as adding native support could free resources from other parts like nat/firewall traversal or ipv4/ipv6/mdns support, inter connectivity and focus resources on the important parts, like discovering and syncing content ;-)

[ojej]

please add freenet or mute transport too

[balupton]

@luisarriojas similar dismay echoed in this older and longer thread ipfs/notes#37 (comment)

[luisarriojas]

Reposting my comment as I deleted accidentally:
"Today, I jumped into the IPFS wagon and found that it is not censorship proof or uncensorable as it has been marketed. The documentation mentions that my IP address will be published to gateways, that means my ISP can cancel my contract as it has happened before to other people/companies in 2020 and 2021. IPFS should be anonymous by default."

[Stebalien]

It has never been marketed as censorship proof or uncensorable. Making the IPFS protocol itself uncensorable is a non-starter.

If you wish to discuss this, please make a post on https://discuss.ipfs.io.

[0xAnon101]

marketed as censorship proof or uncensorable. Making the IPFS protocol itself uncensorable is a non-starter.

Did this ever happen ?

[agowa]

marketed as censorship proof or uncensorable. Making the IPFS protocol itself uncensorable is a non-starter.

Did this ever happen ?

I don't think so. I stopped using IPFS because of this. It's way too risky becoming accidentally a publisher of some crap that could push you into legal trouble...

IPFS is currently "torrent roulette"...

[RangerMauve]

I don't think so. I stopped using IPFS because of this. It's way too risky becoming accidentally a publisher of some crap that could push you into legal trouble...

Just to be clear, when you run IPFS on your computer you are only loading content onto your node which you explicitly tell it to download. You won't have legal troubles just by running a node. If you're running a public gateway that others can use, then you have more liability and would wanna integrate a deny list like badbits to keep yourself out of trouble.

[RangerMauve]

I wanted to bring up that in order to make mixnets viable for the IPFS space, we'll likely need to figure out how to do key routing between peers who advertise on hidden services.

My hypothesis is that the Kademlia DHT inside libp2p is going to be way to slow for creating mixnet connections if we use the method of adding something like tor for multiaddress and having a few tor-enabled DHT nodes to bootstrap into.

I think it'd be worthwhile to sit down and talk about alternatives where we can rely more on persistent connections for routing since it's cheaper to keep mixnet tunnels going than it is to create new ones (I may be wrong on this point?).

One thought I had which I'd like to discuss is to combine my Mostly Minimal Spanning Trees idea with some thoughts I had about content discovery on mesh networks.

Also talked to @masih recently about some ideas of dynamically changing how routing works which we might want to explore.

[daslicht]

deny list like badbits

Thast just sha hash list of 'bad' files? So if someone extract a a hashed zip and rezip it it is good again ?

[willscott]

We should understand if we want to be doing DHT protocols over such a mixnet, or if it would make more sense to use something like delegated routing, where the the request over the circuit causes the exit to do the full dht lookup, or maybe just act as a relay and transfer the full requested block back.

In the mixnet the intermediate hops will already be acting as relays for network traffic, so it's unclear that this is any more of an amplification, and it would be more efficient.

[RangerMauve]

Thast just sha hash list of 'bad' files? So if someone extract a a hashed zip and rezip it it is good again ?

I think the list hashes the CIDs so it's hard to get the original out unless you already know it, but yes if you change the data by even a byte it will result in a new hash. (Might be useful to move this into a separate thread if there's more Q's about it)

[RangerMauve]

or if it would make more sense to use something like delegated routing

Yeah delegated routing would be a good approach. I personally worry about it being a point of centralization and failure. If there was a lot of nodes that could be discovered for doing the delegated routing it'd be less worrying, but at the same time you'd need some sort of discovery mechanism in order to find them. 😅

[RangerMauve]

Also I'm not certain that delegated routing would be able to connect two mixnet peers to each other.

[RangerMauve]

Also, privacy is something that's getting some attention from the IPFS core right now so there's funding for folks that have useful ideas: https://research.protocol.ai/blog/2022/new-open-problems-in-private-data-retrieval/

[pomid]

You guys should consider i2p
Its like like tor but decentralized and packet switched in contrast with tor centralized and circuit switched approach

[marek22k]

I2P, in contrast to Tor, also supports UDP and has an API.

[agowa]

@marek22k Tor also has an API, but you're right that I2P is probably still the better choice in this context.
But admittedly the native library for interacting with tor is still "very early" (onion service support is planed to hit until the end of the year): https://tpo.pages.torproject.net/core/arti/