Ethereum Direct Message

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, when querying a store node that hosts M,
  4. Bob MUST recognize he is M’s recipient when relaying it via 11/WAKU2-RELAY,
  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,
  7. Bob captures received messages via 11/WAKU2-RELAY that have contentTopic /waku/2/eth-dm/child-pubkey/Bw/proto,
  8. Bob queries 13/WAKU2-STORE 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].

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 [2].

Payloads #

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 #

Copyright #

Copyright and related rights waived via CC0.