Add I2P backend support

[suhr]

So you could make tox both secure and anonymous.

[GrayHatter]

@JacobHenner I don't know enough about the differences between I2P and IPv* so say either way. But if you want true I2P support, you'd have to. Rather; I don't know of a better way.

[GrayHatter]

So, I've just read a little more about how I2P works, and unless you're planning to implement a I2P tunnel in toxcore. Using a proxy is still the only reasonable solution.

Unless I'm mistaken. Even with I2P address support, you'd still have to send all the I2P traffic to the tunnel on your localhost/domain, so adding I2P address support without implementing a tunnel in toxcore wouldn't serve much purpose.

[JacobHenner]

@GrayHatter The idea is to optionally link toxcore to I2P using libsam3 (see https://github.com/JacobHenner/libsam3/). It'd use SAM to communicate with the I2P daemon, and create tunnels to other I2P peers.

[GrayHatter]

@JacobHenner My bad, I seem to have missed some of this conversation. Yeah, I see nothing wrong with adding another type to the DHT with a few caveats. 387 bytes is huge compared to the current size of the DHT now, so that's a concern. But how to you expect clients that are compiled without I2P support to interact with clients that do support I2P?

[JacobHenner]

But how to you expect clients that are compiled without I2P support to interact with clients that do support I2P?

I think the current plan was to start with basic I2P-->I2P functionality, and expand it in the future with bridges or something similar.

[GrayHatter]

So that would mean you either have toxcore on I2P, or on IPv4/6, but not both?

[TheNain38]

@JacobHenner And people that have I2P and IPv* could act as bridges?

[str4d]

@GrayHatter as above, if you want to make the DHT entries smaller you can store the B32 instead, but that has tradeoffs.

I2P <--> I2P: this would function essentially exactly as clearnet Tox currently functions, just with the added I2P layer. If implemented on its own with no bridging, this would essentially result in one DHT per transport. In this situation, there is nothing preventing a user from using I2P <--> I2P and IPv* <--> IPv* independently in the same node.

I2P <--> IPv*: My understanding of Tox is that finding peers happens via the DHT, and communicating with them happens via direct connection (correct me if I'm wrong). Then this has two parts:

• Nodes with both I2P and IPv* could bridge the DHT, enabling I2P-only nodes to successfully look up IPv*-only Tox IDs, and vice versa. How this is done should be discussed, because it depends on whether your DHT implementation assumes that a node can always connect to the peers that are storing the DHT entry, or whether you already have recursive lookup support.
  • Vuze (a torrent client that supports simultaneous seeding on I2P and clearnet) participates separately in the two DHTs, so technically you cannot look up clearnet-only torrents, but by the sheer volume of bridging Vuze peers, you can usually find a peer that is dual-seeding. This kind of operation would probably not be as beneficial for Tox, because I assume the goal is to have one single Tox ID space where each Tox ID may be accessible via one or more transports.
• I2P-only nodes will not be able to directly connect to IPv*-only nodes or vice versa, for obvious reasons. This could be handled in two ways:
  • Notify the IPv* user in UI that they should enable I2P support to talk to this Tox ID (the reverse notification for the I2P user would have to be "either drop your anon requirement, or ask that Tox ID to enable I2P support")
  • Add support for connection-proxying nodes, that will route encrypted communication packets between the two networks. This is no different to e.g. using the default false.i2p outproxy for HTTP(S) traffic (where non-I2P requests to the I2P HTTP proxy tunnel get sent to the outproxy). These would be nodes with both I2P and IPv* that additionally enable connection bridging (probably don't want this enabled by default, although doing so would decrease the average load per bridge).

[JacobHenner]

Alright, I'm going to go ahead and start implementing the I2P<-->I2P portion first. If that works out well, I'll explore the potential I2P<-->IPv* bridging.

[GrayHatter]

@JacobHenner My strong suggestions is to add plenty of inline comments, and to try to keep everything in the strict I2P <--> I2P and worry about bridging/relaying later. Also, don't use B32 for the DHT. A collision is worse than slow DHT.

[JacobHenner]

@GrayHatter To store the entire destination address, the DHT would have to support variable-length data, as @str4d explained. Would that be permissible (possible?) in the DHT, or would it make more sense to just go ahead and use the b32s?

[GrayHatter]

@JacobHenner the DHT already supports VLPackets. You're going to be editing the Packed Node format. That's used by a few places in toxcore. But specifically in the DHT, it already has two sizes one for IPv6 and a smaller size for v4.

[JacobHenner]

@GrayHatter Right, but both of those (v4 and v6) have statically defined sizes, whereas the I2P full destination address is variable, because of potential certificate chaining.

[GrayHatter]

@JacobHenner @str4d would there be a possibility of padding the size to make it constant?

[str4d]

@GrayHatter Technically no. The size of a Destination is variable because it may happen to contain one or more Certificates. In practice, we only use one kind of Certificate - the KeyCertificate, which enables other crypto and signing types to be specified. It is this variable crypto and signing that will really be the potential sticking point in future for length.

One way you could make the Destination size a constant is to specify the kind of Destinations that Tox will support - that is, you specify what crypto Tox will allow, and what cert types. Then you would know how long the longest possible Destination would be, and use that for your DHT packet size. It would mean that if in future it became necessary to use a crypto or signing type that required longer key material, you would need to define a new longer packet type.

WRT padding for storing in the DHT, you could pad the Destination object with as many trailing zeroes or random data as you wanted. The Destination object contains the information necessary to determine its own length, so you could easily parse the packet to strip off the padding (or just use a padding form that encodes its own length).

[str4d]

At the moment, a good recommended length is probably 616 bytes for the B64-encoded string (516 for base DSA length + 100 for any certs and extra key material), which would enable you to use the DSA, ECDSA and EdDSA signing types but not RSA. We don't yet know what crypto types we will implement, and how much space they may take up, but we also don't currently use the crypto key in the Destination, so it may not be necessary to extend it any time soon. Then again, if in future we did start using that crypto key again for something, and your DHT packet was too small, you would need to stay with the older crypto type until a new packet was defined. My feeling is though that we will probably implement an EC-based crypto type, which should have a short enough key to fit in the space currently taken up by the ElGamal key.

[aaannndddyyy]

What are the odds for a collision with b32? Collisions are bad, but if they are extremely unlikely... 

[str4d]

The B32 is the full SHA-256 hash of the binary Destination, represented as a 52-character base 32 string (giving a total B32 length of 60 characters). Thus the vulnerability of B32s depends on the collision resistance of SHA-256. However, as the B32s are used to look up Destinations in the netDb, a random collision is not sufficient - the collision must be caused by a valid Destination.

[GrayHatter]

@str4d I don't think any risk of collision is acceptable, at least when it comes to Toxcore. But out of curiosity, say sha256 was was broken. How resistant is netDB to poisoning attacks?

[aaannndddyyy]

@Grayhatter, @str4d , I think it would be possible not to use netdb at all. I have never tried this, but if you have access to your leasesets, you can bundle them in the onion such that the other contatc when it gets the onion, immediatelly knows the gateways it can connect to. But, of course, this would be much bigger then than only a full dest.

[str4d]

@GrayHatter If SHA-256 was broken so badly that a valid Destination could be crafted with a hash matching a target, then the netDb would not be very reliable any more, because the DHT routing key is the SHA-256 hash of the Destination. It would allow a persistent attacker to take over a B32 by pushing their own LeaseSets, which would easily affect new clients looking up the B32. It would not be 100% effective though, because LeaseSets must be re-published every 10 minutes, and the newest one wins. (That in fact is how multihoming works in I2P - two routers run the same Destination, and whichever one happens to have published a LeaseSet to a particular floodfill most recently will be chosen by clients querying that floodfill.)

However, I am not sure right now how existing clients would be affected by a SHA-256 break, ie. those that already had the valid Destination, and then re-looked up a LeaseSet for that Destination and received one with a different Destination. I imagine that should throw up all sorts of red flags, but I'd need to go check the source code.

Bottom line is, if your packet can only hold a B32, you directly take on the risk of a full SHA-256 break. If you store the full Destination, you pass that risk back to I2P; it is still there, but you then benefit if and when we alter the netDb under the covers to mitigate the risk in future.

I will say that I2P is certainly better than Tor in this respect, at least at present, because they use a truncated SHA-1 hash for their .onion addresses. HS 2.0 actually proposes moving to a 52-character identifier like I2P, although they are planning some crypto blinding magics in there too (some of which I am investigating for potential use in I2P).

@aaannndddyyy I assume by "onion" you mean the Tox DHT packet? I guess if you wanted to, you could essentially publish the LeaseSets in the Tox DHT, but I'm not sure the extra effort to get around using the netDb would be worth any gains.

[aaannndddyyy]

@str4d It would avoid the sha issue altogether. Also the onion routing of the onion packet prevents the dht or netdb from learning who communicates with whom.

Using two DHT's for connecting to a peer when one would suffice sounds a bit suboptimal. They main issue with doing it netdb-less would, imho, be the leaseset sizenull

[str4d]

@aaannndddyyy Ah, I understand what you mean now.

The netDb is only used for initial contact, ie. determining the current LeaseSet of the remote peer when your node wants to connect, if you don't have a currently-valid one locally. Once a connection is established, the I2P routers will bundle subsequent new LeaseSets in their communications alongside their data as GarlicCloves.

I2P already does LeaseSet lookups in the netDb through a node's client tunnels, specifically for the reason you state.

[aaannndddyyy]

What I'm saying is that tox already does a lppkup in a dht. Sp maybe we wang to avoid doing a second lookup in a second dht. Also tox dht has provisions to make it harder for participants of the dht to see which ip wants to cpnnect to which ip, or here which anon identity with which other anon identity. This second aspect is less important in case you use ephemeral destinations, which I'd recommend anyway.

[fcore117]

question, if developers plan to integrate this into official Tox then is i2p disabled by default and even then do not use not one bit of extra network resources. I ask because of two reasons, one is that Tox goal is mostly for casual people in world and second Tox currently already has quite large network usage/activity.

If this i2p addon will be planned as fork then no worry.

[aaannndddyyy]

This will not add i2p to toxcore but only support for i2p trasport, using an external i2p router which the user would a) have to install and b) configurw tox to use it, in order to use tox over i2p. That means that unless you yourself explicitly configure tox to use i2p AND you install i2p, there will npt a single additipnal bit be used by your tox. Except fpr the data stpred in the dht, which, due to longer addresses, wpuld slightly increase. That is similar tp the increase ypu get for allowing IPv6 addresses instead of only IPv4.

I hope that answers your question.

[aaannndddyyy]

Ideally, it would not remain a fork, because the goal is global connectivity, whether you are on plain IP, tor or i2p. Right now, toxcore allows proxying through tor already and it does not increase traffic for those who do not use tor, and it is not a fork that tor users would have to use. Think of i2p as an analogous case.

[aaannndddyyy]

@JacobHenner Any news?

[fcore117]

if i am not mistaken they want to complete critical everyday features for casual people who need Skype replacement and later these extra features come to table for thinking. Developers correct if i am wrong.

[GrayHatter]

@str4d @JacobHenner any updates on this?

[str4d]

Just FYI, I2P has launched a development program aimed at helping developers integrate I2P into their apps. If you'd like some help getting this moving, let me know!

[GrayHatter]

I'll echo @str4d I've become a LOT more familiar with tox DHT so while I don't have the time to take on this project my self. I'm happy to spend as much time as I can getting someone else up to speed on this.

@JacobHenner you still alive mate?

[JacobHenner]

@GrayHatter Still alive, but I do not have the resources to dedicate to this effort. Sorry!