mirror of https://github.com/vacp2p/rfc-index.git
Update toy-eth-pm.md
This commit is contained in:
Jimmy Debe
GitHub
parent
a16a2b474d
commit
8841f4941e
|
|
@ -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 <franck@status.im>
|
||||
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)
|
||||
-
|
||||
|
|
|
|||
Loading…
Reference in New Issue