From d278fb406a2852b5fb3433af80bfc6c77db9de37 Mon Sep 17 00:00:00 2001 From: Franck Royer Date: Fri, 7 May 2021 10:43:24 +1000 Subject: [PATCH] 20: Ethereum Direct Message with Waku v2 (#365) --- content/docs/rfcs/20/README.md | 113 +++++++++++++++++++++++++++++++++ content/menu/index.md | 1 + 2 files changed, 114 insertions(+) create mode 100644 content/docs/rfcs/20/README.md diff --git a/content/docs/rfcs/20/README.md b/content/docs/rfcs/20/README.md new file mode 100644 index 00000000..f74e961e --- /dev/null +++ b/content/docs/rfcs/20/README.md @@ -0,0 +1,113 @@ +--- +slug: 20 +title: 20/ETH-DM +name: Ethereum Direct Message +status: raw +editor: Franck Royer +contributors: +--- + +This specification explains the Ethereum Direct Message protocol +which enables a peer to send a direct message to another peer +using the Waku v2 network, and the peer's Ethereum address. + +# Goal + +Alice wants to send an encrypted message to Bob, where only Bob can decrypt the message. + +# Variables + +Here are the variables used in the protocol and their definition: + +- `A` is Alice's Ethereum root HD public key (also named account, address), +- `B` is Bob's Ethereum root HD public key (also named account, address), +- `a` is the private key of `A`, and is only known by Alice, +- `b` is the private key of `B`, and is only known by Bob. + +# Design Requirements + +The proposed protocol MUST adhere to the following design requirements: + +1. Alice knows Bob's Ethereum root HD public key `B`, +2. Alice wants to send message `M` to Bob, +3. Bob SHOULD be able to get `M` using [13/WAKU2-STORE](/spec/13), when querying a store node that hosts `M`, +4. Bob MUST recognize he is `M`'s recipient when relaying it via [11/WAKU2-RELAY](/spec/11), +5. Carole MUST NOT be able to read `M`'s content even if she is storing it or relaying it. + +## Out of scope + +At this stage, we acknowledge that: + +1. Because `Bw` is part of the message in clear, +Alice can know how many messages from other parties Bob receive, +and Carole can see that how many messages a recipient `Bw` is receiving (unlinkability is broken). + +# Steps + +1. Alice MUST derive Bob's waku public Key `Bw` from `B`, +2. Alice SHOULD derive her own waku public key `Aw` from `A`, +3. Alice creates `M'` which MUST contain `M` and `Aw`, it MAY contain `A`, +4. Alice encrypts `M'` using `Bw`, resulting in `m'`, +5. Alice creates waku message `Mw` with + `payload` `m'` and + `contentTopic` `/waku/2/eth-dm/child-pubkey/Bw/proto`, + with `Bw` in hex format (`0xAb1..`), +6. Alice publishes `Mw` via [11/WAKU2-RELAY](/spec/11), +7. Bob captures received messages via [11/WAKU2-RELAY](/spec/11) that have `contentTopic` `/waku/2/eth-dm/child-pubkey/Bw/proto`, +8. Bob queries [13/WAKU2-STORE](/spec/13) with `contentTopics` set to `["/waku/2/eth-dm/child-pubkey/Bw/proto"]`, +9. When retrieving `Mw` Bob derives `bw` from `b`, +10. Bob uses `bw` to decrypt message `Mw`, he learns `m` and `Aw`, +11. Bob replies to Alice in the same manner, setting the `contentTopic` to `/waku/2/eth-dm/child-pubkey/Aw/proto`. + +## Derivation + +Public parent key (`B`) to public child key (`Bw`) derivation is only possible with non-hardened paths [\[1\]](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). + +TODO: Investigate commonly used derivation path to decide on one. + +## Encryption + +TODO: Define encryption method to use. + +## Reply + +To ascertain the fact that Alice receives Bob's reply, she could include connection details such as her peer id and multiaddress in the message. +However, this leads to privacy concerns if she does not use an anonymizing network such as tor. + +Because of that, Alice only includes `Aw` in `M'`. + +## Message retrieval + +To satisfy design requirements 3 and 4, we are using the `contentTopic` as a low-computation method to retrieve messages. + +Using a prefix such as `direct-message/eth-pubkey` reduces possible conflicts with other use cases that would also use a key or 32 byte array. + +We could also consider adding a version to allow an evolution of the field and its usage, e.g. `/waku/2/eth-dm/child-pubkey/1/Aw/proto` + +TODO: Point to spec recommending formatting of `contentTopic`, currently tracked in issue [#364](https://github.com/vacp2p/rfc/issues/364) [2]. + +# Payloads + +```protobuf +syntax = "proto3"; + +message DirectMessage { + DirectMessageContent message = 1; // `M` + bytes sender_waku_public_key = 2; // `Aw` + bytes sender_root_public_key = 3; // `A` +} + +message DirectMessageContent { + bytes message = 1; + string encoding = 2; // Encoding of the message, utf-8 if not present. +} +``` + +# References + +- [\[1\] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) +- [\[2\] https://github.com/vacp2p/rfc/issues/364](https://github.com/vacp2p/rfc/issues/364) + +# Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/content/menu/index.md b/content/menu/index.md index 19653d77..17985856 100644 --- a/content/menu/index.md +++ b/content/menu/index.md @@ -9,6 +9,7 @@ bookMenuLevels: 1 - [17/WAKU2-RLNRELAY]({{< relref "/docs/rfcs/17/README.md" >}}) - [18/WAKU2-SWAP]({{< relref "/docs/rfcs/18/README.md" >}}) - [19/WAKU2-LIGHTPUSH]({{< relref "/docs/rfcs/19/README.md" >}}) + - [20/ETH-DM]({{< relref "/docs/rfcs/20/README.md" >}}) - Draft - [1/COSS]({{< relref "/docs/rfcs/1/README.md" >}})