Implement hybrid key exchange mode#1

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.
?