AtHeartEngineer/rfc-index
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc-index.git synced 2026-01-07 23:04:09 -05:00
Code Issues Packages Projects Releases Wiki Activity

Update and rename README.md to X3DH.md

Browse Source
This commit is contained in:
Jimmy Debe
2024-01-31 23:07:14 -05:00
committed by GitHub
parent 33cf551676
commit 9fd32660a0
1 changed files with 33 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
waku/standards/application/53/README.md → waku/standards/application/53/X3DH.md
View File

@@ -14,20 +14,20 @@ contributors:
- Dean Eigenmann <dean@status.im>
---
# Abstract
## Abstract
This document describes a method that can be used to provide a secure channel between two peers, and thus provide confidentiality, integrity, authenticity and forward secrecy.
It is transport-agnostic and works over asynchronous networks.
It builds on the [X3DH](https://signal.org/docs/specifications/x3dh/) and [Double Ratchet](https://signal.org/docs/specifications/doubleratchet/) specifications, with some adaptations to operate in a decentralized environment.
# Motivation
## Motivation
Nodes on a network may want to communicate with each other in a secure manner, without other nodes network being able to read their messages.
# Specification
## Specification
## Definitions
### Definitions
- **Perfect Forward Secrecy** is a feature of specific key-agreement protocols which provide assurances that session keys will not be compromised even if the private keys of the participants are compromised.
Specifically, past messages cannot be decrypted by a third-party who manages to get a hold of a private key.
@@ -35,7 +35,7 @@ Specifically, past messages cannot be decrypted by a third-party who manages to
- **Secret channel** describes a communication channel where a Double Ratchet algorithm is in use.
## Design Requirements
### Design Requirements
- **Confidentiality**: The adversary should not be able to learn what data is being exchanged between two Status clients.
- **Authenticity**: The adversary should not be able to cause either endpoint to accept data from any third party as though it came from the other endpoint.
@@ -44,21 +44,21 @@ Specifically, past messages cannot be decrypted by a third-party who manages to
All of these properties are ensured by the use of [Signal's Double Ratchet](https://signal.org/docs/specifications/doubleratchet/)
## Conventions
### Conventions
Types used in this specification are defined using the [Protobuf](https://developers.google.com/protocol-buffers/) wire format.
# Specification
## Specification
## End-to-End Encryption
### End-to-End Encryption
End-to-end encryption (E2EE) takes place between two clients.
The main cryptographic protocol is a Double Ratchet protocol, which is derived from the [Off-the-Record protocol](https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html), using a different ratchet.
[The Waku v2 protocol](/spec/10/) subsequently encrypts the message payload, using symmetric key encryption.
[The Waku v2 protocol](../../standards/core/10/waku2.md) subsequently encrypts the message payload, using symmetric key encryption.
Furthermore, the concept of prekeys (through the use of [X3DH](https://signal.org/docs/specifications/x3dh/)) is used to allow the protocol to operate in an asynchronous environment.
It is not necessary for two parties to be online at the same time to initiate an encrypted conversation.
## Cryptographic Protocols
### Cryptographic Protocols
This protocol uses the following cryptographic primitives:
- X3DH
@@ -73,7 +73,7 @@ This protocol uses the following cryptographic primitives:
The node achieves key derivation using [HKDF](https://www.rfc-editor.org/rfc/rfc5869).
## Pre-keys
### Pre-keys
Every client SHOULD initially generate some key material which is stored locally:
- Identity keypair based on secp256k1 - `IK`
@@ -96,7 +96,7 @@ Waku SHOULD be used for retrieving prekey bundles.
Since bundles stored in QR codes or ENS records cannot be updated to delete already used keys, the bundle MAY be rotated every 24 hours, and distributed via Waku.
## Flow
### Flow
The key exchange can be summarized as follows:
@@ -108,7 +108,7 @@ The key exchange can be summarized as follows:
4. Message key derivation: The two parties derive a new message key from their chain key, and use it to encrypt a message.
### 1. Initial key exchange flow (X3DH)
#### 1. Initial key exchange flow (X3DH)
[Section 3 of the X3DH protocol](https://signal.org/docs/specifications/x3dh/#sending-the-initial-message) describes the initial key exchange flow, with some additional context:
- The peers' identity keys `IK_A` and `IK_B` correspond to their public keys;
@@ -148,7 +148,7 @@ The `signature` is generated by sorting `installation-id` in lexicographical ord
`installation-id-1signed-pre-key1version1installation-id2signed-pre-key2-version-2`
### 2. Double Ratchet
#### 2. Double Ratchet
Having established the initial shared secret `SK` through X3DH, it SHOULD be used to seed a Double Ratchet exchange between Alice and Bob.
@@ -216,36 +216,43 @@ Where:
}
```
### 3. Chain key update
#### 3. Chain key update
The chain key MUST be updated according to the `DR_Header` received in the `EncryptedMessageProtocol` message, described in [2.Double Ratchet](#2-double-ratchet).
### 4. Message key derivation
#### 4. Message key derivation
The message key MUST be derived from a single ratchet step in the symmetric-key ratchet as described in [Symmetric key ratchet](https://signal.org/docs/specifications/doubleratchet/#symmetric-key-ratchet)
The message key MUST be used to encrypt the next message to be sent.
# Security Considerations
## Security Considerations
1. Inherits the security considerations of [X3DH](https://signal.org/docs/specifications/x3dh/#security-considerations) and [Double Ratchet](https://signal.org/docs/specifications/doubleratchet/#security-considerations).
2. Inherits the security considerations of the [Waku v2 protocol](/spec/10/).
2. Inherits the security considerations of the [Waku v2 protocol](../../standards/core/10/waku2.md).
3. The protocol is designed to be used in a decentralized manner, however, it is possible to use a centralized server to serve prekey bundles. In this case, the server is trusted.
# Privacy Considerations
## Privacy Considerations
1. This protocol does not provide message unlinkability. It is possible to link messages signed by the same keypair.
# Copyright
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
# References
## References
1. [5/SECURE-TRANSPORT](https://specs.status.im/spec/5)
2. [10/WAKU2](/spec/10/)
3. [X3DH](https://signal.org/docs/specifications/x3dh/)
4. [HKDF](https://www.rfc-editor.org/rfc/rfc5869)
4. [Double Ratchet](https://signal.org/docs/specifications/doubleratchet/)
- [X3DH](https://signal.org/docs/specifications/x3dh/)
- [Double Ratchet](https://signal.org/docs/specifications/doubleratchet/)
- [Signal's Double Ratchet](https://signal.org/docs/specifications/doubleratchet/)
- [Protobuf](https://developers.google.com/protocol-buffers/)
- [Off-the-Record protocol](https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html)
- [The Waku v2 protocol](../../standards/core/10/waku2.md)
- [HKDF](https://www.rfc-editor.org/rfc/rfc5869)
- [2/ACCOUNT](https://specs.status.im/spec/2#x3dh-prekey-bundles)
- [reference wire format](https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L12)
- [Symmetric key ratchet](https://signal.org/docs/specifications/doubleratchet/#symmetric-key-ratchet)
-
-