[LXMF] Theoretical Malicious Node

[LinuxinaBit]

What would happen if there was a malicious node that accepted messages and returned that 'they are on the propagation net' then proceeded to not distribute it or give it to the recipient?
Does LXMF check with other propagation nodes to make sure the message has been properly distributed first? If not, is there something I'm missing?

[faragher]

Propagation nodes are meant to be manually trusted. Setting a default node should solve that problem from the point of view of the sender. I don't know enough about the synchronization to do a threat analysis at this time. There is a potential threat of spoofing delivery unless each node requires a cryptographic signature from the recipent before deleting, or something similar. Worth looking into.

…

On Thu, Dec 21, 2023, 8:33 AM Linux in a Bit ***@***.***> wrote: What would happen if there was a malicious node that accepted messages and returned that 'they are on the propagation net' then proceeded to not distribute it or give it to the recipient? Does LXMF check with other propagation nodes to make sure the message has been properly distributed first? If not, is there something I'm missing? — Reply to this email directly, view it on GitHub <#411>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALIZNI43EHOGDIMH4DLK6XDYKRCDJAVCNFSM6AAAAABA6PXNZWVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZVHE4DMMBWHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[LinuxinaBit]

I think there should definitely be a something that automatically tests the dependability of a node for two cases:

1. Automatic node pseudo-trusting so the user doesn’t have to manually trust any
2. Automatic removal of trust if a node is detected doing something suspicious (most users will likely just trust whatever random node pops up first, if they even trust anything in the first place)

Some way of having a message propagated to multiple nodes from the sending device would also probably be a good thing.

[faragher]

These are conceptual and security issues that I'm not really qualified to discuss. Many of the problems facing Reticulum are trust based, but as a trustless decentralized system, they are difficult to address, There's a balance between enabling trust to keep users safe, and reducing the vectors by which trust can be misused. Beyond that there's a balance between user friendliness and the user being responsible for their own safety.

It's a complicated discussion, and something to discuss, but it needs a through analysis before implementation. If it's simple consensus, someone can simply spin up more nodes. Trust creates a single point of failure. Proofs across untrusted networks is difficult. It's one of the reasons Proof of Work exists on blockchain, but no matter how you feel about blockchain, it's obviously a Red Queen's Race that consumes a tremendous amount of power and new hardware, all in service of keeping malicious actors out.

This is obviously, regardless of opinion on cryptocurrencies, utterly unacceptable for a transport network.

There are the ideas I had. I would love to see a better solution, given these issues:

1. There can be no central authority
2. A malicious actor can spin up as many nodes as they want to erroneously declare a message sent
3. Data efficiency is paramount
4. Processing efficiency is important because this needs to scale properly
5. There may be no information available except the destination of the packet

Requiring a user to have a trusted node selected (I have like three in operation, I can recommend two. :D ) solves the user-mode problem, and simply requires the nodes to harden themselves from malicious actors. Since you're likely connecting to an endpoint that has a node, and should ideally be someone you trust, I think that first step is acceptable.

[markqvist]

When sending via propagation nodes, LXMF currently only delivers to one propagation node. If this node accepts the message, and then disappears (maliciously or because of unintended failure), the message will not get delivered to it's final recipient. In practice, this is the only real attack vector for attempting denial of service.

Once the message has been delivered to at least one propagation node, that is reliable in terms of at least attempting to propagate the message, it's almost impossible to block the message delivery, since every node that has the message will help out in getting the message to every other node that needs it. Note that connections between nodes doesn't even have to be reliable or always on for this to succeed, neither do nodes actually need to be powered on all the time (even though this is very much recommended, especially in situations where connectivity between nodes is very unreliable or intermittent).

In my understanding, the best way to make attempts at denial of service irrelevant, would be to allow LXMF clients automatically deliver propagated messages to a couple of different nodes. This would dramatically improve chances of success, even in a network where X% of nodes are malicious, and the required number of deliveries can be easily mathematically modeled to satisfy any desired probability of success.

Then again, another easy solution is to just use a propagation node that you know will not act maliciously, and if you don't have that luxury available from anyone else, the solution is simply to find an old computer, small SBC or similar and run:

lxmd -p