Update ETH-SECPM.md

This commit is contained in:
Jimmy Debe 2024-02-01 23:05:16 -05:00 committed by GitHub
parent 860bae20d9
commit 22bb3312fa
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 15 additions and 15 deletions

View File

@ -9,20 +9,20 @@ editor: Ramses Fernandez <ramses@status.im>
contributors:
---
# Abstract
## Abstract
This document specifies an Ethereum-based private messaging service.
This proposal is built upon this [model](https://rfc.vac.dev/spec/20/) and
This proposal is built upon this [model](../../waku/standards/application/20/toy-eth-pm.md) and
amends the limitations of the latter concerning forward privacy and authentication.
The document is still work in progress.
Next steps will include a description of how to implement the different functions and algorithms in terms of the Noise framework.
# Background
## Background
Alice wants to send an encrypted message to Bob.
Here Bob is the only individual able to decrypt the message.
Alice has access to Bobs Ethereum address.
# Theory and Description of the Protocol
## Theory and Description of the Protocol
The proposed protocol must adhere to the following design requirements:
- Alice knows Bobs Ethereum address.
@ -134,14 +134,14 @@ SHA256 for the KDF and AES256 for AEAD encryption.
Consequently, according to the Noise framework specifications, the X3DH algorithm is encoded as **Noise_IX_448_AES256GCM_SHA256**
# Retrieving information
## Retrieving information
## Static data
### Static data
Some data, such as the key pairs (ik, IK) for Alice and Bob, do not need to be regenerated after a period of time.
Therefore the public keys IK can be stored in long-term storage solutions, such as a dedicated smart contract which outputs such a key pair when receiving an Ethereum wallet address.
## Ephemeral data
### Ephemeral data
Storing ephemeral data on Ethereum can be done using a combination of on-chain and off-chain solutions.
This approach provides an efficient solution to the problem of storing updatable data in Ethereum.
@ -151,7 +151,7 @@ In any case, the user stores the associated IPFS hash, URL or reference in Ether
The fact of a user not updating the ephemeral information can be understood as Bob not willing to participate in any communication.
## Interaction with Ethereum
### Interaction with Ethereum
Storing static data is done using a dedicated smart contract *PublicKeyStorage* which associates the Ethereum wallet address of a user with his public key.
This mapping is done by PublicKeyStorage using a *publicKeys* function, or a *setPublicKey* function.
@ -160,9 +160,9 @@ A user who wants to retrieve a public key associated with a specific wallet addr
The user provides the wallet address as the only input parameter for *getPublicKey*.
The function outputs the associated public key from the smart contract.
# Extension to group chat
## Extension to group chat
## 1-to-1 version
### 1-to-1 version
In order to extend the protocol to a group chat, this document specifies using an Asynchronous Distributed Key Generation (ADKG) to replace the X3DH step in the previous combination X3DH + Double Ratchet.
@ -203,7 +203,7 @@ the communication in this group is 1-to-1,
meaning that group member C cannot see the messages between group members A and B.
The fact of defining a room key makes impossible for outsiders to communicate with group members if the latter are not willing to.
## n-to-n version
### n-to-n version
Using the above approach leads to a situation where a group of users can set a group for 1-to-1 messages,
meaning that any group member external to a communication between any other two members will not be able to read the contents of the messages.
@ -212,20 +212,20 @@ An approach to generalize this situation to the setting of a group of users exch
The proposal suggested provides both forward secrecy and post-compromise security.
The shared key can be then used in any symmetric encryption scheme, such as AES256.
# Privacy and Security Considerations
## Privacy and Security Considerations
- For the information retrieval, the algorithm MUST include a access control mechanisms to restrict who can call the set and get functions.
- One SHOULD include event logs to track changes in public keys.
- The curve X448 MUST be chosen as the elliptic curve, since it offers a higher security level: 224-bit security instead of the 128-bit security provided by X25519.
- Concerning the hardness of the ADKG, the proposal lies on the Discrete Logarithm assumption.
# Copyright
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
# References
## References
- https://rfc.vac.dev/spec/20/
- [model](../../waku/standards/application/20/toy-eth-pm.md)
- https://signal.org/docs/specifications/x3dh/
- https://signal.org/docs/specifications/doubleratchet/
- https://eprint.iacr.org/2022/1389