4 ms·

Thanks for taking the time to write this primer! Does the protocol have any kinds of countermeasures for bad actors? As an attacker, it looks like I could easi

by jude- 5y ago

Thanks for taking the time to write this primer! Does the protocol have any kinds of countermeasures for bad actors? As an attacker, it looks like I could easily insert malicious nodes into the spanning tree in-between any pair of honest nodes with relative ease. From there, I could do things like: * Selectively drop (censor) messages * Gather message arrival-time and size data in a bid to deanonymize users * Partition the network, denying service * Eclipse a set of victim nodes, thereby allowing me to decide who they talk to If your threat model includes node operators who can do this, one way you could at least make it harder for them to pull it off is to focus on reachability. You could make it so nodes discover the full set (or near enough the full set) through a random k-regular flood network, and have them rebuild a random spanning tree in regular intervals to "shake off" attackers. In addition, you'd want to find a way to make node ID generation both slow and expensive, so the attacker can't overwhelm the flood network with garbage state. As long as the total number of node IDs is small and grows at a bound rate, peers could feasibly learn the IP addresses of all other peers, and stave off partitions and deliberate route breakage.

neilalexander 5y ago
At the moment we don’t have much in the implementation that actively avoids these kinds of attacks. If protocol messages are dropped then this will interrupt the bootstrap and path setup processes, which also is a kind of damage limitation. If a bad actor selectively dropped traffic but kept passing protocol messages then that’s much more of an issue. In that case the logical thing to do is to try and route via another peer that may take another (albeit slightly less direct) path. Partitioning the network is also quite difficult because all it would take is a single set of good paths through the network for the spanning tree to converge on the real strongest key. Key generation is an interesting point though - right now generating ed25519 keys is cheap and it may be possible to flood the network with lots of nodes, but it still doesn’t really constitute a complete attack, as other genuine nodes may still end up making routing decisions that repair the path. We will need to study it more and simulate it. We do have an entire list of scenarios to work through but some of these will hopefully be solved at the Pinecone layer and others will be solved at the Matrix layer (i.e. right now full-mesh federation, like what Matrix has today, is wholly impractical for P2P so we will need to do better). This is by no means a finished product - it’s effectively a research project at this stage and we still have a lot to do to reach the P2P Matrix goal.

by jude- 5y ago

neilalexander 5y ago

At the moment we don’t have much in the implementation that actively avoids these kinds of attacks. If protocol messages are dropped then this will interrupt the bootstrap and path setup processes, which also is a kind of damage limitation. If a bad actor selectively dropped traffic but kept passing protocol messages then that’s much more of an issue. In that case the logical thing to do is to try and route via another peer that may take another (albeit slightly less direct) path. Partitioning the network is also quite difficult because all it would take is a single set of good paths through the network for the spanning tree to converge on the real strongest key. Key generation is an interesting point though - right now generating ed25519 keys is cheap and it may be possible to flood the network with lots of nodes, but it still doesn’t really constitute a complete attack, as other genuine nodes may still end up making routing decisions that repair the path. We will need to study it more and simulate it. We do have an entire list of scenarios to work through but some of these will hopefully be solved at the Pinecone layer and others will be solved at the Matrix layer (i.e. right now full-mesh federation, like what Matrix has today, is wholly impractical for P2P so we will need to do better). This is by no means a finished product - it’s effectively a research project at this stage and we still have a lot to do to reach the P2P Matrix goal.