Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate possible abuse of expiry & ttl field in envelope #105

Closed
kdeme opened this issue Oct 21, 2019 · 2 comments
Closed

Investigate possible abuse of expiry & ttl field in envelope #105

kdeme opened this issue Oct 21, 2019 · 2 comments
Labels
Waku Issues related to Waku Swarm Whisper wontfix This will not be worked on

Comments

@kdeme
Copy link
Contributor

kdeme commented Oct 21, 2019

Here it is informally explained that in Whisper the origin of a message could be found out by a powerful adversary.
Perhaps the next issue is obvious and known and not the goal Whisper, but I assumed differently so I'll post it here anyhow. Also, I've not actually tested it.

A Whisper envelope contains the expiry and ttl fields. Typically in implementations: expiry - ttl = creation timestamp.

Now I question if a peer can not simply abuse this timestamp to figure out the origin of the envelope.
A peer his direct connections, could have a fairly stable round-trip time (RTT). Just looking at the timestamp could perhaps identify the peer as a sender or not. Especially over multiple messages.

This is however somewhat more complicated:

  • First there is the PoW calculation which will delay the queuing of the message. This delay will also have some randomness. However, the delay will probably not be enough compared to a usual RTT/2. Especially if the selected PoW is low (e.g. very low setting of PoW in Status).
  • Secondly, messages are send in batch and not immediate. This is not a requirement of EIP-627 but it is generally assumed and done in geth and nim-eth. Depending on the send interval (300ms currently), this will make it more difficult to figure out the origin of the message (1 - 300 ms can be added as delay).

In the worst case (e.g. messages with less delay added than RTT/2), it is likely that some messages will be able to be linked to a peer you are connected with.
Combine this e.g. with a node monitoring the messages of some most used public channels on Status and you could perhaps link IP-address to the messages & Status names of a user that this node is connected with.
Of course these are public channels but still I believe pseudoanonimity should be a goal even on those channels.

Possible ideas of improving this:

  • add more time randomness by decreasing expiry with random amount.
  • add more time randomness to the batch envelope send.

TBI

@staheri14
Copy link

The provided link is not reachable https://github.com/ethereum/go-ethereum/wiki/Achieving-Darkness, could not find it in the Geth documentation either

@kdeme kdeme added the wontfix This will not be worked on label Nov 16, 2022
@kdeme
Copy link
Contributor Author

kdeme commented Nov 16, 2022

Whisper/Waku code was moved out of nim-eth

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Waku Issues related to Waku Swarm Whisper wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants