diff --git a/waku/informational/20/toy-eth-pm.md b/waku/informational/20/toy-eth-pm.md index 33bc578..80a59b3 100644 --- a/waku/informational/20/toy-eth-pm.md +++ b/waku/informational/20/toy-eth-pm.md @@ -3,7 +3,7 @@ slug: 20 title: 20/TOY-ETH-PM name: Toy Ethereum Private Message status: draft -tags: waku-application +tags: waku/application editor: Franck Royer contributors: --- @@ -24,12 +24,12 @@ In the current state, the protocol has privacy and features [limitations](#limit and hence is not fit for production usage. We hope this can be an inspiration for developers wishing to build on top of Waku v2. -# Goal +## Goal Alice wants to send an encrypted message to Bob, where only Bob can decrypt the message. Alice only knows Bob's Ethereum Address. -# Variables +## Variables Here are the variables used in the protocol and their definition: @@ -38,7 +38,7 @@ Here are the variables used in the protocol and their definition: - `B'` is Bob's Encryption Public Key, for which `b'` is the private key. - `M` is the private message that Alice sends to Bob. -# Design Requirements +## Design Requirements The proposed protocol MUST adhere to the following design requirements: @@ -46,7 +46,7 @@ The proposed protocol MUST adhere to the following design requirements: 2. Bob is willing to participate to Eth-PM, and publishes `B'`, 3. Bob's ownership of `B'` MUST be verifiable, 4. Alice wants to send message `M` to Bob, -5. Bob SHOULD be able to get `M` using [10/WAKU2 spec](../../core/10/WAKU2.md), +5. Bob SHOULD be able to get `M` using [10/WAKU2 spec](../../standards/core/10/WAKU2.md), 6. Participants only have access to their Ethereum Wallet via the Web3 API, 7. Carole MUST NOT be able to read `M`'s content even if she is storing it or relaying it, 8. [Waku Message Version 1](../../standards/application/26) Asymmetric Encryption is used for encryption purposes. @@ -69,23 +69,23 @@ See the [Status secure transport spec](https://specs.status.im/spec/5) for an ex Bob MUST decide to participate in the protocol before Alice can send him a message. This is discussed in more in details in [Consideration for a non-interactive/uncoordinated protocol](#consideration-for-a-non-interactiveuncoordinated-protocol) -# The protocol +## The protocol -## Generate Encryption KeyPair +### Generate Encryption KeyPair First, Bob needs to generate a keypair for Encryption purposes. Bob SHOULD get 32 bytes from a secure random source as Encryption Private Key, `b'`. Then Bob can compute the corresponding SECP-256k1 Public Key, `B'`. -# Broadcast Encryption Public Key +### Broadcast Encryption Public Key For Alice to encrypt messages for Bob, Bob SHOULD broadcast his Encryption Public Key `B'`. To prove that the Encryption Public Key `B'` is indeed owned by the owner of Bob's Ethereum Account `B`, Bob MUST sign `B'` using `B`. -## Sign Encryption Public Key +### Sign Encryption Public Key To prove ownership of the Encryption Public Key, Bob must sign it using [EIP-712](https://eips.ethereum.org/EIPS/eip-712) v3, @@ -125,7 +125,7 @@ const typedData = { } ``` -## Public Key Message +### Public Key Message The resulting signature is then included in a `PublicKeyMessage`, where @@ -155,7 +155,7 @@ it is not enough in itself to deduce Bob's Public Key. This is why the protocol dictates that Bob MUST send his Public Key first, and Alice MUST receive it before she can send him a message. -Moreover, nim-waku, the reference implementation of [13/WAKU2-STORE](/spec/13/), +Moreover, nim-waku, the reference implementation of [13/WAKU2-STORE](../../standards/core/13/store.md)), stores messages for a maximum period of 30 days. This means that Bob would need to broadcast his public key at least every 30 days to be reachable. @@ -196,19 +196,24 @@ Similarly to above, if Bob stops publishing his public key then it may be an ind In any case, the protocol could be modified to store the Public Key in a more permanent storage, such as a dedicated smart contract on the blockchain. -# Send Private Message +## Send Private Message Alice MAY monitor the Waku v2 to collect Ethereum Address and Encryption Public Key tuples. Alice SHOULD verify that the `signature`s of `PublicKeyMessage`s she receives are valid as per EIP-712. She SHOULD drop any message without a signature or with an invalid signature. -Using Bob's Encryption Public Key, retrieved via [10/WAKU2](/spec/13), Alice MAY now send an encrypted message to Bob. +Using Bob's Encryption Public Key, retrieved via [10/WAKU2](../../standards/core/10/WAKU2.md), Alice MAY now send an encrypted message to Bob. If she wishes to do so, Alice MUST encrypt her message `M` using Bob's Encryption Public Key `B'`, -as per [26/WAKU-PAYLOAD Asymmetric Encryption specs](/spec/26/#asymmetric). +as per [26/WAKU-PAYLOAD Asymmetric Encryption specs](../../standards/application/26/payload.md/#asymmetric). Alice SHOULD now publish this message on the Private Message content topic. # Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +## References +- [10/WAKU2 spec](../../standards/core/10/WAKU2.md) +- [Waku Message Version 1](../../standards/application/26) +-