acid-info
/
vac.dev
mirror of https://github.com/acid-info/vac.dev.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

edit(relay anonymity)

This commit is contained in:
ksr 2022-07-22 15:35:03 +02:00
parent 3c6e0d49bd
commit 39f0c52a60
1 changed files with 9 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
research/2022-07-15-relay-anonymity.md → research/2022-07-22-relay-anonymity.md
View File

@ -1,20 +1,18 @@
---
layout: post
name: "Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay"
title: "Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay"
date: 2022-07-22 10:00:00
author: Daniel
author: kaiserd
published: true
permalink: /wakuv2-relay-anon
categories: research
summary: Introducing a basic threat model and privacy/anonymity analysis for the Waku v2 relay protocol.
image: ../static-assets/img/anonymity_trilemma.svg
image: /img/anonymity_trilemma.svg
discuss: https://forum.vac.dev/t/discussion-waku-privacy-and-anonymity-analysis/149
_includes: [math]
---
<!-- intro -->
[Waku v2](https://rfc.vac.dev/spec/10/) enables secure, privacy preserving communication using a set of modular P2P protocols.
Waku v2 also aims at protecting the user's anonymity.
This post is the first in a series about Waku v2 security, privacy, and anonymity.
@ -29,7 +27,7 @@ Waku comprises many protocols that can be combined in a modular way.
For our privacy and anonymity analysis, we start with the relay protocol because it is at the core of Waku v2 enabling Waku's publish subscribe approach to P2P messaging.
In its current form, Waku relay is a minor extension of [libp2p GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md).
![Figure 1: The Waku v2 relay mesh is based on the [GossipSub mesh](https://docs.libp2p.io/concepts/publish-subscribe#types-of-peering)](../static-assets/img/libp2p_gossipsub_types_of_peering.png)
![Figure 1: The Waku v2 relay mesh is based on the [GossipSub mesh](https://docs.libp2p.io/concepts/publish-subscribe#types-of-peering)](/img/libp2p_gossipsub_types_of_peering.png)
## Informal Definitions: Security, Privacy, and Anonymity
@ -56,7 +54,7 @@ Privacy allows users to choose which data and information
* and with whom they want to share it.
This includes data and information that is associated with and/or generated by users.
Protected data also comprises metadata that might be generated without users being aware of.
Protected data also comprises metadata that might be generated without users being aware of it.
This means, no further information about the sender or the message is leaked.
Metadata that is protected as part of the privacy-preserving property does not cover protecting the identities of sender and receiver.
Identities are protected by the [anonymity property](#anonymity).
@ -132,7 +130,7 @@ We will cover this in more detail in later sections.
Waku's goal, being a modular set of protocols, is to offer any combination of two out of these three properties, as well as blends.
An example for blending is an adjustable number of pubsub topics and peers in the respective pubsub topic mesh; this allows tuning the trade-off between anonymity and bandwidth.
![Figure 2: Anonymity Trilemma: pick two. ](../static-assets/img/anonymity_trilemma.svg){width=250px}
![Figure 2: Anonymity Trilemma: pick two. ](/img/anonymity_trilemma.svg)
A forth factor that influences [the anonymity trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html) is *frequency and patterns* of messages.
The more messages there are, and the more randomly distributed they are, the better the anonymity protection offered by a given anonymous communication protocol.
@ -161,7 +159,7 @@ Each attacker type comes in a passive and an active variant.
While a passive attacker can stay hidden and is not suspicious,
the respective active attacker has more (or at least the same) deanonymization power.
We also distinguish between internal an external attackers.
We also distinguish between internal and external attackers.
### Internal
@ -277,8 +275,8 @@ This, however, might lead to $v$ switching to other peers.
This attack cannot (reliably) distinguish messages $m_v$ sent by $v$ from messages $m_y$ relayed by peers of $v$ the attacker is not connected to.
Still, there are hop-count variations that might be leveraged.
Messages $m_v$ always have a hop-count of 1 from $v$ to the attacker, while all other paths are longer.
Messages $m_y$ might have the same hop-count on the path from $v$ as well as from other paths.
Messages $m_v$ always have a hop-count of 1 on the path from $v$ to the attacker, while all other paths are longer.
Messages $m_y$ might have the same hop-count on the path from $v$ as well as on other paths.
### Controlled Neighbourhood