HSM / PKCS#11 / Hybrid KEM + ECDH
What you will do: Execute six steps in order: Alice and Bob X25519 keypairs, ECDH in both directions, an ML-KEM-768 keypair, encapsulation, then decapsulate and HKDF-combine both secrets into one 32-byte session key.
Worked example: Step 3 prints both ECDH secrets and confirms they match; Step 5 shows the 1088-byte ciphertext; Step 6 lists the HKDF inputs (ECDH secret, ML-KEM secret, info string) and the final 32-byte hybrid key.
Runtime and privacy: The cryptographic exercise runs in this browser. Review the site privacy terms before entering sensitive material; use synthetic inputs for learning and evaluation.
Browse all Crypto Lab tools · Learn with Hybrid Cryptography
For your role
- Developer / Engineer
- Walk the six steps from Generate Alice Keypair to the HKDF-SHA-256 combiner: each step's Field / Value / Description table names the PKCS#11 mechanism your code calls for X25519, ML-KEM-768 encapsulation and the final 32-byte session key.
- Security Architect
- The combiner is the design point: both the X25519 and the ML-KEM-768 secrets feed HKDF, so the session key stays secure if either component survives, and the step tables show the size each component adds to the exchange.
- Researcher / Academic
- Follow the mechanism and key-handle columns through the six steps to reproduce the exchange outside the browser; the PKCS#11 call log records every call with its return code.
Live HSM Mode Active
SoftHSM3 · PKCS#11 v3.2 · Rust · session open
Hybrid Key Establishment (X25519 + ML-KEM-768)
Live PKCS#11 demo: X25519 ECDH + ML-KEM-768 encapsulation + HKDF-SHA-256 combiner. Both secrets contribute to the 32-byte hybrid session key — quantum-safe if either component remains secure (FIPS 203 · RFC 5869).
Step 1 — Alice X25519 Keypair
Alice generates an ephemeral X25519 (Curve25519) keypair. The 32-byte public key will be shared with Bob for ECDH key agreement.
PKCS#11 v3.2 mechanism for Curve25519/Curve448 keypair generation
Montgomery-form elliptic curve; public key is the 32-byte u-coordinate
Key is authorized for CKM_ECDH1_DERIVE — required for ECDH key agreement
Compact vs 65 bytes for an uncompressed P-256 public key
| Field | Value | Description |
|---|---|---|
| Mechanism | CKM_EC_MONTGOMERY_KEY_PAIR_GEN (0x1056) | PKCS#11 v3.2 mechanism for Curve25519/Curve448 keypair generation |
| Curve | X25519 (Curve25519) | Montgomery-form elliptic curve; public key is the 32-byte u-coordinate |
| CKA_DERIVE | true | Key is authorized for CKM_ECDH1_DERIVE — required for ECDH key agreement |
| Public Key Size | 32 bytes | Compact vs 65 bytes for an uncompressed P-256 public key |
Enable the HSM toggle and execute steps to see PKCS#11 traces.
Why combine ECDH and ML-KEM?
A Key Encapsulation Mechanism (KEM) is a one-sided primitive: the sender encapsulates a random shared secret for the receiver. Unlike ECDH, the sender cannot inject a chosen value.
Combining X25519 ECDH with ML-KEM-768 via HKDF provides defense-in-depth:
- If a cryptographically-relevant quantum computer (CRQC) breaks X25519 via Shor's algorithm, the ML-KEM shared secret remains secret.
- If ML-KEM-768 has an unforeseen algebraic weakness, the X25519 shared secret remains secret.
Note: softhsmv3 WASM uses X25519 (Montgomery) for the classical leg via CKM_EC_MONTGOMERY_KEY_PAIR_GEN + CKM_ECDH1_DERIVE. This demo is for educational use only — keys generated here must not be used in production systems.
Try it
In the six steps, where do the X25519 secret and the ML-KEM-768 secret meet?
Next step
Turn it into a plan: Hybrid Transition PlannerThis tool practises the Hybrid Cryptography module, phase 5 (Pilots & Migration); Hybrid Transition Planner produces a deliverable of that phase.
Related content
Next in HSM / PKCS#11