feat: add post-quantum hybrid KEM + SQLCipher persistence
Feature 1 — Post-Quantum Hybrid KEM (X25519 + ML-KEM-768): - Create hybrid_kem.rs with keygen, encrypt, decrypt + 11 unit tests - Wire format: version(1) | x25519_eph_pk(32) | mlkem_ct(1088) | nonce(12) | ct - Add uploadHybridKey/fetchHybridKey RPCs to node.capnp schema - Server: hybrid key storage in FileBackedStore + RPC handlers - Client: hybrid keypair in StoredState, auto-wrap/unwrap in send/recv/invite/join - demo-group runs full hybrid PQ envelope round-trip Feature 2 — SQLCipher Persistence: - Extract Store trait from FileBackedStore API - Create SqlStore (rusqlite + bundled-sqlcipher) with encrypted-at-rest SQLite - Schema: key_packages, deliveries, hybrid_keys tables with indexes - Server CLI: --store-backend=sql, --db-path, --db-key flags - 5 unit tests for SqlStore (FIFO, round-trip, upsert, channel isolation) Also includes: client lib.rs refactor, auth config, TOML config file support, mdBook documentation, and various cleanups by user. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
87
docs/src/protocol-layers/overview.md
Normal file
87
docs/src/protocol-layers/overview.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# Protocol Layers Overview
|
||||
|
||||
quicnprotochat composes five distinct protocol layers into a single security stack. Each layer addresses a specific class of threat and delegates everything else to the layers above or below it. No single layer is sufficient on its own; the composition is what delivers end-to-end confidentiality, mutual authentication, forward secrecy, post-compromise security, and post-quantum resistance.
|
||||
|
||||
This page provides a high-level comparison and a suggested reading order. The deep-dive pages that follow contain implementation details drawn directly from the source code.
|
||||
|
||||
## Layer comparison
|
||||
|
||||
| Layer | Standard / Spec | Crate(s) | Security Properties |
|
||||
|---|---|---|---|
|
||||
| **QUIC + TLS 1.3** | RFC 9000, RFC 9001 | `quinn 0.11`, `rustls 0.23` | Transport confidentiality, server authentication, 0-RTT resumption |
|
||||
| **Noise\_XX** | [Noise Protocol Framework](https://noiseprotocol.org/noise.html) | `snow 0.9` | Mutual authentication, identity hiding, ChaCha20-Poly1305 session encryption |
|
||||
| **Cap'n Proto** | [capnproto.org specification](https://capnproto.org/encoding.html) | `capnp 0.19`, `capnp-rpc 0.19` | Zero-copy deserialisation, schema-enforced types, canonical serialisation for signing, async RPC |
|
||||
| **MLS** | [RFC 9420](https://www.rfc-editor.org/rfc/rfc9420.html) | `openmls 0.5` | Group key agreement, forward secrecy, post-compromise security (PCS) |
|
||||
| **Hybrid KEM** | [draft-ietf-tls-hybrid-design](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/) | `ml-kem 0.2`, `x25519-dalek 2` | Post-quantum resistance via ML-KEM-768 combined with X25519 |
|
||||
|
||||
## How the layers compose
|
||||
|
||||
Data flows through the stack from top to bottom on send and from bottom to top on receive:
|
||||
|
||||
```text
|
||||
Application plaintext
|
||||
|
|
||||
v
|
||||
+-----------+
|
||||
| MLS | RFC 9420 group encryption (PrivateMessage)
|
||||
+-----------+
|
||||
|
|
||||
v
|
||||
+-----------+
|
||||
| Cap'n Proto| Schema-typed serialisation into Envelope frames
|
||||
+-----------+
|
||||
|
|
||||
v
|
||||
+-----------+
|
||||
| Noise_XX | Per-session ChaCha20-Poly1305 encryption (M1 TCP path)
|
||||
+-----------+ -- OR --
|
||||
+-----------+
|
||||
| QUIC+TLS | QUIC transport encryption (M3+ QUIC path)
|
||||
+-----------+
|
||||
|
|
||||
v
|
||||
Network
|
||||
```
|
||||
|
||||
In the current M3 architecture, the QUIC + TLS 1.3 layer has replaced the Noise\_XX layer for client-to-server transport. The Noise\_XX implementation remains in the codebase and is used for direct peer-to-peer connections in M1-era integration tests. Both paths carry Cap'n Proto messages as their inner payload.
|
||||
|
||||
The Hybrid KEM layer operates orthogonally: it wraps MLS payloads in an outer post-quantum encryption envelope before they enter the transport layer. It is implemented and tested but not yet integrated into the MLS ciphersuite (planned for the M5 milestone).
|
||||
|
||||
## Suggested reading order
|
||||
|
||||
The pages in this section are ordered to build understanding incrementally:
|
||||
|
||||
1. **[QUIC + TLS 1.3](quic-tls.md)** -- Start here. This is the outermost transport layer that every client-server connection uses today. Understanding QUIC stream multiplexing and the TLS 1.3 handshake is prerequisite to understanding how Cap'n Proto RPC rides on top.
|
||||
|
||||
2. **[MLS (RFC 9420)](mls.md)** -- The core cryptographic innovation. MLS provides the group key agreement that makes quicnprotochat an E2E encrypted group messenger rather than just a transport-encrypted relay. This is the longest and most detailed page.
|
||||
|
||||
3. **[Cap'n Proto Serialisation and RPC](capn-proto.md)** -- The serialisation and RPC layer that bridges MLS application data with the transport. Understanding the Envelope schema, the ParsedEnvelope owned type, and the NodeService RPC interface is essential for reading the server and client source code.
|
||||
|
||||
4. **[Noise\_XX Handshake](noise-xx.md)** -- The M1-era transport encryption layer. Even though QUIC has replaced it for client-server communication, the Noise\_XX code remains in the codebase and the design decisions it embodies (mutual authentication, identity hiding) inform the overall architecture.
|
||||
|
||||
5. **[Hybrid KEM: X25519 + ML-KEM-768](hybrid-kem.md)** -- The post-quantum encryption layer. Read this last because it builds on concepts from all other layers: key encapsulation (from MLS), wire format conventions (from Cap'n Proto), and AEAD encryption (from Noise).
|
||||
|
||||
## Cross-cutting concerns
|
||||
|
||||
Several topics span multiple layers and have their own dedicated pages elsewhere in this book:
|
||||
|
||||
- **Forward secrecy**: Provided by MLS epoch ratcheting. See [Forward Secrecy](../cryptography/forward-secrecy.md).
|
||||
- **Post-compromise security**: Provided by MLS Update proposals. See [Post-Compromise Security](../cryptography/post-compromise-security.md).
|
||||
- **Post-quantum readiness**: Currently provided by the standalone Hybrid KEM module; integration into MLS is planned for M5. See [Post-Quantum Readiness](../cryptography/post-quantum-readiness.md).
|
||||
- **Key lifecycle and zeroization**: Private key material is zeroized after use across all layers. See [Key Lifecycle and Zeroization](../cryptography/key-lifecycle.md).
|
||||
- **Wire format details**: The length-prefixed framing codec and Cap'n Proto schema definitions are documented in the [Wire Format Reference](../wire-format/overview.md) section.
|
||||
- **Design rationale**: The ADR pages explain *why* each layer was chosen. See [Design Decisions Overview](../design-rationale/overview.md).
|
||||
|
||||
## Crate mapping
|
||||
|
||||
Each protocol layer maps to one or more workspace crates:
|
||||
|
||||
| Layer | Primary Crate | Source File(s) |
|
||||
|---|---|---|
|
||||
| QUIC + TLS 1.3 | `quicnprotochat-server`, `quicnprotochat-client` | `main.rs` (server and client entry points) |
|
||||
| Noise\_XX | `quicnprotochat-core` | `src/noise.rs`, `src/codec.rs` |
|
||||
| Cap'n Proto | `quicnprotochat-proto` | `src/lib.rs`, `build.rs`, `schemas/*.capnp` |
|
||||
| MLS | `quicnprotochat-core` | `src/group.rs`, `src/keystore.rs` |
|
||||
| Hybrid KEM | `quicnprotochat-core` | `src/hybrid_kem.rs` |
|
||||
|
||||
For a full crate responsibility breakdown, see [Crate Responsibilities](../architecture/crate-responsibilities.md).
|
||||
Reference in New Issue
Block a user