Rethink routing strategy

The routing strategy used as of this writing involves forwarding ConnectionPackets through intermediate peers as necessary based on key distance. Compared to Tor, it has the advantage that intermediate nodes cannot tell whether the node they receive a packet from is the original sender or not.

But as per Drew's feedback, we also picked up a significant disadvantage relative to Tor: each intermediate node knows the final recipient, which Tor avoids.

Investigate other options. Can we have both benefits? Maybe there is a darknet or mixnet reliable enough to use as a transport? Or maybe we could use Tor as a transport after all?

Assigned to
2 months ago
24 days ago
No labels applied.

~yujiri 2 months ago

As per our discussion in Matrix, a new sub-issue: maybe the NetworkPacket layer needs a time-to-live, a max number of hops, because it's possible for a packet to be sent in a circle: even though wrapped subtraction prevents you from overshooting the final recipient, it might be for example that peer 10 is the final recipient, peer 9 cannot reach peer 10, but peer 8 can - and the "closest peer" algorithm would lead peer 9 to transmit to peer 8.

~yujiri a month ago*

Thoughts I had:

I wonder if federation could be an optional mode? It would use prekeys and double ratchet a la Signal, so it could have true offline delivery while still having forward secrecy, and also have multi-device support in a way that wouldn't be visible to your conversation partners (unlike Matrix). A user would have both a long-term public key serving as an ID and optionally a homeserver, but it would be possible to receive messages in P2P mode even if you have a homeserver, which would eliminate my concern about homeservers being a single point of failure for their users.

I realize that this is a large increase in the total complexity of the protocol. And that if Sufec is going to use double ratchet for sending a message to a homeserver, it might as well also use it for direct (P2P) mode. I had hoped to avoid double ratchet since I found it was difficult to understand and unnecessary for P2P, but there's no gain in not using it for one mode if the software is going to contain that complexity anyway.

If this is true, the next step is probably to implement double ratchet.

There is one issue raised by double ratchet. Deleting all memory of a DM client-side should not interfere with the other party's ability to send another message, and with double ratchet, it does, because the recipient wouldn't have the chain keys/etc anymore. And worse, in federated mode, that would mean you could send a message the recipient can't read and you wouldn't know because it's asynchronous. The server tells you it was accepted while the recipient is offline.

I believe in Signal, the answer to this is that leaving a DM notifies the other party. I don't want that. I want to be able to delete local memory of a chat without involving the other party.

~yujiri a month ago

Chloe has suggested that just storing enough ephemeral keys on your homeserver might be a good enough substitute for the double ratchet. Storing 1000 keys would allow you to receive 1000 messages while offline, right? That seems good enough. And it would only take 32kb!

~yujiri a month ago*

Some more thoughts I am having about federation:

#Multi-device support

My first, naive, idea of this was to simply have all your devices share your private key, your homeserver can't tell the difference between the devices (privacy++, right?), and so it would just store received messages for something like a week to give you time to download it to all devices.

Security--: this means storing messages after all devices have received them, allowing them to be compromised by a key compromise up to a week in the future. I'm not about to accept that after how big a deal I've made out of forward secrecy in planning this protocol.

Another apparent security-- is that if all devices simply share the private key, you can't use one device to revoke another's access if it's lost. My decision to have them all share the private key came after reading about some other solutions for multi-device support (too complex for me to fully understand) that involved each device havings its own long-term key pair and the sender separately encrypting a message to each of your devices, and I thought, "that's a privacy--, I don't want everyone who sends me messages to know how many devices I have and when I add a new one etc".

But on closer reflection I don't think this is a security-- because if one device can revoke another's access, and you lose a device, then that device could also be used to revoke your remaining device first.

So, to address the first security--: I have decided that the client, when fetching messages from homeserver, must include some sort of device ID (not a key pair or signature, just an ID), and the homeserver should know which device IDs are on your account, so that the homeserver can know when all devices have received a message and stop storing the messages immediately thereafter.

The devices will still share the long-term key pair.

Actually, maybe the device ID should be a separate key pair, to prevent devices from pretending to be each other?

~yujiri a month ago

I have gone off topic here using this issue to discuss everything related to federation. We should refocus this issue on the idea of changing our P2P routing strategy. I will copy the above comment over to #4.

~yujiri referenced this from #4 a month ago

~yujiri referenced this from #5 a month ago

~yujiri a month ago*

It seems we were mistaken about Tor allowing the guard node to know it's the guard node ( https://en.wikipedia.org/wiki/Onion_routing ):

To preserve the anonymity of the sender, no node in the circuit is able to tell whether the node before it is the originator or another intermediary like itself.

In that case, I am increasingly against the idea of implementing our own p2p routing system. If p2p is truly necessary (and, as per #7, I'm increasingly unconvinced that it is), there must be a way to do it over Tor or other anynomous p2p transport solutions.

~yujiri REPORTED INVALID 24 days ago

Closing since the protocol is no longer P2P.

Register here or Log in to comment, or comment via email.