chore: rename quicproquo → quicprochat in docs, Docker, CI, and packaging
Rename all project references from quicproquo/qpq to quicprochat/qpc across documentation, Docker configuration, CI workflows, packaging scripts, operational configs, and build tooling. - Docker: crate paths, binary names, user/group, data dirs, env vars - CI: workflow crate references, binary names, artifact names - Docs: all markdown files under docs/, SDK READMEs, book.toml - Packaging: OpenWrt Makefile, init script, UCI config (file renames) - Scripts: justfile, dev-shell, screenshot, cross-compile, ai_team - Operations: Prometheus config, alert rules, Grafana dashboard - Config: .env.example (QPQ_* → QPC_*), CODEOWNERS paths - Top-level: README, CONTRIBUTING, ROADMAP, CLAUDE.md
This commit is contained in:
@@ -1,8 +1,8 @@
|
||||
# Hybrid KEM: X25519 + ML-KEM-768
|
||||
|
||||
quicproquo implements a hybrid Key Encapsulation Mechanism that combines classical X25519 Diffie-Hellman with post-quantum ML-KEM-768 (FIPS 203). The hybrid construction ensures that the system remains secure even if one of the two components is broken: X25519 protects against failures in ML-KEM, and ML-KEM protects against quantum computers breaking X25519.
|
||||
quicprochat implements a hybrid Key Encapsulation Mechanism that combines classical X25519 Diffie-Hellman with post-quantum ML-KEM-768 (FIPS 203). The hybrid construction ensures that the system remains secure even if one of the two components is broken: X25519 protects against failures in ML-KEM, and ML-KEM protects against quantum computers breaking X25519.
|
||||
|
||||
The implementation lives in `quicproquo-core/src/hybrid_kem.rs`. It is fully implemented and tested but **not yet integrated into the MLS ciphersuite** -- integration is planned for the M5 milestone. Currently, the module can be used as a standalone envelope encryption layer to wrap MLS payloads in an outer post-quantum-resistant encryption before they transit the network.
|
||||
The implementation lives in `quicprochat-core/src/hybrid_kem.rs`. It is fully implemented and tested but **not yet integrated into the MLS ciphersuite** -- integration is planned for the M5 milestone. Currently, the module can be used as a standalone envelope encryption layer to wrap MLS payloads in an outer post-quantum-resistant encryption before they transit the network.
|
||||
|
||||
## Design approach
|
||||
|
||||
@@ -70,8 +70,8 @@ The two shared secrets are combined via HKDF-SHA256 with domain separation:
|
||||
ikm = X25519_shared_secret(32 bytes) || ML-KEM_shared_secret(32 bytes)
|
||||
salt = [] (empty)
|
||||
|
||||
key = HKDF-SHA256(salt, ikm, info="quicproquo-hybrid-v1", L=32)
|
||||
nonce = HKDF-SHA256(salt, ikm, info="quicproquo-hybrid-nonce-v1", L=12)
|
||||
key = HKDF-SHA256(salt, ikm, info="quicprochat-hybrid-v1", L=32)
|
||||
nonce = HKDF-SHA256(salt, ikm, info="quicprochat-hybrid-nonce-v1", L=12)
|
||||
```
|
||||
|
||||
The implementation in `derive_aead_material()`:
|
||||
@@ -85,10 +85,10 @@ fn derive_aead_material(x25519_ss: &[u8], mlkem_ss: &[u8]) -> (Key, Nonce) {
|
||||
let hk = Hkdf::<Sha256>::new(None, &ikm);
|
||||
|
||||
let mut key_bytes = Zeroizing::new([0u8; 32]);
|
||||
hk.expand(b"quicproquo-hybrid-v1", &mut *key_bytes).unwrap();
|
||||
hk.expand(b"quicprochat-hybrid-v1", &mut *key_bytes).unwrap();
|
||||
|
||||
let mut nonce_bytes = [0u8; 12];
|
||||
hk.expand(b"quicproquo-hybrid-nonce-v1", &mut nonce_bytes).unwrap();
|
||||
hk.expand(b"quicprochat-hybrid-nonce-v1", &mut nonce_bytes).unwrap();
|
||||
|
||||
(*Key::from_slice(&*key_bytes), *Nonce::from_slice(&nonce_bytes))
|
||||
}
|
||||
@@ -273,7 +273,7 @@ The AEAD nonce is derived deterministically from the shared secrets via HKDF. Si
|
||||
|
||||
## Further reading
|
||||
|
||||
- [Post-Quantum Readiness](../cryptography/post-quantum-readiness.md) -- Broader discussion of quicproquo's PQ strategy.
|
||||
- [Post-Quantum Readiness](../cryptography/post-quantum-readiness.md) -- Broader discussion of quicprochat's PQ strategy.
|
||||
- [MLS (RFC 9420)](mls.md) -- The MLS layer that the hybrid KEM will wrap.
|
||||
- [Key Lifecycle and Zeroization](../cryptography/key-lifecycle.md) -- How hybrid key material is managed and cleared.
|
||||
- [Threat Model](../cryptography/threat-model.md) -- Where hybrid KEM fits in the overall threat model.
|
||||
|
||||
Reference in New Issue
Block a user