Add I2P backend support

[suhr]

So you could make tox both secure and anonymous.

[ameenross]

I2P is far from anonymous

[suhr]

I2P is far from anonymous

Why do you think so?

[ameenross]

Sorry, must have mixed it up with freenet. In any case I2P was designed for P2P so it definitely has merit. But there would not be a connection to "clearnet" tox.

[suhr]

But there would not be a connection to "clearnet" tox.

Yes, but there will be a tox network inside I2P. It might be useful.

[ameenross]

Yes certainly

[iShift]

You can use that lib - https://github.com/orignal/i2pd/ i2p on C++

[fcore117]

Let I2P be I2P and Tox should work in own ways. I2P itself should make some general network driver interface where it is possible to connect.

[suhr]

I2P itself should make some general network driver interface where it is possible to connect.

I doubt if it's possible due to I2P have much longer addresses than even IPv6 (and linux/windows networking is not like Plan 9 one).

[iShift]

I2P itself should make some general network driver interface where it is possible to connect.

I2P work on high OSI level, is is not possible to make driver

[Natanael90]

There's Garlicat which provides a wrapper, it emulates a network card where I2P addresses are mapped to IP addresses.

[stqism]

While I2P had its anonymonity broken open, Tox has worked through I2P for a year.

[Natanael90]

Since when did I2P get broken open? Are you talking about the Tails & I2P XSS flaw?

[aaannndddyyy]

i2pd is far from stable, so using sam would be the way to do it.
tox dht would have to store key hashes instead of ip:port.
Then the client connects to localhost and instructs sam to open up a tunnel to the bootstrap nodes first, and later to any key hash it wants to connect to.

[suhr]

@GrayHatter Reopen please, this is still an issue.

[TheNain38]

@GrayHatter Yes, reopen please it didn't get solved

[ProMcTagonist]

Would be very cool to have Tox over I2P.

[JacobHenner]

I'd be interested in investigating this some more.

[aaannndddyyy]

@JacobHenner Do not bundle i2p, just require it as a dependency. The dht would need tweaking (dests instead of ip:port).
use one of these api's:
https://geti2p.net/en/docs/api/samv3
https://geti2p.net/en/docs/api/bob

I2P is a closed network, like tor hidden services, but you could allow nodes to act as bridges just like tcp node now. Would then need a bridge flag so you can find those in the DHT

Tunnels should be ephemeral.
To fully make use of it, use different tunnels (that means different addresses) for DHT communication, 1:1 messenger and groupchat.

[JacobHenner]

So would it make more sense to modify toxcore, or implement this in a specific client? Also, if the user is connecting over I2P, will they also be connecting regularly, or is it expected that they will only use one or the other at a time?

[aaannndddyyy]

I don't think you could implement a new way of transport in a client. So it'd need to be in core.
But changes should remain minimal and as generic as possible, so to allow easy adaption for tor and not to bloat core.
As I said, the hidden services (i2p and tor) are conceived as separate networks.

So if a regular user (non hidden services) were to find his friend on an address such as jf2g5hus6gp2jfgk7zgc2cxtzeedxbstr3ju374amtoaq6p2ax6a.b32.i2p he would not know how to connect to it.

So basically, two networks. those with i2p otion enabled, send this address to the router and it connects them to their peer.

But for interconnectivity of regular users and hidden service users I suggested the "bridges"

[aaannndddyyy]

Right now, users who cannot connect via udp find a tcp relay which relays their traffic.
In a similar way, a non-i2p user could find a relay node that is connected to both i2p and regular tox network and thus allow inter-network communication.
But this would be the icing on the cake, in order to prevent fragmentation.
For basic functionality this is not needed, only for inter-network connectivity.

[GrayHatter]

any reason you couldn't just plug tox into an I2P proxy like this https://geti2p.net/en/about/browser-config ?

[JacobHenner]

@GrayHatter I2P doesn't do "exits" like Tor does. It supports "outproxies" for HTTP sites, but only when the operators are able to do so (and unlike Tor, these proxies typically block non-get requests).

You can essentially think of I2P as only implementing Tor's "hidden services" (with some major implementation differences).

[GrayHatter]

@JacobHenner right, so if I used an I2P to bootstrap to a node, also on/in I2P. Wouldn't then I be able to connect to any other client who was also proxied'd and boot strapped to that node?

[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!