mirror of
https://github.com/vacp2p/vac.dev.git
synced 2026-01-08 22:28:01 -05:00
Update Links (#163)
* Update 2022-07-22-relay-anonymity.mdx * Update 2022-07-22-relay-anonymity.mdx * Update 2019-07-19-p2p-data-sync-for-mobile.mdx * Update 2019-08-02-vac-overview.mdx * Update 2019-10-04-remote-log.mdx * Update 2019-12-03-fixing-whisper-with-waku.mdx * Update 2020-02-14-waku-update.mdx * Update 2020-02-7-dns-based-discovery.mdx * Update 2020-02-7-dns-based-discovery.mdx * Update 2020-07-01-waku-v2-pitch.mdx * Update 2020-09-28-waku-v2-update.mdx * Update 2020-11-10-waku-v2-ethereum-messaging.mdx * Update 2021-03-03-rln-relay.mdx * Update 2021-06-04-presenting-js-waku.mdx * Update 2021-08-06-coscup-waku-ethereum.mdx * Update 2021-10-25-waku-v1-vs-waku-v2.mdx * Update 2022-04-12-introducing-nwaku.mdx * Update 2022-05-09-ambient-peer-discovery.mdx * Update 2022-05-17-noise.mdx * Update 2022-11-04-building-privacy-protecting-infrastructure.mdx * Update 2022-11-08-waku-for-all-decentralize-applications.mdx * Update 2023-04-03-waku-as-a-network.mdx * Update 2023-04-03-waku-as-a-network.mdx * Update 2023-04-24-device-pairing-in-js-waku-and-go-waku.mdx * Update 2023-11-07-rln-relay.mdx * Update 2024-05-03-rln-light-verifiers.mdx * Update 2024-05-13-rln-v3.mdx
This commit is contained in:
Jimmy Debe
@@ -63,7 +63,7 @@ For requirements or design goals for a solution, here's what we came up with.
|
||||
|
||||
## MVDS - a minimium viable version
|
||||
|
||||
The first minimum viable version is in an alpha stage, and it has a [specification](https://rfc.vac.dev/spec/2), [implementation](https://github.com/vacp2p/mvds) and we have deployed it in a [console client](https://github.com/status-im/status-console-client) for end to end functionality. It's heavily inspired by [Bramble Sync Protocol](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md).
|
||||
The first minimum viable version is in an alpha stage, and it has a [specification](https://rfc.vac.dev/vac/2/mvds/), [implementation](https://github.com/vacp2p/mvds) and we have deployed it in a [console client](https://github.com/status-im/status-console-client) for end to end functionality. It's heavily inspired by [Bramble Sync Protocol](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md).
|
||||
|
||||
The spec is fairly minimal. You have nodes that exchange records over some secure transport. These records are of different types, such as `OFFER`, `MESSAGE`, `REQUEST`, and `ACK`. A peer keep tracks of the state of message for each node it is interacting with. There's also logic for message retransmission with exponential delay. The positive ACK and retransmission model is quite similar to how TCP is designed.
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@ In terms of specific properties and trade-offs at each layer, we'll go deeper do
|
||||
|
||||
With all the pieces involved, this is quite an undertaking. Luckily, a lot of pieces are already in place and can be either incorporated as-is or iterated on. In terms of medium and long term, here's a rough sketch of priorities and open problems.
|
||||
|
||||
1. **Better data sync.** While the current [MVDS](https://rfc.vac.dev/spec/2/) works, it is lacking in a few areas:
|
||||
1. **Better data sync.** While the current [MVDS](https://rfc.vac.dev/vac/2/mvds/) works, it is lacking in a few areas:
|
||||
|
||||
- Lack of remote log for mostly-offline offline devices
|
||||
- Better scalability for multi-user chat contexts
|
||||
|
||||
@@ -94,7 +94,7 @@ Both patterns can be used in parallel, e,g. by storing the last `k` messages dir
|
||||
|
||||
### Interaction with MVDS
|
||||
|
||||
[vac.mvds.Message](https://rfc.vac.dev/spec/2/#payloads) payloads are the only payloads that MUST be uploaded. Other messages types MAY be uploaded, depending on the implementation.
|
||||
[vac.mvds.Message](https://rfc.vac.dev/vac/2/mvds/#payloads) payloads are the only payloads that MUST be uploaded. Other messages types MAY be uploaded, depending on the implementation.
|
||||
|
||||
## Future work
|
||||
|
||||
|
||||
@@ -290,8 +290,8 @@ iterative work with results on the order of weeks.
|
||||
|
||||
### Progress so far
|
||||
|
||||
In short, we have a [Waku version 0 spec up](https://rfc.vac.dev/spec/5) as well as a [PoC](https://github.com/status-im/nim-eth/pull/120) for backwards compatibility. In the coming weeks, we are going to solidify the specs, get a more fully featured PoC for [Waku mode](https://github.com/status-im/nim-eth/pull/114). See [rough roadmap](https://github.com/vacp2p/pm/issues/5), project board [link deprecated] and progress thread on the [Vac forum](https://forum.vac.dev/t/waku-project-and-progress/24).
|
||||
In short, we have a [Waku version 0 spec up](https://rfc.vac.dev/waku/deprecated/5/waku0) as well as a [PoC](https://github.com/status-im/nim-eth/pull/120) for backwards compatibility. In the coming weeks, we are going to solidify the specs, get a more fully featured PoC for [Waku mode](https://github.com/status-im/nim-eth/pull/114). See [rough roadmap](https://github.com/vacp2p/pm/issues/5), project board [link deprecated] and progress thread on the [Vac forum](https://forum.vac.dev/t/waku-project-and-progress/24).
|
||||
|
||||
The spec has been rewrittten for clarity, with ABNF grammar and less ambiguous language. The spec also incorporates several previously [ad hoc implemented features](https://rfc.vac.dev/spec/6/#additional-capabilities), such as light nodes and mailserver/client support. This has already caught a few incompatibilities between the `geth` (Go), `status/whisper` (Go) and `nim-eth` (Nim) versions, specifically around light node usage and the handshake.
|
||||
The spec has been rewrittten for clarity, with ABNF grammar and less ambiguous language. The spec also incorporates several previously [ad hoc implemented features](https://rfc.vac.dev/waku/standards/legacy/6/waku1/#additional-capabilities), such as light nodes and mailserver/client support. This has already caught a few incompatibilities between the `geth` (Go), `status/whisper` (Go) and `nim-eth` (Nim) versions, specifically around light node usage and the handshake.
|
||||
|
||||
If you are interested in this effort, please check out [our forum](https://forum.vac.dev/) for questions, comments and proposals. We already have some discussion for better [spam protection](https://forum.vac.dev/t/stake-priority-based-queuing/26) (see [previous post](https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks) for a more complex but privacy-preserving proposal), something that is likely going to be addressed in future versions of Waku, along with many other fixes and enhancement.
|
||||
|
||||
@@ -21,7 +21,7 @@ Waku is our fork of Whisper where we address the shortcomings of Whisper in an i
|
||||
|
||||
**Specs:**
|
||||
|
||||
We released [Waku spec v0.3](https://rfc.vac.dev/spec/6) this week! You can see the full changelog [here](https://rfc.vac.dev/spec/6/#changelog).
|
||||
We released [Waku spec v0.3](https://rfc.vac.dev/waku/standards/legacy/6/waku1) this week! You can see the full changelog [here](https://rfc.vac.dev/waku/standards/legacy/6/waku1/#changelog).
|
||||
|
||||
The main change from 0.2 is making the handshake more flexible. This enables us to communicate topic interest immediately without ambiguity. We also did the following:
|
||||
|
||||
@@ -31,9 +31,9 @@ The main change from 0.2 is making the handshake more flexible. This enables us
|
||||
|
||||
We cut the spec up in several components to make Vac as modular as possible. The components right now are:
|
||||
|
||||
- Waku (main spec), currently in [version 0.3.0](https://rfc.vac.dev/spec/6)
|
||||
- Waku envelope data field, currently in [version 0.1.0](https://rfc.vac.dev/spec/7)
|
||||
- Waku mailserver, currently in [version 0.2.0](https://rfc.vac.dev/spec/8)
|
||||
- Waku (main spec), currently in [version 0.3.0](https://rfc.vac.dev/waku/standards/legacy/6/waku1)
|
||||
- Waku envelope data field, currently in [version 0.1.0](https://rfc.vac.dev/waku/standards/legacy/7/data)
|
||||
- Waku mailserver, currently in [version 0.2.0](https://rfc.vac.dev/waku/standards/legacy/8/mail)
|
||||
|
||||
We can probably factor these out further as the main spec is getting quite big, but this is good enough for now.
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ A look at EIP-1459 and the benefits of DNS based discovery.
|
||||
|
||||
Discovery in p2p networks is the process of how nodes find each other and specific resources they are looking for. Popular discovery protocols, such as [Kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) which utilizes a [distributed hash table](https://en.wikipedia.org/wiki/Distributed_hash_table) or DHT, are highly inefficient for resource restricted devices. These methods use short connection windows, and it is quite battery intensive to keep establishing connections. Additionally, we cannot expect a mobile phone for example to synchronize an entire DHT using cellular data.
|
||||
|
||||
Another issue is how we do the initial bootstrapping. In other words, how does a client find its first node to then discover the rest of the network? In most applications, including Status right now, this is done with a [static list of nodes](https://specs.status.im/spec/1#bootstrapping) that a client can connect to.
|
||||
Another issue is how we do the initial bootstrapping. In other words, how does a client find its first node to then discover the rest of the network? In most applications, including Status right now, this is done with a [static list of nodes](https://rfc.vac.dev/status/deprecated/client/#bootstrapping) that a client can connect to.
|
||||
|
||||
In summary, we have a static list that provides us with nodes we can connect to which then allows us to discover the rest of the network using something like Kademlia. But what we need is something that can easily be mutated, guarantees a certain amount of security, and is efficient for resource restricted devices. Ideally our solution would also be robust and scalable.
|
||||
|
||||
@@ -23,7 +23,7 @@ How do we do this?
|
||||
|
||||
[EIP 1459: Node Discovery via DNS](https://eips.ethereum.org/EIPS/eip-1459), which is one of the strategies we are using for discovering waku nodes. [EIP-1459](https://eips.ethereum.org/EIPS/eip-1459) is a DNS-based discovery protocol that stores [merkle trees](https://en.wikipedia.org/wiki/Merkle_tree) in DNS records which contain connection information for nodes.
|
||||
|
||||
_Waku is our fork of Whisper. Oskar recently wrote an [entire post](https://vac.dev/fixing-whisper-with-waku) explaining it. In short, Waku is our method of fixing the shortcomings of Whisper in a more iterative fashion. You can find the specification [here](https://rfc.vac.dev/spec/6/)_
|
||||
_Waku is our fork of Whisper. Oskar recently wrote an [entire post](https://vac.dev/fixing-whisper-with-waku) explaining it. In short, Waku is our method of fixing the shortcomings of Whisper in a more iterative fashion. You can find the specification [here](https://rfc.vac.dev/waku/standards/legacy/6/waku1/)_
|
||||
|
||||
DNS-based methods for bootstrapping p2p networks are quite popular. Even Bitcoin uses it, but it uses a concept called DNS seeds, which are just DNS servers that are configured to return a list of randomly selected nodes from the network upon being queried. This means that although these seeds are hardcoded in the client, the IP addresses of actual nodes do not have to be.
|
||||
|
||||
|
||||
@@ -108,7 +108,7 @@ Very experimental and incomplete libp2p support can be found in the nim-waku rep
|
||||
|
||||
### 2. Simplify the protocol
|
||||
|
||||
Due to Waku's origins in Whisper, devp2p and as a standalone protocol, there are a lot of stuff that has accumulated (<https://rfc.vac.dev/spec/6/>). Not all of it serves it purpose anymore. For example, do we still need RLP here when we have Protobuf messages? What about extremely low PoW when we have peer scoring? What about key management / encryption when have encryption at libp2p and Status protocol level?
|
||||
Due to Waku's origins in Whisper, devp2p and as a standalone protocol, there are a lot of stuff that has accumulated (<https://rfc.vac.dev/waku/standards/legacy/6/waku1/>). Not all of it serves it purpose anymore. For example, do we still need RLP here when we have Protobuf messages? What about extremely low PoW when we have peer scoring? What about key management / encryption when have encryption at libp2p and Status protocol level?
|
||||
|
||||
Not everything has to be done in one go, but being minimalist at this stage will the protocol lean and make us more adaptable.
|
||||
|
||||
|
||||
@@ -34,11 +34,11 @@ Let's talk about the state of specs and our main implementation nim-waku. Then w
|
||||
|
||||
After some back and forth on how to best structure things, we ended up breaking down the specs into a few pieces. While Waku v2 is best thought of as a cohesive whole in terms of its capabilities, it is made up of several protocols. Here's a list of the current specs and their status:
|
||||
|
||||
- [Main spec](https://rfc.vac.dev/spec/10/) (draft)
|
||||
- [Relay protocol spec](https://rfc.vac.dev/spec/11/) (draft)
|
||||
- [Filter protocol spec](https://rfc.vac.dev/spec/12) (raw)
|
||||
- [Store protocol spec](https://rfc.vac.dev/spec/13) (raw)
|
||||
- [Bridge spec](https://rfc.vac.dev/spec/15/) (raw)
|
||||
- [Main spec](https://rfc.vac.dev/waku/standards/core/10/waku2) (draft)
|
||||
- [Relay protocol spec](https://rfc.vac.dev/waku/standards/core/11/relay) (draft)
|
||||
- [Filter protocol spec](https://rfc.vac.dev/waku/standards/core/12/filter) (raw)
|
||||
- [Store protocol spec](https://rfc.vac.dev/waku/standards/core/13/store) (raw)
|
||||
- [Bridge spec](https://rfc.vac.dev/waku/standards/core/15/bridge) (raw)
|
||||
|
||||
Raw means there is not yet an implementation that corresponds fully to the spec, and draft means there is an implementation that corresponds to the spec. In the interest of space, we won't go into too much detail on the specs here except to note a few things:
|
||||
|
||||
|
||||
@@ -98,7 +98,7 @@ The main implementation is written in Nim using nim-libp2p, which is also poweri
|
||||
|
||||
Right now, all protocols, with the exception of bridge, are in draft mode, meaning they have been implemented but are not yet being relied upon in production.
|
||||
|
||||
You can read more about the breakdown in this [update](https://vac.dev/waku-v2-update) though some progress has been made since then, as well was in the [main Waku v2 spec](https://rfc.vac.dev/spec/10).
|
||||
You can read more about the breakdown in this [update](https://vac.dev/waku-v2-update) though some progress has been made since then, as well was in the [main Waku v2 spec](https://rfc.vac.dev/waku/standards/core/10/waku2).
|
||||
|
||||
## 5. Waku v2 - Upcoming
|
||||
|
||||
|
||||
@@ -200,8 +200,8 @@ Thanks to Onur Kılıç for his explanation and pointers and for assisting with
|
||||
|
||||
## References
|
||||
|
||||
[^1]: Waku v2: https://rfc.vac.dev/spec/10/
|
||||
[^2]: RLN-Relay specification: https://rfc.vac.dev/spec/17/
|
||||
[^1]: Waku v2: https://rfc.vac.dev/waku/standards/core/10/waku2
|
||||
[^2]: RLN-Relay specification: https://rfc.vac.dev/waku/standards/core/17/rln-relay
|
||||
[^3]: RLN documentation: [https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?both](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?both)
|
||||
[^4]: RLN repositories: [https://github.com/kilic/RLN](https://github.com/kilic/RLN) and [https://github.com/kilic/rlnapp](https://github.com/kilic/rlnapp)
|
||||
[^5]: RLN Benchmark: [https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Benchmarks](https://hackmd.io/tMTLMYmTR5eynw2lwK9n1w?view#Benchmarks)
|
||||
@@ -216,7 +216,7 @@ Thanks to Onur Kılıç for his explanation and pointers and for assisting with
|
||||
[^14]: Zero Knowledge Proof: [https://dl.acm.org/doi/abs/10.1145/3335741.3335750](https://dl.acm.org/doi/abs/10.1145/3335741.3335750) and [https://en.wikipedia.org/wiki/Zero-knowledge_proof](https://en.wikipedia.org/wiki/Zero-knowledge_proof)
|
||||
[^15]: zkSNARKs: [https://link.springer.com/chapter/10.1007/978-3-662-49896-5_11](https://link.springer.com/chapter/10.1007/978-3-662-49896-5_11) and [https://coinpare.io/whitepaper/zcash.pdf](https://coinpare.io/whitepaper/zcash.pdf)
|
||||
[^16]: GossipSub: [https://docs.libp2p.io/concepts/publish-subscribe/](https://docs.libp2p.io/concepts/publish-subscribe/)
|
||||
[^17]: Waku Relay: https://rfc.vac.dev/spec/11/
|
||||
[^17]: Waku Relay: https://rfc.vac.dev/waku/standards/core/11/relay
|
||||
[^18]: Prior blockers of RLN-Relay: [https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks](https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks)
|
||||
[^19]: The lack of Shamir secret sharing in zkSNARKs: [https://github.com/vacp2p/research/issues/10](https://github.com/vacp2p/research/issues/10)
|
||||
[^20]: The MPC required for zkSNARKs trusted setup: [https://github.com/vacp2p/research/issues/9](https://github.com/vacp2p/research/issues/9)
|
||||
|
||||
@@ -78,7 +78,7 @@ It is available right now on [npm](https://www.npmjs.com/package/js-waku):
|
||||
As it is written in TypeScript, types are included in the npm package to allow easy integration with TypeScript, ClojureScript and other typed languages that compile to JavaScript.
|
||||
|
||||
Key Waku v2 protocols are already available:
|
||||
[message](https://rfc.vac.dev/spec/14/), [store](https://rfc.vac.dev/spec/13/), [relay](https://rfc.vac.dev/spec/11/) and [light push](https://rfc.vac.dev/spec/19/),
|
||||
[message](https://rfc.vac.dev/waku/standards/core/14/message), [store](https://rfc.vac.dev/waku/standards/core/13/store), [relay](https://rfc.vac.dev/waku/standards/core/11/relay) and [light push](https://rfc.vac.dev/waku/standards/core/19/lightpush),
|
||||
enabling your dApp to:
|
||||
|
||||
- Send and receive near-instant messages on the Waku network (relay),
|
||||
@@ -138,7 +138,7 @@ We have also put a bounty at [0xHack](https://0xhack.dev/) for using JS-Waku
|
||||
and running a [workshop](https://www.youtube.com/watch?v=l77j0VX75QE).
|
||||
We were thrilled to have a couple of hackers create new software using our libraries.
|
||||
One of the projects aimed to create a decentralised, end-to-end encrypted messenger app,
|
||||
similar to what the [ETH-DM](https://rfc.vac.dev/spec/20/) protocol aims to achieve.
|
||||
similar to what the [ETH-DM](https://rfc.vac.dev/waku/standards/application/20/toy-eth-pm) protocol aims to achieve.
|
||||
Another project was a decentralised Twitter platform.
|
||||
Such projects allow us to prioritize the work on JS-Waku and understand how DevEx can be improved.
|
||||
|
||||
|
||||
@@ -166,7 +166,7 @@ example, here's the content topic used in our testnet:
|
||||
|
||||
`/toychat/2/huilong/proto`
|
||||
|
||||
For more on topics, see https://rfc.vac.dev/spec/23/
|
||||
For more on topics, see https://rfc.vac.dev/waku/informational/23/topics
|
||||
|
||||
### Status app
|
||||
|
||||
@@ -177,7 +177,7 @@ In the Status protocol, content topics - topics in Whisper/Waku v1 - are used fo
|
||||
- Public chats correspond to hash of the plaintext name
|
||||
- Negotiated topic for 1:1 chat with DHKE derived content topic
|
||||
|
||||
See more here https://specs.status.im/spec/10
|
||||
See more here http://rfc.vac.dev/status/deprecated/waku-usage
|
||||
|
||||
Currently, Status app is in the process of migrating to and testing Waku v2.
|
||||
|
||||
|
||||
@@ -31,7 +31,7 @@ this would require significant planning and resources,
|
||||
if it were to simulate "real world" conditions faithfully and measure bandwidth and resource usage across different network connections,
|
||||
robustness against attacks/losses, message latencies, etc.
|
||||
(There already exists a fairly comprehensive [evaluation of GossipSub v1.1](https://research.protocol.ai/publications/gossipsub-v1.1-evaluation-report/vyzovitis2020.pdf),
|
||||
on which [`11/WAKU2-RELAY`](https://rfc.vac.dev/spec/11/) is based.)
|
||||
on which [`11/WAKU2-RELAY`](https://rfc.vac.dev/waku/standards/core/11/relay) is based.)
|
||||
|
||||
As a starting point,
|
||||
this post contains a limited and local comparison of the _bandwidth_ profile (only) between Waku v1 and Waku v2.
|
||||
@@ -205,7 +205,7 @@ Some questions that we want to answer include:
|
||||
- What proportion of Waku v2's bandwidth usage is used to propagate _payload_ versus bandwidth spent on _control_ messaging to maintain the mesh?
|
||||
- To what extent is message latency (time until a message is delivered to its destination) affected by network size and message rate?
|
||||
- How _reliable_ is message delivery in Waku v2 for different network sizes and message rates?
|
||||
- What are the resource usage profiles of other Waku v2 protocols (e.g.[`12/WAKU2-FILTER`](https://rfc.vac.dev/spec/12/) and [`19/WAKU2-LIGHTPUSH`](https://rfc.vac.dev/spec/19/))?
|
||||
- What are the resource usage profiles of other Waku v2 protocols (e.g.[`12/WAKU2-FILTER`](https://rfc.vac.dev/waku/standards/core/12/previous-versions00/filter) and [`19/WAKU2-LIGHTPUSH`](https://rfc.vac.dev/waku/standards/core/19/lightpush))?
|
||||
|
||||
Our aim is to get ever closer to a "real world" understanding of Waku v2's performance characteristics,
|
||||
identify and fix vulnerabilities
|
||||
|
||||
@@ -128,7 +128,7 @@ It is enabled in a `nwaku` node by default.
|
||||
|
||||
This is a DHT-based discovery mechanism adapted to store and relay _node records_.
|
||||
Our implementation is based on [Ethereum's Discovery v5 protocol](https://github.com/ethereum/devp2p/blob/fa6428ada7385c13551873b2ae6ad2457c228eb8/discv5/discv5-theory.md)
|
||||
with some [minor modifications](https://rfc.vac.dev/spec/33/) to isolate our discovery network from that of Ethereum.
|
||||
with some [minor modifications](https://rfc.vac.dev/waku/standards/core/33/discv5) to isolate our discovery network from that of Ethereum.
|
||||
The decision to separate the Waku Discovery v5 network from Ethereum's was made on considerations of lookup efficiency.
|
||||
This comes at a possible tradeoff in network resilience.
|
||||
We are considering merging with the Ethereum Discovery v5 network in future,
|
||||
@@ -137,8 +137,8 @@ or even implement a hybrid solution.
|
||||
|
||||
## 5. Spam protection using RLN
|
||||
|
||||
An early addition to our suite of protocols was [an extension of `11/WAKU-RELAY`](https://rfc.vac.dev/spec/32/)
|
||||
that provided spam protection using [Rate Limiting Nullifiers (RLN)](https://rfc.vac.dev/spec/32/).
|
||||
An early addition to our suite of protocols was [an extension of `11/WAKU-RELAY`](https://rfc.vac.dev/vac/32/rln-v1)
|
||||
that provided spam protection using [Rate Limiting Nullifiers (RLN)](https://rfc.vac.dev/vac/32/rln-v1).
|
||||
The `nwaku` client now contains a working demonstration and integration of RLN relay.
|
||||
Check out [this tutorial](https://github.com/status-im/nim-waku/blob/ee96705c7fbe4063b780ac43b7edee2f6c4e351b/docs/tutorial/rln-chat2-live-testnet.md) to see the protocol in action using a toy chat application built on `nwaku`.
|
||||
We'd love for people to join us in dogfooding RLN spam protection as part of our operator incentive testnet.
|
||||
@@ -264,9 +264,9 @@ You can also view the changelog for past releases [here](https://github.com/stat
|
||||
|
||||
## References
|
||||
|
||||
- [17/WAKU-RLN-RELAY](https://rfc.vac.dev/spec/17/)
|
||||
- [32/RLN](https://rfc.vac.dev/spec/32/)
|
||||
- [33/WAKU2-DISCV5](https://rfc.vac.dev/spec/33/)
|
||||
- [17/WAKU-RLN-RELAY](https://rfc.vac.dev/waku/standards/core/17/rln-relay)
|
||||
- [32/RLN](https://rfc.vac.dev/vac/32/rln-v1)
|
||||
- [33/WAKU2-DISCV5](https://rfc.vac.dev/waku/standards/core/33/discv5)
|
||||
- [Capabilities advertising](https://github.com/vacp2p/rfc/issues/429)
|
||||
- [Configuring a domain name](https://github.com/status-im/nim-waku/tree/d2fccb5220144893f994a67f2cc26661247f101f/waku/v2#configuring-a-domain-name)
|
||||
- [Conversational security](https://github.com/vacp2p/research/issues/97)
|
||||
|
||||
@@ -16,7 +16,7 @@ Introducing and discussing ambient peer discovery methods currently used by Waku
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
[Waku v2](https://rfc.vac.dev/spec/10/) comprises a set of modular protocols for secure, privacy preserving communication.
|
||||
[Waku v2](https://rfc.vac.dev/waku/standards/core/10/waku2) comprises a set of modular protocols for secure, privacy preserving communication.
|
||||
Avoiding centralization, these protocols exchange messages over a P2P network layer.
|
||||
In order to build a P2P network, participating nodes first have to discover peers within this network.
|
||||
This is where [_ambient peer discovery_](https://docs.libp2p.io/concepts/publish-subscribe/#discovery) comes into play:
|
||||
@@ -129,7 +129,7 @@ If Waku v2 would do the same, only a small subset of the retrieved nodes would s
|
||||
A first naive solution for Waku v2 discv5 discovery is
|
||||
|
||||
- retrieve a random node set, which is achieved by querying for a set of randomly chosen node IDs
|
||||
- filter the returned nodes on the query path based on Waku v2 capability via the [Waku v2 ENR](https://rfc.vac.dev/spec/31/)
|
||||
- filter the returned nodes on the query path based on Waku v2 capability via the [Waku v2 ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md)
|
||||
- repeat until enough Waku v2 capable nodes are found
|
||||
|
||||
This query process boils down to random walk discovery, which is very resilient against attacks, but also very inefficient if the number of nodes supporting the desired capability is small.
|
||||
@@ -186,7 +186,7 @@ Our current solution and future plans for solving this issue are covered in the
|
||||
|
||||
### Simple Solution: Separate Discovery Network
|
||||
|
||||
The simple solution we currently use for [Waku v2 discv5](https://rfc.vac.dev/spec/33/) is a separate discv5 network.
|
||||
The simple solution we currently use for [Waku v2 discv5](https://rfc.vac.dev/waku/standards/core/33/discv5) is a separate discv5 network.
|
||||
All (well behaving) nodes in this network support Waku v2, resulting in a very high query efficiency.
|
||||
However, this solution reduces resilience because the difficulty of attacking a DHT scales with the number of participating nodes.
|
||||
|
||||
@@ -338,7 +338,7 @@ To mitigate information leakage by transmitting peer lists, we plan to only repl
|
||||
|
||||
## References
|
||||
|
||||
- [Waku v2](https://rfc.vac.dev/spec/10/)
|
||||
- [Waku v2](https://rfc.vac.dev/waku/standards/core/10/waku2)
|
||||
- [libp2p gossipsub](https://github.com/libp2p/specs/blob/10712c55ab309086a52eec7d25f294df4fa96528/pubsub/gossipsub/README.md)
|
||||
- [unstructured P2P network](https://en.wikipedia.org/wiki/Peer-to-peer#Unstructured_networks)
|
||||
- [ambient peer discovery](https://docs.libp2p.io/concepts/publish-subscribe/#discovery)
|
||||
@@ -351,13 +351,13 @@ To mitigate information leakage by transmitting peer lists, we plan to only repl
|
||||
- [Merkle trees](https://en.wikipedia.org/wiki/Merkle_tree)
|
||||
- [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack)
|
||||
- [eclipse attack](https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman)
|
||||
- [Waku v2 ENR](https://rfc.vac.dev/spec/31/)
|
||||
- [Waku v2 ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md)
|
||||
- [Discv5 topic discovery](https://github.com/ethereum/devp2p/blob/6b0abc3d956a626c28dce1307ee9f546db17b6bd/discv5/discv5-theory.md#ad-placement-and-topic-radius)
|
||||
- [Discv5 paper](https://github.com/harnen/service-discovery-paper)
|
||||
- [Discv5 vs Sybil and eclipse attacks](https://github.com/ethereum/devp2p/blob/6b0abc3d956a626c28dce1307ee9f546db17b6bd/discv5/discv5-rationale.md#sybil-and-eclipse-attacks)
|
||||
- [peer exchange idea](https://github.com/libp2p/specs/issues/222)
|
||||
- [Rendezvous protocol](https://github.com/libp2p/specs/blob/10712c55ab309086a52eec7d25f294df4fa96528/rendezvous/README.md)
|
||||
- [Waku v2 discv5](https://rfc.vac.dev/spec/33/)
|
||||
- [Waku v2 discv5](https://rfc.vac.dev/waku/standards/core/33/discv5)
|
||||
- [Gossipsub peer exchange](https://github.com/libp2p/specs/blob/10712c55ab309086a52eec7d25f294df4fa96528/pubsub/gossipsub/gossipsub-v1.1.md#prune-backoff-and-peer-exchange)
|
||||
- [NAT traversal](https://docs.libp2p.io/concepts/nat/)
|
||||
- [UPnP](https://en.wikipedia.org/wiki/Universal_Plug_and_Play)
|
||||
|
||||
@@ -19,7 +19,7 @@ We provide an overview of the Noise Protocol Framework as a tool to design effic
|
||||
|
||||
## Introduction
|
||||
|
||||
In this post we will provide an overview of how [Waku v2](https://rfc.vac.dev/spec/10/) users can adopt [Noise handshakes](http://www.noiseprotocol.org/noise.html) to agree on cryptographic keys used to securely encrypt messages.
|
||||
In this post we will provide an overview of how [Waku v2](https://rfc.vac.dev/waku/standards/core/10/waku2) users can adopt [Noise handshakes](http://www.noiseprotocol.org/noise.html) to agree on cryptographic keys used to securely encrypt messages.
|
||||
|
||||
This process belongs to the class of _key-exchange_ mechanisms, consisting of all those protocols that, with different levels of complexity and security guarantees, allow two parties to publicly agree on a secret without letting anyone else know what this secret is.
|
||||
|
||||
@@ -27,18 +27,18 @@ But why do we need key-exchange mechanisms in the first place?
|
||||
|
||||
With the advent of [public-key cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography), it become possible to decouple encryption from decryption through use of two distinct cryptographic keys: one _public_, used to encrypt information and that can be made available to anyone, and one _private_ (kept secret), which enables decryption of messages encrypted with its corresponding public key. The same does not happen in the case of [symmetric encryption schemes](https://en.wikipedia.org/wiki/Symmetric-key_algorithm) where, instead, the same key is used for both encryption and decryption operations and hence cannot be publicly revealed as for public keys.
|
||||
|
||||
In order to address specific application needs, many different public, symmetric and hybrid cryptographic schemes were designed: [Waku v1](https://rfc.vac.dev/spec/6/) and [Waku v2](https://rfc.vac.dev/spec/10/), which inherits part of their design from the Ethereum messaging protocol [Whisper](https://ethereum.org/en/developers/docs/networking-layer/#whisper), provide [support](https://rfc.vac.dev/spec/26/) to both public-key primitives ([`ECIES`](https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme), [`ECDSA`](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)) and symmetric primitives ([`AES-256-GCM`](https://en.wikipedia.org/wiki/Galois/Counter_Mode), [`KECCAK-256`](https://en.wikipedia.org/wiki/SHA-3)), used to sign, hash, encrypt and decrypt exchanged messages.
|
||||
In order to address specific application needs, many different public, symmetric and hybrid cryptographic schemes were designed: [Waku v1](https://rfc.vac.dev/spec/6/) and [Waku v2](https://rfc.vac.dev/waku/standards/core/10/waku2), which inherits part of their design from the Ethereum messaging protocol [Whisper](https://ethereum.org/en/developers/docs/networking-layer/#whisper), provide [support](https://rfc.vac.dev/waku/standards/application/26/payload) to both public-key primitives ([`ECIES`](https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme), [`ECDSA`](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)) and symmetric primitives ([`AES-256-GCM`](https://en.wikipedia.org/wiki/Galois/Counter_Mode), [`KECCAK-256`](https://en.wikipedia.org/wiki/SHA-3)), used to sign, hash, encrypt and decrypt exchanged messages.
|
||||
|
||||
In principle, when communications employ public-key based encryption schemes (`ECIES`, in the case of Waku), there is no need for a key-agreement among parties: messages can be directly encrypted using the recipient's public-key before being sent over the network. However, public-key encryption and decryption primitives are usually very inefficient in processing large amount of data, and this may constitute a bottleneck for many of today's applications. Symmetric encryption schemes such as `AES-256-GCM`, on the other hand, are much more efficient, but the encryption/decryption key needs to be shared among users beforehand any encrypted messages is exchanged.
|
||||
|
||||
To counter the downsides given by each of these two approaches while taking advantage of their strengths, hybrid constructions were designed. In these, public-key primitives are employed to securely agree on a secret key which, in turn, is used with a symmetric cipher for encrypting messages. In other words, such constructions specify a (public-key based) key-agreement mechanism!
|
||||
|
||||
Waku, up to [payload version 1](https://rfc.vac.dev/spec/14/#payload-encryption), does not implement nor recommend any protocol for exchanging symmetric ciphers' keys, leaving such task to the application layer. It is important to note that the kind of key-agreement employed has a direct impact on the security properties that can be granted on later encrypted messages, while security requirements usually depend on the specific application for which encryption is needed in the first place.
|
||||
Waku, up to [payload version 1](https://rfc.vac.dev/waku/standards/core/14/message/#payload-encryption), does not implement nor recommend any protocol for exchanging symmetric ciphers' keys, leaving such task to the application layer. It is important to note that the kind of key-agreement employed has a direct impact on the security properties that can be granted on later encrypted messages, while security requirements usually depend on the specific application for which encryption is needed in the first place.
|
||||
|
||||
In this regard, [Status](https://status.im), which builds on top of Waku, [implements](https://specs.status.im/spec/5) a custom version of the [X3DH](https://signal.org/docs/specifications/x3dh/) key-agreement protocol, in order to allow users to instantiate end-to-end encrypted communication channels. However, although such a solution is optimal when applied to (distributed) E2E encrypted chats, it is not flexible enough to fit or simplify the variety of applications Waku aims to address.
|
||||
In this regard, [Status](https://status.im), which builds on top of Waku, [implements](https://rfc.vac.dev/status/deprecated/secure-transport) a custom version of the [X3DH](https://signal.org/docs/specifications/x3dh/) key-agreement protocol, in order to allow users to instantiate end-to-end encrypted communication channels. However, although such a solution is optimal when applied to (distributed) E2E encrypted chats, it is not flexible enough to fit or simplify the variety of applications Waku aims to address.
|
||||
Hence, proposing and implementing one or few key-agreements which provide certain (presumably _strong_) security guarantees, would inevitably degrade performances of all those applications for which, given their security requirements, more tailored and efficient key-exchange mechanisms can be employed.
|
||||
|
||||
Guided by different examples, in the following sections we will overview Noise, a protocol framework we are [currently integrating](https://rfc.vac.dev/spec/35/) in Waku, for building secure key-agreements between two parties. One of the great advantage of using Noise is that it is possible to add support to new key-exchanges by just specifying users' actions from a predefined list, requiring none to minimal modifications to existing implementations. Furthermore, Noise provides a framework to systematically analyze protocols' security properties and the corresponding attacker threat models. This allows not only to easily design new key-agreements eventually optimized for specific applications we want to address, but also to easily analyze or even [formally verify](https://noiseexplorer.com/) any of such custom protocol!
|
||||
Guided by different examples, in the following sections we will overview Noise, a protocol framework we are [currently integrating](https://github.com/waku-org/specs/blob/master/standards/application/noise.md) in Waku, for building secure key-agreements between two parties. One of the great advantage of using Noise is that it is possible to add support to new key-exchanges by just specifying users' actions from a predefined list, requiring none to minimal modifications to existing implementations. Furthermore, Noise provides a framework to systematically analyze protocols' security properties and the corresponding attacker threat models. This allows not only to easily design new key-agreements eventually optimized for specific applications we want to address, but also to easily analyze or even [formally verify](https://noiseexplorer.com/) any of such custom protocol!
|
||||
|
||||
We believe that with its enormous flexibility and features, Noise represents a perfect candidate for bringing key-exchange mechanisms in Waku.
|
||||
|
||||
@@ -171,7 +171,7 @@ Nonetheless, due to the pure _token-based_ nature of handshake processing rules,
|
||||
|
||||
On a side note, we already mentioned that identity-hiding properties can be guaranteed against a passive attacker that only reads the communication occurring between Alice and Bob. However, an active attacker who compromised one party's static key and actively interferes with the parties' exchanged messages, may lower the identity-hiding security guarantees provided by some handshake patterns. In our security model we exclude such adversary, but, for completeness, in the following we report a summary of possible de-anonymization attacks that can be performed by such an active attacker.
|
||||
|
||||
For more details on supported handshakes and on how these are implemented in Waku, we refer to [35/WAKU2-NOISE](https://rfc.vac.dev/spec/35/) RFC.
|
||||
For more details on supported handshakes and on how these are implemented in Waku, we refer to [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md) RFC.
|
||||
|
||||
### The K1K1 Handshake
|
||||
|
||||
@@ -248,7 +248,7 @@ The core idea is to exchange after-handshake messages (encrypted with a Cipher S
|
||||
|
||||
This allows to decouple the handshaking phase from the actual encrypted communication, thus improving users' identity-hiding capabilities.
|
||||
|
||||
Furthermore, by publicly revealing a value derived from `session-id` on the corresponding session content topic, a Noise session can be marked as _stale_, enabling peers to save resources by discarding any eventually [stored](https://rfc.vac.dev/spec/13/) message sent to such content topic.
|
||||
Furthermore, by publicly revealing a value derived from `session-id` on the corresponding session content topic, a Noise session can be marked as _stale_, enabling peers to save resources by discarding any eventually [stored](https://rfc.vac.dev/waku/standards/core/13/store) message sent to such content topic.
|
||||
|
||||
One relevant aspect in today's applications is the possibility for users to employ different devices in their communications. In some cases, this is non-trivial to achieve since, for example, encrypted messages might be required to be synced on different devices which do not necessarily share the necessary key material for decryption and may be temporarily offline.
|
||||
|
||||
@@ -264,13 +264,13 @@ Informally, in the $N11M$ session management scheme, once the first Noise sessio
|
||||
|
||||
In the $NM$ session management scheme, instead, all pairs of Alice's and Bob's devices have a distinct Noise session: a message is then sent from the currently-in-use sender’s device to all recipient’s devices, by properly encrypting and sending it to the content topics of each corresponding Noise session. If sent messages should be available on all sender’s devices as well, we require each pair of sender’s devices to instantiate a Noise session used for syncing purposes.
|
||||
|
||||
For more technical details on how Noise sessions are instantiated and managed within these two mechanisms and the different trade-offs provided by the latter, we refer to [37/WAKU2-NOISE-SESSIONS](https://rfc.vac.dev/spec/37/).
|
||||
For more technical details on how Noise sessions are instantiated and managed within these two mechanisms and the different trade-offs provided by the latter, we refer to [WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions.md).
|
||||
|
||||
## Conclusions
|
||||
|
||||
In this post we provided an overview of Noise, a protocol framework for designing Diffie-Hellman based key-exchange mechanisms allowing systematic security and threat model analysis.
|
||||
|
||||
The flexibility provided by Noise components allows not only to fully replicate with same security guarantees well established key-exchange primitives such as X3DH, currently employed by Status [5/TRANSPORT-SECURITY](https://specs.status.im/spec/5), but enables also optimizations based on the reciprocal knowledge parties have of each other while allowing easier protocols' security analysis and (formal) verification.
|
||||
The flexibility provided by Noise components allows not only to fully replicate with same security guarantees well established key-exchange primitives such as X3DH, currently employed by Status [TRANSPORT-SECURITY](https://rfc.vac.dev/status/deprecated/secure-transport), but enables also optimizations based on the reciprocal knowledge parties have of each other while allowing easier protocols' security analysis and (formal) verification.
|
||||
|
||||
Furthermore, different handshakes can be combined and executed one after each other, a particularly useful feature to authenticate multiple static keys employed by different applications but also to ease keys revocation.
|
||||
|
||||
@@ -286,13 +286,13 @@ The available [implementation](https://github.com/status-im/nwaku/tree/master/wa
|
||||
|
||||
## References
|
||||
|
||||
- [6/WAKU1](https://rfc.vac.dev/spec/6/)
|
||||
- [10/WAKU2](https://rfc.vac.dev/spec/10/)
|
||||
- [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/)
|
||||
- [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26/)
|
||||
- [35/WAKU2-NOISE](https://rfc.vac.dev/spec/35/)
|
||||
- [37/WAKU2-NOISE-SESSIONS](https://rfc.vac.dev/spec/37/)
|
||||
- [5/TRANSPORT-SECURITY](https://specs.status.im/spec/5)
|
||||
- [6/WAKU1](https://rfc.vac.dev/waku/standards/legacy/6/waku1)
|
||||
- [10/WAKU2](https://rfc.vac.dev/waku/standards/core/10/waku2)
|
||||
- [13/WAKU2-STORE](https://rfc.vac.dev/waku/standards/core/13/store)
|
||||
- [26/WAKU-PAYLOAD](https://rfc.vac.dev/waku/standards/application/26/payload)
|
||||
- [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)
|
||||
- [37/WAKU2-NOISE-SESSIONS](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions.md)
|
||||
- [TRANSPORT-SECURITY](https://rfc.vac.dev/status/deprecated/secure-transport)
|
||||
- [The PubSub/GossipSub Protocols](https://github.com/libp2p/specs/tree/master/pubsub)
|
||||
- [The Noise Protocol Framework](http://www.noiseprotocol.org/noise.html)
|
||||
- [The X3DH Key-agreement Protocol](https://signal.org/docs/specifications/x3dh/)
|
||||
|
||||
@@ -19,7 +19,7 @@ Introducing a basic threat model and privacy/anonymity analysis for the Waku v2
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
[Waku v2](https://rfc.vac.dev/spec/10/) enables secure, privacy preserving communication using a set of modular P2P protocols.
|
||||
[Waku v2](https://rfc.vac.dev/waku/standards/core/10/waku2) 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.
|
||||
The goal is to eventually have a full privacy and anonymity analysis for each of the Waku v2 protocols, as well as covering the interactions of various Waku v2 protocols.
|
||||
@@ -27,7 +27,7 @@ This provides transparency with respect to Waku's current privacy and anonymity
|
||||
|
||||
In this post, we first give an informal description of security, privacy and anonymity in the context of Waku v2.
|
||||
For each definition, we summarize Waku's current guarantees regarding the respective property.
|
||||
We also provide attacker models, an attack-based threat model, and a first anonymity analysis of [Waku v2 relay](https://rfc.vac.dev/spec/11/) within the respective models.
|
||||
We also provide attacker models, an attack-based threat model, and a first anonymity analysis of [Waku v2 relay](https://rfc.vac.dev/waku/standards/core/11/relay) within the respective models.
|
||||
|
||||
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.
|
||||
@@ -90,7 +90,7 @@ We subdivide anonymity into _receiver anonymity_ and _sender anonymity_.
|
||||
#### Receiver Anonymity
|
||||
|
||||
We define receiver anonymity as _unlinkability of users' identities and the data they receive and/or related actions_.
|
||||
The data transmitted via Waku relay must be a [Waku message](https://rfc.vac.dev/spec/14/), which contains a content topic field.
|
||||
The data transmitted via Waku relay must be a [Waku message](https://rfc.vac.dev/waku/standards/core/14/message), which contains a content topic field.
|
||||
Because each message is associated with a content topic, and each receiver is interested in messages with specific content topics,
|
||||
receiver anonymity in the context of Waku corresponds to _subscriber-topic unlinkability_.
|
||||
An example for the "action" part of our receiver anonymity definition is subscribing to a specific topic.
|
||||
@@ -111,21 +111,21 @@ Assuming there are $n$ Waku content topics, a receiver has $n$-anonymity with re
|
||||
Technically, Waku allows distributing messages over several libp2p pubsub topics.
|
||||
This yields $k$-anonymity, assuming $k$ content topics share the same pubsub topic.
|
||||
However, if done wrongly, such sharding of pubsub topics can breach anonymity.
|
||||
A formal specification of anonymity-preserving topic sharding building on the concepts of [partitioned topics](https://specs.status.im/spec/10#partitioned-topic) is part of our roadmap.
|
||||
A formal specification of anonymity-preserving topic sharding building on the concepts of [partitioned topics](https://rfc.vac.dev/status/deprecated/10/waku-usage#partitioned-topic) is part of our roadmap.
|
||||
|
||||
Also, Waku is not directly concerned with 1:1 communication, so for this post, 1:1 communication is out of scope.
|
||||
Channels for 1:1 communication can be implemented on top of Waku relay.
|
||||
In the future, a 1:1 communication protocol might be added to Waku.
|
||||
Similar to topic sharding, it would maintain receiver anonymity leveraging [partitioned topics](https://specs.status.im/spec/10#partitioned-topic).
|
||||
Similar to topic sharding, it would maintain receiver anonymity leveraging [partitioned topics](https://rfc.vac.dev/status/deprecated/10/waku-usage/#partitioned-topic).
|
||||
|
||||
#### Sender Anonymity
|
||||
|
||||
We define sender anonymity as _unlinkability of users' identities and the data they send and/or related actions_.
|
||||
Because the data in the context of Waku is Waku messages, sender anonymity corresponds to _sender-message unlinkability_.
|
||||
|
||||
In summary, Waku offers weak sender anonymity because of [Waku's strict no sign policy](https://rfc.vac.dev/spec/11/#signature-policy),
|
||||
In summary, Waku offers weak sender anonymity because of [Waku's strict no sign policy](https://rfc.vac.dev/waku/standards/core/11/relay),
|
||||
which has its origins in the [Ethereum consensus specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#why-are-we-using-the-strictnosign-signature-policy).
|
||||
[17/WAKU-RLN-RELAY](https://rfc.vac.dev/spec/17/) and [18/WAKU2-SWAP](https://rfc.vac.dev/spec/18/) mitigate replay and injection attacks.
|
||||
[17/WAKU-RLN-RELAY](https://rfc.vac.dev/waku/standards/core/17/rln-relay) and [18/WAKU2-SWAP](https://rfc.vac.dev/waku/deprecated/18/swap) mitigate replay and injection attacks.
|
||||
|
||||
Waku currently does not offer sender anonymity in stronger attacker models, as well as cannot protect against targeted attacks in weaker attacker models like the single or multi node attacker.
|
||||
We will cover this in more detail in later sections.
|
||||
@@ -193,7 +193,7 @@ which Waku uses for ambient peer discovery.
|
||||
|
||||
### External
|
||||
|
||||
An external attacker can only see encrypted traffic (protected by a secure channel set up with [Noise](https://rfc.vac.dev/spec/35/)).
|
||||
An external attacker can only see encrypted traffic (protected by a secure channel set up with [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)).
|
||||
Because an internal position can be easily obtained,
|
||||
in practice external attackers would mount combined attacks that leverage both internal an external attacks.
|
||||
We cover this more below when describing attacks.
|
||||
@@ -244,8 +244,8 @@ This also goes well with the modular design philosophy of Waku v2, as layers of
|
||||
Instead of looking at a multiplicative explosion of possible interactions, we look at the core in this article, and cover the most relevant combinations in future posts.
|
||||
|
||||
Further restricting the scope, we will look at the data field of a relay message as a black box.
|
||||
In a second article on Waku v2 relay, we will look into the data field, which according to the [specification of Waku v2 relay](https://rfc.vac.dev/spec/11/#message-fields) must be a [Waku v2 message](https://rfc.vac.dev/spec/14/).
|
||||
We only consider messages with version field `2`, which indicates that the payload has to be encoded using [35/WAKU2-NOISE](https://rfc.vac.dev/spec/35/).
|
||||
In a second article on Waku v2 relay, we will look into the data field, which according to the [specification of Waku v2 relay](https://rfc.vac.dev/waku/standards/core/11/relay#message-fields) must be a [Waku v2 message](https://rfc.vac.dev/waku/standards/core/14/message).
|
||||
We only consider messages with version field `2`, which indicates that the payload has to be encoded using [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md).
|
||||
|
||||
### Prerequisite: Get a Specific Position in the Network
|
||||
|
||||
@@ -263,7 +263,7 @@ A linearly scaling nodes attacker can leverage DHT based discovery systems to bo
|
||||
|
||||
In the scope we defined above, Waku v2 is resilient against replay attacks.
|
||||
GossipSub nodes, and by extension Waku relay nodes, feature a `seen` cache, and only relay messages they have not seen before.
|
||||
Further, replay attacks will be punished by [RLN](https://rfc.vac.dev/spec/17/) and [SWAP](https://rfc.vac.dev/spec/18/).
|
||||
Further, replay attacks will be punished by [RLN](https://rfc.vac.dev/waku/standards/core/17/rln-relay) and [SWAP](https://rfc.vac.dev/waku/deprecated/18/swap).
|
||||
|
||||
### Neighbourhood Surveillance
|
||||
|
||||
@@ -311,8 +311,8 @@ An active single node attacker could run a disruption attack by
|
||||
|
||||
While (1) has a negative effect on availability, the impact is not significant.
|
||||
A linearly scaling botnet attacker, however, could significantly disrupt the network with such an attack.
|
||||
(2) is thwarted by [RLN](https://rfc.vac.dev/spec/17/).
|
||||
Also [SWAP](https://rfc.vac.dev/spec/18/) helps mitigating DoS attacks.
|
||||
(2) is thwarted by [RLN](https://rfc.vac.dev/waku/standards/core/17/rln-relay).
|
||||
Also [SWAP](https://rfc.vac.dev/waku/deprecated/18/swap) helps mitigating DoS attacks.
|
||||
|
||||
A local attacker can DoS Waku by dropping all Waku traffic within its controlled network segment.
|
||||
An AS attacker can DoS Waku within its authority, while a global attacker can DoS the whole network.
|
||||
@@ -323,7 +323,7 @@ A countermeasure are censorship resistance techniques like [Pluggable Transports
|
||||
Currently, Waku v2 relay offers k-anonymity with respect to receiver anonymity.
|
||||
This also includes k-anonymity towards legitimate members of the same topic.
|
||||
|
||||
Waku v2 relay offers sender anonymity in the single node attacker model with its [strict no sign policy](https://rfc.vac.dev/spec/11/#signature-policy).
|
||||
Waku v2 relay offers sender anonymity in the single node attacker model with its [strict no sign policy](https://rfc.vac.dev/waku/standards/core/11/relay/#signature-policy).
|
||||
Currently, Waku v2 does not guarantee sender anonymity in the multi node and stronger attacker models.
|
||||
However, we are working on modular anonymity-preserving protocols and building blocks as part of our privacy/anonymity roadmap.
|
||||
The goal is to allow tunable anonymity with respect to trade offs between _strong anonymity_, _low bandwidth_, and _low latency_.
|
||||
@@ -341,40 +341,41 @@ As an intermediate step, we might directly employ Tor for onion-routing, and [Ny
|
||||
In future research log posts, we will cover further Waku v2 protocols and identify anonymity problems that will be added to our roadmap.
|
||||
These protocols comprise
|
||||
|
||||
- [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/), which can violate receiver anonymity as it allows filtering by content topic.
|
||||
- [13/WAKU2-STORE](https://rfc.vac.dev/waku/standards/core/13/store), which can violate receiver anonymity as it allows filtering by content topic.
|
||||
A countermeasure is using the content topic exclusively for local filters.
|
||||
- [12/WAKU2-FILTER](https://rfc.vac.dev/spec/12/), which discloses nodes' interest in topics;
|
||||
- [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/), which also discloses nodes' interest in topics and links the lightpush client as the sender of a message to the lightpush service node;
|
||||
- [21/WAKU2-FTSTORE](https://rfc.vac.dev/spec/21/), which discloses nodes' interest in specific time ranges allowing to infer information like online times.
|
||||
- [12/WAKU2-FILTER](https://rfc.vac.dev/waku/standards/core/12/filter), which discloses nodes' interest in topics;
|
||||
- [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/waku/standards/core/19/lightpush), which also discloses nodes' interest in topics and links the lightpush client as the sender of a message to the lightpush service node;
|
||||
- [21/WAKU2-FTSTORE](https://rfc.vac.dev/waku/standards/application/21/fault-tolerant-store), which discloses nodes' interest in specific time ranges allowing to infer information like online times.
|
||||
|
||||
While these protocols are not necessary for the operation of Waku v2, and can be seen as pluggable features,
|
||||
we aim to provide alternatives without the cost of lowering the anonymity level.
|
||||
|
||||
## References
|
||||
|
||||
- [10/WAKU2](https://rfc.vac.dev/spec/10/)
|
||||
- [11/WAKU2-RELAY](https://rfc.vac.dev/spec/11/)
|
||||
- [10/WAKU2](https://rfc.vac.dev/waku/standards/core/10/waku2)
|
||||
- [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay)
|
||||
- [libp2p GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
|
||||
- [Security](https://en.wikipedia.org/wiki/Information_security)
|
||||
- [Authentication](https://en.wikipedia.org/wiki/Authentication)
|
||||
- [Non-repudiation](https://en.wikipedia.org/wiki/Non-repudiation)
|
||||
- [Noise Protocol Framework](https://noiseprotocol.org/)
|
||||
- [plausible deniability](https://en.wikipedia.org/wiki/Plausible_deniability#Use_in_cryptography)
|
||||
- [Waku v2 message](https://rfc.vac.dev/spec/14/)
|
||||
- [partitioned topics](https://specs.status.im/spec/10#partitioned-topic)
|
||||
- [Waku v2 message](https://rfc.vac.dev/waku/standards/core/14/message)
|
||||
- [partitioned topics](https://rfc.vac.dev/status/deprecated/10/waku-usage
|
||||
#partitioned-topic)
|
||||
- [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack)
|
||||
- [Dolev-Yao model](https://en.wikipedia.org/wiki/Dolev%E2%80%93Yao_model)
|
||||
- [35/WAKU2-NOISE](https://rfc.vac.dev/spec/35/)
|
||||
- [WAKU2-NOISE](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)
|
||||
- [33/WAKU2-DISCV5](https://vac.dev/wakuv2-apd)
|
||||
- [strict no sign policy](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#why-are-we-using-the-strictnosign-signature-policy)
|
||||
- [Waku v2 strict no sign policy](https://rfc.vac.dev/spec/11/#signature-policy)
|
||||
- [17/WAKU-RLN-RELAY](https://rfc.vac.dev/spec/17/)
|
||||
- [Waku v2 strict no sign policy](https://rfc.vac.dev/waku/standards/core/11/relay#signature-policy)
|
||||
- [17/WAKU-RLN-RELAY](https://rfc.vac.dev/waku/standards/core/17/rln-relay)
|
||||
- [anonymity trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html)
|
||||
- [18/WAKU2-SWAP](https://rfc.vac.dev/spec/18/)
|
||||
- [18/WAKU2-SWAP](https://rfc.vac.dev/waku/deprecated/18/swap)
|
||||
- [Pluggable Transports](https://www.pluggabletransports.info/about/)
|
||||
- [Nym](https://nymtech.net/)
|
||||
- [Dandelion++](https://arxiv.org/abs/1805.11060)
|
||||
- [13/WAKU2-STORE](https://rfc.vac.dev/spec/13/)
|
||||
- [12/WAKU2-FILTER](https://rfc.vac.dev/spec/12/)
|
||||
- [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/)
|
||||
- [21/WAKU2-FTSTORE](https://rfc.vac.dev/spec/21/)
|
||||
- [13/WAKU2-STORE](https://rfc.vac.dev/waku/standards/core/13/store)
|
||||
- [12/WAKU2-FILTER](https://rfc.vac.dev/waku/standards/core/12/filter)
|
||||
- [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/waku/standards/core/19/lightpush)
|
||||
- [21/WAKU2-FTSTORE](https://rfc.vac.dev/waku/standards/application/21/fault-tolerant-store)
|
||||
|
||||
@@ -219,7 +219,7 @@ gave a [talk](https://www.youtube.com/watch?v=g41nHQ0mLoA) in Amsterdam at
|
||||
Devconnect about this. We have some write-ups on RLN
|
||||
[here](https://vac.dev/rln-relay) by Sanaz who has been pushing a lot of this
|
||||
from our side. There's also another talk at Devcon by Tyler going into RLN in
|
||||
more detail. Finally, here's the [RLN spec](https://rfc.vac.dev/spec/32/).
|
||||
more detail. Finally, here's the [RLN spec](https://rfc.vac.dev/vac/32/rln-v1).
|
||||
|
||||
I'll briefly go over what it is, the interface and circuit and then talk about
|
||||
how it is used in Waku.
|
||||
|
||||
@@ -139,11 +139,11 @@ Waku can help:
|
||||
share transactions with other sequencers. Waku nodes can act as a neutral network to enable all sequences to access
|
||||
transactions.
|
||||
- Enable censorship-resistant wallet<>L2 communication,
|
||||
- Provide rate limiting mechanism for spam protection: Using [RLN](https://rfc.vac.dev/spec/32/) to prevent DDOS.
|
||||
- Provide rate limiting mechanism for spam protection: Using [RLN](https://rfc.vac.dev/vac/32/rln-v1) to prevent DDOS.
|
||||
|
||||
## Device pairing and communication
|
||||
|
||||
With [Waku Device Pairing](https://rfc.vac.dev/spec/43/), a user can setup a secure encrypted communication channel
|
||||
With [Waku Device Pairing](https://github.com/waku-org/specs/blob/master/standards/application/device-pairing.md), a user can setup a secure encrypted communication channel
|
||||
between their devices. As this channel would operate over Waku, it would be censorship-resistant and privacy preserving.
|
||||
These two devices could be:
|
||||
|
||||
@@ -172,8 +172,8 @@ What you can expect next:
|
||||
- [Scalability and performance studies](https://forum.vac.dev/t/waku-v2-scalability-studies/142/9) and improvement across Waku software,
|
||||
- [New websites](https://github.com/waku-org/waku.org/issues/15) to easily find documentation about Waku and its implementations,
|
||||
- New Waku protocols implemented in all code bases and cross client PoCs
|
||||
([noise](https://rfc.vac.dev/spec/35/), [noise-sessions](https://rfc.vac.dev/spec/37/),
|
||||
[waku-rln-relay](https://rfc.vac.dev/spec/17/), etc),
|
||||
([noise](https://github.com/waku-org/specs/blob/master/standards/application/noise.md), [noise-sessions](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions.md),
|
||||
[waku-rln-relay](https://rfc.vac.dev/waku/standards/core/17/rln-relay), etc),
|
||||
- Easier to [run your own waku node](https://github.com/status-im/nwaku/issues/828), more operator trials,
|
||||
- Dogfooding and Improvement of existing protocols (e.g. [Waku Filter](https://github.com/vacp2p/rfc/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc++12%2FWAKU2-FILTER)),
|
||||
- Continue our focus Waku portability: Browser,
|
||||
|
||||
@@ -111,7 +111,7 @@ We have several ongoing initiatives:
|
||||
|
||||
- Analyzing the Status Community protocol to confirm efficient usage of Waku [[4]](https://github.com/vacp2p/research/issues/177)
|
||||
- Simulating the Waku Network to measure actual bandwidth usage [[5]](https://github.com/waku-org/pm/issues/2)
|
||||
- Segregating chat messages from control and media messages [[6]](https://rfc.vac.dev/spec/57/#control-message-shards)
|
||||
- Segregating chat messages from control and media messages [[6]](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md/#control-message-shards)
|
||||
|
||||
The final solution will likely be a combination of protocols that reduce bandwidth usage or mitigate the risk of DOS attacks, providing flexibility for users and platforms to enable the best experience.
|
||||
|
||||
@@ -128,9 +128,9 @@ to devices with limited resources.
|
||||
|
||||
## References
|
||||
|
||||
1. [51/WAKU2-RELAY-SHARDING](https://rfc.vac.dev/spec/51/)
|
||||
2. [57/STATUS-Simple-Scaling](https://rfc.vac.dev/spec/57/)
|
||||
3. [58/RLN-V2](https://rfc.vac.dev/spec/58/)
|
||||
1. [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)
|
||||
2. [57/STATUS-Simple-Scaling](https://rfc.vac.dev/status/raw/simple-scaling)
|
||||
3. [RLN-V2](https://rfc.vac.dev/vac/raw/rln-v2)
|
||||
4. [Scaling Status Communities: Potential Problems](https://github.com/vacp2p/research/issues/177)
|
||||
5. [Waku Network Testing](https://github.com/waku-org/pm/issues/2)
|
||||
6. [51/WAKU2-RELAY-SHARDING: Control Message Shards](https://rfc.vac.dev/spec/57/#control-message-shards)
|
||||
6. [WAKU2-RELAY-SHARDING: Control Message Shards](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md/#control-message-shards)
|
||||
|
||||
@@ -35,7 +35,7 @@ Actors:
|
||||
- Bob the responder
|
||||
|
||||
1. The first step in achieving secure device pairing using Noise and Waku is for Bob generate the pairing information which could be transmitted out-of-band. For this, Bob opens https://examples.waku.org/noise-js/ and a QR code is generated, containing the data required to do the handshake. This pairing QR code is timeboxed, meaning that after 2 minutes, it will become invalid and a new QR code must be generated
|
||||
2. Alice scans the QR code using a mobile phone. This will open the app with the QR code parameters initiating the handshake process which is described in [43/WAKU2-DEVICE-PAIRING](https://rfc.vac.dev/spec/43/#protocol-flow). These messages are exchanged between two devices over Waku to establish a secure connection. The handshake messages consist of three main parts: the initiator's message, the responder's message, and the final message, which are exchanged to establish a secure connection. While using js-noise, the developer is abstracted of this process, since the messaging happens automatically depending on the actions performed by the actors in the pairing process.
|
||||
2. Alice scans the QR code using a mobile phone. This will open the app with the QR code parameters initiating the handshake process which is described in [WAKU2-DEVICE-PAIRING](https://github.com/waku-org/specs/blob/master/standards/application/device-pairing.md/#protocol-flow). These messages are exchanged between two devices over Waku to establish a secure connection. The handshake messages consist of three main parts: the initiator's message, the responder's message, and the final message, which are exchanged to establish a secure connection. While using js-noise, the developer is abstracted of this process, since the messaging happens automatically depending on the actions performed by the actors in the pairing process.
|
||||
3. Both Alice and Bob will be asked to verify each other's identity. This is done by confirming if an 8-digits authorization code match in both devices. If both actors confirm that the authorization code is valid, the handshake concludes succesfully
|
||||
4. Alice and Bob receive a set of shared keys that can be used to start exchanging encrypted messages. The shared secret keys generated during the handshake process are used to encrypt and decrypt messages sent between the devices. This ensures that the messages exchanged between the devices are secure and cannot be intercepted or modified by an attacker.
|
||||
|
||||
@@ -52,9 +52,9 @@ Don't hesitate to try the live example at https://examples.waku.org/noise-js and
|
||||
### References
|
||||
|
||||
- [Noise handshakes as key-exchange mechanism for Waku](https://vac.dev/wakuv2-noise)
|
||||
- [Noise Protocols for Waku Payload Encryption](https://rfc.vac.dev/spec/35/)
|
||||
- [Session Management for Waku Noise](https://rfc.vac.dev/spec/37/)
|
||||
- [Device pairing and secure transfers with Noise](https://rfc.vac.dev/spec/43/)
|
||||
- [Noise Protocols for Waku Payload Encryption](https://github.com/waku-org/specs/blob/master/standards/application/noise.md)
|
||||
- [Session Management for Waku Noise](https://github.com/waku-org/specs/blob/master/standards/application/noise-sessions.md)
|
||||
- [Device pairing and secure transfers with Noise](https://github.com/waku-org/specs/blob/master/standards/application/device-pairing.md)
|
||||
- [go-waku Noise's example](https://github.com/waku-org/go-waku/tree/master/examples/noise)
|
||||
- [js-waku Noise's example](https://github.com/waku-org/js-waku-examples/tree/master/examples/noise-js)
|
||||
- [js-noise](https://github.com/waku-org/js-noise/)
|
||||
|
||||
@@ -132,7 +132,7 @@ Both IP and KYC logging prevent systems from being truly anonymous, and hence, c
|
||||
RLN can be used as an alternative, which provides the best of both worlds, i.e a permissioned membership set, as well as anonymous signaling.
|
||||
However, we are bound by k-anonymity rules of the membership set.
|
||||
|
||||
[Waku-RLN-Relay](https://rfc.vac.dev/spec/17/) is a [libp2p](https://libp2p.io) pubsub validator that verifies if a proof attached to a given message is valid.
|
||||
[Waku-RLN-Relay](https://rfc.vac.dev/waku/standards/core/17/rln-relay) is a [libp2p](https://libp2p.io) pubsub validator that verifies if a proof attached to a given message is valid.
|
||||
In case the proof is valid, the message is relayed.
|
||||
|
||||
## Performance analysis
|
||||
@@ -221,8 +221,8 @@ Following is a diagram that will help understand the dependency tree -
|
||||
|
||||
* [RLN Circuits](https://github.com/rate-limiting-nullifier/circom-rln)
|
||||
* [Zerokit](https://github.com/vacp2p/zerokit)
|
||||
* [RLN-V1 RFC](https://rfc.vac.dev/spec/32/)
|
||||
* [RLN-V2 RFC](https://rfc.vac.dev/spec/58/)
|
||||
* [RLN-V1 RFC](https://rfc.vac.dev/vac/32/rln-v1)
|
||||
* [RLN-V2 RFC](https://rfc.vac.dev/vac/raw/rln-v2)
|
||||
* [RLN Implementers guide](https://hackmd.io/7cBCMU5hS5OYv8PTaW2wAQ?view)
|
||||
* [groth16](https://eprint.iacr.org/2016/260.pdf)
|
||||
* [bn254](https://eprint.iacr.org/2013/879.pdf)
|
||||
|
||||
@@ -154,7 +154,7 @@ Consequently, it allows for a more scalable and efficient RLN verifier.
|
||||
|
||||
- [RLN Circuits](https://github.com/rate-limiting-nullifier/circom-rln)
|
||||
- [Zerokit](https://github.com/vacp2p/zerokit)
|
||||
- [RLN-V1 RFC](https://rfc.vac.dev/spec/32/)
|
||||
- [RLN-V2 RFC](https://rfc.vac.dev/spec/58/)
|
||||
- [RLN-V1 RFC](https://rfc.vac.dev/vac/32/rln-v1)
|
||||
- [RLN-V2 RFC](https://rfc.vac.dev/vac/raw/rln-v2)
|
||||
- [RLN Implementers guide](https://hackmd.io/7cBCMU5hS5OYv8PTaW2wAQ?view)
|
||||
- [Strengthening Anonymous DoS Prevention with Rate Limiting Nullifiers in Waku](https://vac.dev/rlog/rln-anonymous-dos-prevention)
|
||||
|
||||
@@ -228,6 +228,6 @@ It enhances the user's flexibility in setting their message limits and cost-opti
|
||||
- [Gnark](https://docs.gnark.consensys.io/)
|
||||
- [Poseidon Hash](https://eprint.iacr.org/2019/458.pdf)
|
||||
- [Zerokit](https://github.com/vacp2p/zerokit)
|
||||
- [RLN-v1 RFC](https://rfc.vac.dev/spec/32/)
|
||||
- [RLN-v2 RFC](https://rfc.vac.dev/spec/58/)
|
||||
- [RLN-v1 RFC](https://rfc.vac.dev/vac/32/rln-v1)
|
||||
- [RLN-v2 RFC](https://rfc.vac.dev/vac/raw/rln-v2)
|
||||
- [Waku](https://waku.org)
|
||||
|
||||
Reference in New Issue
Block a user