Implement hybrid key exchange mode#6
● OpenTravis L. Guckert opened this issue on Mar 18, 2026
TG
tguckertopened this issue
The default key exchange should use X25519 + ML-KEM-1024 in hybrid mode as specified by LSS-001 Layer 2.
## Requirements
The hybrid mode must satisfy the following properties:
1. Classical X25519 key agreement executes first
2. Post-quantum ML-KEM-1024 encapsulation executes second
3. Both shared secrets are combined via HKDF-SHA3-256
4. If either algorithm fails, the handshake fails entirely — no silent fallback
5. The CryptoProvider trait must expose a `suite_name()` method returning the active algorithm description
## Acceptance Criteria
- All NIST KAT reference vectors pass
- Constant-time arithmetic verified via Kani
- Zeroization of all intermediate key material
- MTP Receipt generated for every key exchange
- Recorded in the transparency log
## References
- FIPS 203 (ML-KEM)
- LSS-001 Layer 2 (Post-Quantum Cryptography)
- LSS-001 Layer 3 (Cryptographic Agility)
◉
tguckert added the enhancement label
14d ago
◉
tguckert added the pqc label
14d ago
→
tguckert self-assigned this issue
14d ago
AI
Architect AIcommented 14d ago
I have analyzed the CryptoProvider trait in core/src/crypto/provider.rs and confirm the following implementation path:
The HybridProvider struct already combines classical and post-quantum providers. The remaining work is to implement the HKDF-SHA3-256 key combination step and verify constant-time execution via Kani.
Provenance: CTP query against drok/core/src/crypto/provider.rs at commit c9135f2a. MTP Receipt: receipt-arch-001.
TG
Travis L. Guckertcommented 14d ago
Confirmed. The HybridProvider.encapsulate() method needs to execute both key agreements and combine shared secrets via HKDF. The decapsulate() method mirrors this logic.
Priority: this blocks all subsequent key exchange operations across the platform. Targeting completion before the v0.5.0 milestone.
AI
Architect AIcommented 13d ago
Draft implementation prepared. The HKDF combination uses SHA3-256 with a domain separator of "drok-hybrid-kem-v1" to prevent cross-protocol attacks. All intermediate key material is zeroized via the zeroize crate's Zeroize derive macro.
I have verified that the pqcrypto-kyber crate exposes the ML-KEM-1024 encapsulate/decapsulate functions with the correct API surface. The x25519-dalek crate provides StaticSecret and PublicKey types for the classical component.
Provenance: CTP queries against drok/core/src/crypto/ directory. MTP Receipt: receipt-arch-002.
?