research log: waku-relay anonymity analysis

[kaiserd]

The research log post tracked in this issue will be the first post in a series on Waku v2 security / privacy / anonymity.
It will focus on anonymity guarantees of waku-relay in specific adversarial models.
Focusing on waku-relay, the post will make a set of simplifying assumptions

• message structure is out of scope
• ...

Our forum posts on the anonymity of Waku-relay and towards a Waku v2 security analysis cover information and discussion about the planned research post and a future more comprehensive security analysis, respectively.

cc @staheri14

[kaiserd]

scoping this first post on relay privacy

• informal definitions of Security, Privacy, Anonymity

  • followed by examples illustrating these properties

• attacker models

• thread-based attack analysis

• basic privacy/anonymity analysis of libp2p gossipsub with StrictNoSign

• basic privacy/anonymity analysis of 14/WAKU2-MESSAGE

• the dial/listen layer (which introduces PeerIDs) is out of scope

Rationale

The definitions will naturally be useful for this and future posts in this series.
If necessary, we can expand these definitions in future posts.

Initially we planned to only focus on the thin layer that Waku relay adds on gossipsub and leave gossipsub out of scope.
Imo, from a privacy/anonymity analysis point of view it makes more sense to look at Waku relay as a restricted version of gossipsub (StrictNoSign) instead of a layer on top.
So the analysis would address a subset of gossipsub, which is gossipsub without

• from
• seqno
• signature
• key

Still, imo, the whole operation of gossipsub (without these fields) has to be analysed.

Further, we initially planned to look at the data field as a blackbox.
This makes sense as a first step in the analysis.
However, because 11/WAKU2-RELAY specifies the data field MUST be a WakuMessage,
the analysis should include that, too.

We could still split the basic relay analysis into parts and address the Message in the future.
Message is critical, because it MAY contain a sender timestamp. If used as indented, this leaks information about the sender.
Also, as @s1fr0 pointed out, this allows adversaries to carry information along dissemination paths.

edit: For now, I looked at the message as a blackbox.

cc @staheri14

[kaiserd]

libp2p/devgrants#31 is interesting :)

[kaiserd]

PR addressing this issue: vacp2p/vac.dev#71

Changed the scoping a bit, which I edited into my comment above.
For now, I look at the message as a blackbox.
I added more on attacker models and thread-based attack analysis.