14/WAKU2-MESSAGE: Investigate the use of a message format with better features regarding unlinkability

[kdeme]

Problem

There might be ways to link a message to a specific application, or worse user, because of the way the message is formed.

One specific case is for example, always having a specific size. Others might/will apply, tbi.

Waku v1 envelope data format e.g. always adds padding so that the messages become a mutiple of 256 bytes.

Acceptance criteria

• Review existing solutions, suggest what is applicable.

Details

This should be further investigated, started by looking at the current (best) practises in privacy focused transports (e.g. mixnets)

Possible Solutions

• ...

Notes

Sphinx format used by Nym and Lightning Network: https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf

[oskarth]

While I agree we should do this, I think keeping it simple for now is the way to go. Once we have basic track(s) in place, it makes sense for someone to run off and investigate (and then implement) how/if we can use something like Sphinx. It should be a fairly self contained change I believe.

[kdeme]

Yes, which is why I I only tagged with waku-v2 label for now.

However, I do have a slight concern that some of this might depend on the underlying encryption of the payload.

[oskarth]

Brief update: this is still not a priority, but something for further privacy enhancements once we have gotten Waku v2 shipped, I believe. cc @staheri14 for awareness as it relates to general privacy guarantees and analysis.

Unassigning myself as I'm not likely to personally work on this any time soon, but I'd be happy to look at proposals here

[staheri14]

@oskarth Thanks for pinging me here! Padding + Encryption is a typical and decent approach to overcome such sizing issues and distinguishability problems (it is also already implemented in Waku v1). I will take a look at Sphinx article at a later time (depending on the priority of this issue) and will get back to share ideas.

[jimstir]

issue moved here