logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-02 14:13:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

review comments

Browse Source
This commit is contained in:
Jazz Turner-Baggs 2025-10-28 15:12:17 -07:00
parent 8e1e2536a1
commit bfe3f14e12
No known key found for this signature in database
1 changed files with 28 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
standards/application/privatev1.md
View File

@ -9,7 +9,7 @@ contributors:
# Abstract
This specification defines PRIVATE1, a conversation protocol for establishing secure, full-duplex encrypted communication channels between two participants. PRIVATE1 provides end-to-end encryption with forward secrecy and post-compromise security using the DoubleRatchet algorithm, combined with reliable message delivery via Scalable Data Sync (SDS) and efficient segmentation for transport-constrained environments.
This specification defines PRIVATE1, a conversation protocol for establishing secure, full-duplex encrypted communication channels between two participants. PRIVATE1 provides end-to-end encryption with forward secrecy and post-compromise security using the Double Ratchet algorithm, combined with reliable message delivery via Scalable Data Sync (SDS) and efficient segmentation for transport-constrained environments.
The protocol is transport-agnostic and designed to support both direct messaging and as a foundation for group communication systems. PRIVATE1 ensures payload confidentiality, content integrity, sender privacy, and message reliability while remaining resilient to network disruptions and message reordering.
@ -24,7 +24,7 @@ However, being encrypted is merely the starting point, not the complete solution
# Private V1
PrivateV1 is a conversation type specification that establishes a full-duplex secure communication channel between two participants. It combines the Double Ratchet algorithm for encryption with Scalable Data Sync (SDS) for reliable delivery and an efficient segmentation strategy to handle transport constraints.
PRIVATE1 is a conversation type specification that establishes a full-duplex secure communication channel between two participants. It combines the Double Ratchet algorithm for encryption with Scalable Data Sync (SDS) for reliable delivery and an efficient segmentation strategy to handle transport constraints.
PRIVATE1 provides the following properties:
@ -56,7 +56,7 @@ It also assumes that some other component is responsible for delivering the gene
```mermaid
flowchart LR
Content:::plain--> Privatev1 --> Payload:::plain
Content:::plain--> PrivateV1 --> Payload:::plain
classDef plain fill:none,stroke:transparent;
```
### Content
@ -68,9 +68,9 @@ Applications provide content as encoded bytes, which is then packaged into paylo
Content MUST be smaller than `255 * max_seg_size`
due to segmentation protocol limitations.
**Agnostic**
**Structure**
The protocol treats the contents as a arbitrary sequence of bytes and is agnostic to its contents.
The protocol treats the contents as an arbitrary sequence of bytes and is agnostic to its contents.
### Payload Delivery
How payloads are sent and received by clients is deliberately not specified by this protocol.
@ -81,7 +81,7 @@ Confidentiality, integrity, and forward secrecy are provided regardless of how p
However, transport choice may affect other properties and characteristics.
**Recipient Privacy:**
The routing/addressing layer may leak sensitive metadata including the recipients identity. The payloads generated by this protocol do not reveal the participants of a conversation, however the overall privacy properties are determined by the delivery mechanism used to transport payloads.
The routing/addressing layer may leak sensitive metadata including the recipient's identity. The payloads generated by this protocol do not reveal the participants of a conversation, however the overall privacy properties are determined by the delivery mechanism used to transport payloads.
**Reliability Performance**
While PRIVATE1 handles message losses, more reliable transports reduce retransmission overhead.
@ -106,7 +106,7 @@ PRIVATE1 requires a unique identifier, however the exact derivation is left to i
Additionally implementations MUST determine the following constants:
- `max_seg_size` - maximum segmentation size to be used.
- `max_skip` - number of keys which can be skipped per session. Values are determined by
- `max_skip` - number of keys which can be skipped per session.
## Value Derivations
@ -196,7 +196,7 @@ The following mappings connect PRIVATE1 concepts to SDS fields:
- `channel_id`: uses the `conversation_id` parameter.
**Sender Validation**
SDS uses a `sender_id` payload field to determine whether a message was sent by the remote party. This value is sender reported and not validated which can have unknown implications if trusted in other contexts. For security hygiene Clients SHOULD drop SDS messages if `sender_id` != the sender derived from the encryption layer. !TODO: PrivateV1 is not sender aware currently
SDS uses a `sender_id` payload field to determine whether a message was sent by the remote party. This value is sender reported and not validated which can have unknown implications if trusted in other contexts. For security hygiene Clients SHOULD drop SDS messages if `sender_id` != the sender derived from the encryption layer. !TODO: PRIVATE1 is not sender aware currently
**Bloom Filter Configuration**
@ -291,7 +291,7 @@ flowchart TD
### Encrypted Payload
```protobuf
message Doubleratchet {
message DoubleRatchet {
bytes dh = 1; // 32 byte publickey
uint32 msgNum = 2;
uint32 prevChainLen = 3;
@ -322,7 +322,7 @@ message Message {
}
```
**content:** This field is an protobuf encoded `Segment`
**content:** This field is a protobuf encoded `Segment`
### Segmentation
@ -345,7 +345,7 @@ message SegmentMessageProto {
!TODO: This should be encoded as a FrameType so it can be optional.
### Frame
### PrivateV1Frame
```protobuf
message PrivateV1Frame {
@ -377,7 +377,7 @@ This means that senders SHOULD generate a new ephemeral key for `ssk` for every
### Excessive Skipped Message
Handling of skipped message keys is not strictly defined in double ratchet.
Implementations need to choose an strategy which works best for their environment, and delivery mechanism.
Implementations need to choose a strategy which works best for their environment, and delivery mechanism.
Halting operation of the channel is the safest, as it bounds resource utilization in the event of a DOS attack but is not always possible.
If eventual delivery of messages is not guaranteed, implementors should regularly delete keys that are older than a given time window.
@ -385,7 +385,7 @@ Unreliable delivery mechanisms will result in increased key storage over time, a
## Security/Privacy Considerations
### Sender Deniability and Authentication**
### Sender Deniability and Authentication
Encrypted messages do not have a cryptographically provable sender to third parties due to the deniability property of the Double Ratchet algorithm.
However, participants in a conversation can authenticate each other through the shared cryptographic state.
@ -400,3 +400,18 @@ Without proper authentication during initialization, an adversary could perform
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
## References
- **[DOUBLERATCHET]** "The Double Ratchet Algorithm", Signal, 2016.
https://signal.org/docs/specifications/doubleratchet/
- **[SDS]** "Scalable Data Sync Specification", vac, 2024.
https://github.com/vacp2p/rfc-index/blob/main/vac/raw/sds.md
- **[SEGMENTATION]** "Message Segmentation Specification", Waku, 2024.
https://github.com/waku-org/specs/blob/main/standards/application/segmentation.md
- **[CONTENTFRAME]** "ContentFrame Specification", Waku, 2024.
https://github.com/waku-org/specs/blob/main/standards/application/contentframe.md
- **[CHAT-DEFINITIONS]** "Chat Definitions Specification", Waku, 2024.
https://github.com/waku-org/specs/blob/main/informational/chatdefs.md