From eed6ef582ed9b20e1ca9f5c02de4b89ea153a208 Mon Sep 17 00:00:00 2001 From: Jimmy Debe <91767824+jimstir@users.noreply.github.com> Date: Tue, 30 Jan 2024 01:26:27 -0500 Subject: [PATCH] Delete informational/20 directory --- informational/20/toy-eth-pm.md | 219 --------------------------------- 1 file changed, 219 deletions(-) delete mode 100644 informational/20/toy-eth-pm.md diff --git a/informational/20/toy-eth-pm.md b/informational/20/toy-eth-pm.md deleted file mode 100644 index 80a59b3..0000000 --- a/informational/20/toy-eth-pm.md +++ /dev/null @@ -1,219 +0,0 @@ ---- -slug: 20 -title: 20/TOY-ETH-PM -name: Toy Ethereum Private Message -status: draft -tags: waku/application -editor: Franck Royer -contributors: ---- - -**Content Topics**: - -- Public Key Broadcast: `/eth-pm/1/public-key/proto`, -- Private Message: `/eth-pm/1/private-message/proto`. - -This specification explains the Toy Ethereum Private Message protocol -which enables a peer to send an encrypted message to another peer -using the Waku v2 network, and the peer's Ethereum address. - -The main purpose of this specification is to demonstrate how Waku v2 can be used for encrypted messaging purposes, -using Ethereum accounts for identity. -This protocol caters for Web3 wallets restrictions, allowing it to be implemented only using standard Web3 API. -In the current state, the protocol has privacy and features [limitations](#limitations), has not been audited -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 - -Alice wants to send an encrypted message to Bob, where only Bob can decrypt the message. -Alice only knows Bob's Ethereum Address. - -## Variables - -Here are the variables used in the protocol and their definition: - -- `B` is Bob's Ethereum address (or account), -- `b` is the private key of `B`, and is only known by Bob. -- `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 - -The proposed protocol MUST adhere to the following design requirements: - -1. Alice knows Bob's Ethereum address, -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](../../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. - -## Limitations - -Alice's details are not included in the message's structure, -meaning that there is no programmatic way for Bob to reply to Alice -or verify her identity. - -Private messages are sent on the same content topic for all users. -As the recipient data is encrypted, all participants must decrypt all messages which can lead to scalability issues. - -This protocol does not guarantee Perfect Forward Secrecy nor Future Secrecy: -If Bob's private key is compromised, past and future messages could be decrypted. -A solution combining regular [X3DH](https://www.signal.org/docs/specifications/x3dh/) -bundle broadcast with [Double Ratchet](https://signal.org/docs/specifications/doubleratchet/) encryption would remove these limitations; -See the [Status secure transport spec](https://specs.status.im/spec/5) for an example of a protocol that achieves this in a peer-to-peer setting. - -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 - -### 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 - -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 - -To prove ownership of the Encryption Public Key, -Bob must sign it using [EIP-712](https://eips.ethereum.org/EIPS/eip-712) v3, -meaning calling `eth_signTypedData_v3` on his Wallet's API. - -Note: While v4 also exists, -it is not available on all wallets and the features brought by v4 is not needed for the current use case. - -The `TypedData` to be passed to `eth_signTypedData_v3` MUST be as follows, where: - -- `encryptionPublicKey` is Bob's Encryption Public Key, `B'`, in hex format, **without** `0x` prefix. -- `bobAddress` is Bob's Ethereum address, corresponding to `B`, in hex format, **with** `0x` prefix. - -```js -const typedData = { - domain: { - chainId: 1, - name: 'Ethereum Private Message over Waku', - version: '1', - }, - message: { - encryptionPublicKey: encryptionPublicKey, - ownerAddress: bobAddress, - }, - primaryType: 'PublishEncryptionPublicKey', - types: { - EIP712Domain: [ - { name: 'name', type: 'string' }, - { name: 'version', type: 'string' }, - { name: 'chainId', type: 'uint256' }, - ], - PublishEncryptionPublicKey: [ - { name: 'encryptionPublicKey', type: 'string' }, - { name: 'ownerAddress', type: 'string' }, - ], - }, - } -``` - -### Public Key Message - -The resulting signature is then included in a `PublicKeyMessage`, where - -- `encryption_public_key` is Bob's Encryption Public Key `B'`, not compressed, -- `eth_address` is Bob's Ethereum Address `B`, -- `signature` is the EIP-712 as described above. - -```protobuf -syntax = "proto3"; - -message PublicKeyMessage { - bytes encryption_public_key = 1; - bytes eth_address = 2; - bytes signature = 3; -} -``` - -This MUST be wrapped in a Waku Message version 0, with the Public Key Broadcast content topic. -Finally, Bob SHOULD publish the message on Waku v2. - -## Consideration for a non-interactive/uncoordinated protocol - -Alice has to get Bob's public Key to send a message to Bob. -Because an Ethereum Address is part of the hash of the public key's account, -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](../../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. - -Below we are reviewing possible solutions to mitigate this "sign up" step. - -### Retrieve the public key from the blockchain - -If Bob has signed at least one transaction with his account then his Public Key can be extracted from the transaction's ECDSA signature. -The challenge with this method is that standard Web3 Wallet API does not allow Alice to specifically retrieve all/any transaction sent by Bob. - -Alice would instead need to use the `eth.getBlock` API to retrieve Ethereum blocks one by one. -For each block, she would need to check the `from` value of each transaction until she finds a transaction sent by Bob. - -This process is resource intensive and can be slow when using services such as Infura due to rate limits in place, -which makes it inappropriate for a browser or mobile phone environment. - -An alternative would be to either run a backend that can connect directly to an Ethereum node, -use a centralized blockchain explorer -or use a decentralized indexing service such as [The Graph](https://thegraph.com/). - -Note that these would resolve a UX issue only if a sender wants to proceed with _air drops_. - -Indeed, if Bob does not publish his Public Key in the first place -then it can be an indication that he simply does not participate in this protocol and hence will not receive messages. - -However, these solutions would be helpful if the sender wants to proceed with an _air drop_ of messages: -Send messages over Waku for users to retrieve later, once they decide to participate in this protocol. -Bob may not want to participate first but may decide to participate at a later stage -and would like to access previous messages. -This could make sense in an NFT offer scenario: -Users send offers to any NFT owner, -NFT owner may decide at some point to participate in the protocol and retrieve previous offers. - -### Publishing the public in long term storage - -Another improvement would be for Bob not having to re-publish his public key every 30 days or less. -Similarly to above, if Bob stops publishing his public key then it may be an indication that he does not participate in the protocol anymore. - -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 - -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](../../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](../../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) --