- A new post-quantum protocol enhances ML-KEM with bidirectional authentication, combining PQC-based DSA and KEM public keys into a single dual-usage certificate
- Three certificate schemes — composite, catalyst, and chameleon — offer distinct tradeoffs between message size and computation time for latency-sensitive applications
- Organizations running real-time messaging or any key-exchange-dependent infrastructure should begin evaluating dual-usage certificate architectures now, before NIST compliance deadlines tighten
Why One-Way Authentication Leaves You Exposed
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), standardized as NIST FIPS 203, handles one job well: encapsulating a shared secret so two parties can establish an encrypted channel. What it does not do natively is prove that both sides of that channel are who they claim to be.
That gap matters. Every enterprise instant messaging platform, every internal API gateway, every microservice handshake that relies on key exchange without mutual authentication creates an opening for machine-in-the-middle attacks. Classical TLS solved this with RSA or ECDSA certificate chains — but those algorithms face a hard expiration date as cryptographically relevant quantum computers advance from theoretical to operational.
The real risk is not the quantum computer itself. The risk is that your PKI migration plan assumes you can swap algorithms one-for-one. You cannot. PQC key exchange and PQC digital signatures have fundamentally different performance profiles — larger keys, larger signatures, different computation costs. Treating them as drop-in replacements for RSA and ECDH will break latency budgets in real-time applications.
A research team addressed this head-on in a recent arXiv preprint (2604.08612), proposing a PQC-based bidirectional authentication key exchange protocol that packages both signature and encapsulation capabilities into a single credential.
How Dual-Usage Certificates Work
Definition: A dual-usage certificate is a single X.509-style credential that binds both a PQC-based Digital Signature Algorithm (DSA) public key and a PQC-based Key Encapsulation Mechanism (KEM) public key to the same identity. This eliminates the need for separate certificates for authentication and encryption — reducing certificate management overhead and cutting the number of credentials an organization must issue, rotate, and revoke.
The protocol described in arXiv:2604.08612 enhances ML-KEM’s key exchange by wrapping it in a bidirectional authentication layer. Both parties prove their identity through PQC digital signatures while simultaneously negotiating a shared secret through PQC key encapsulation — all within a single protocol flow.
“This study aims to enhance the bidirectional authentication capability of ML-KEM by proposing the post-quantum cryptography-based bidirectional authentication key exchange protocol.” — arXiv:2604.08612v1
The mechanism works in three stages:
- Identity assertion: Each party presents a dual-usage certificate containing both their DSA and KEM public keys
- Mutual verification: Each party verifies the other’s DSA signature against the certificate, confirming identity
- Key encapsulation: The KEM public key from the verified certificate is used to encapsulate a shared secret, completing the authenticated key exchange
This collapses what would traditionally require two separate certificate lookups and two distinct cryptographic operations into a unified flow.
[IMAGE: A split X.509 certificate glowing with two distinct quantum-entangled key pairs — one for digital signatures, one for key encapsulation — merging into a single credential against a dark lattice-structure background]
Three Certificate Schemes Compared
The research introduces three distinct approaches to constructing dual-usage certificates, each with architectural implications for PKI infrastructure:
| Scheme | Architecture | DSA + KEM Integration | Certificate Size Impact | Best Fit |
|---|---|---|---|---|
| Composite | Both PQC-DSA and PQC-KEM keys embedded as a single composite key structure | Tightly coupled — keys generated and managed together | Largest certificate size; single credential contains all material | Organizations wanting simplest certificate management with tolerance for larger payloads |
| Catalyst | PQC-KEM key derived or catalyzed from the PQC-DSA key | Mathematically linked — KEM key depends on DSA key | Moderate size; derivation reduces redundant key material | Environments prioritizing compact certificates where key generation latency is acceptable |
| Chameleon | PQC-KEM key embedded within the certificate extension fields, independent of DSA key | Loosely coupled — keys are independent but co-located | Flexible size; modular design allows selective updates | Hybrid migration scenarios where KEM and DSA algorithms may be updated independently |
Each scheme was validated for key exchange message lengths and computation times, though the preprint abstract does not disclose specific numeric benchmarks — a gap that subsequent peer-reviewed publications will need to fill before enterprises can make definitive architectural choices.
What the Research Does Not Tell You
Several critical details remain unspecified in the preprint abstract, and security architects should note these gaps before drawing implementation conclusions:
- Which DSA algorithm? The paper does not specify whether it uses ML-DSA (Dilithium), SLH-DSA (SPHINCS+), or FN-DSA (Falcon). Each has dramatically different signature sizes and verification speeds. ML-DSA-65 signatures run approximately 3,300 bytes; SLH-DSA-128s signatures exceed 7,800 bytes. This choice alone could determine whether the protocol fits within existing TLS handshake budgets.
- Which ML-KEM parameter set? ML-KEM-512, ML-KEM-768, and ML-KEM-1024 offer different security levels (roughly equivalent to AES-128, AES-192, and AES-256). The performance and bandwidth implications vary significantly — ML-KEM-768 ciphertexts are 1,088 bytes versus 1,568 bytes for ML-KEM-1024.
- No TLS 1.3 interoperability testing. The preprint demonstrates the protocol through an instant messaging application but does not address integration with existing transport protocols.
- No comparison against classical baselines. Without RSA/ECDH benchmarks as a reference point, it is difficult to quantify the migration overhead.
- Preprint status only. This paper has not undergone formal peer review. Treat findings as directional, not definitive.
Security architects should track this research closely but should not use it as the sole basis for procurement or migration decisions until benchmark data and peer review are available.
Industry Context: The PKI Migration Problem Nobody Wants to Talk About
The dual-usage certificate concept arrives at a critical moment. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in 2024, giving organizations standardized algorithms to target. But standardizing algorithms is the easy part. The hard part is rearchitecting PKI infrastructure to handle them.
Consider the certificate lifecycle problem. Today, most enterprises manage separate certificate types for TLS server authentication, client authentication, code signing, and email encryption. Adding PQC variants of each — potentially with different algorithms for signatures and key exchange — multiplies the number of certificate types an organization must manage.
Dual-usage certificates directly attack this complexity. By combining authentication and encryption capabilities in a single credential, they reduce the certificate sprawl that makes PQC migration feel overwhelming. For organizations running hundreds of thousands of certificates across microservice architectures, this is not an incremental improvement — it is a fundamentally different migration path.
The instant messaging use case demonstrated in the paper is strategically chosen. Messaging platforms demand low latency, frequent key renegotiation, and bidirectional trust — precisely the conditions where PQC overhead is most painful and where dual-usage certificates offer the greatest operational simplification.
The BeQuantum Perspective
BeQuantum’s Digital Notary infrastructure already addresses the authentication half of this equation — cryptographically binding identities to content and transactions using post-quantum signatures. The dual-usage certificate concept aligns with the architectural direction our PQC Layer has taken: treating authentication and encryption as inseparable components of a single trust assertion rather than bolting them together from separate systems.
The three certificate schemes identified — composite, catalyst, and chameleon — map to real deployment patterns we observe across enterprise customers. Organizations with centralized PKI tend toward composite schemes for simplicity. Those running hybrid classical-PQC environments during migration gravitate toward chameleon schemes, where the KEM algorithm can be upgraded independently without reissuing the entire certificate.
BeQuantum’s IceCase hardware security modules are designed to handle the larger key material that PQC algorithms demand. Where classical RSA-2048 keys fit comfortably in legacy HSM storage, ML-KEM-1024 public keys (1,568 bytes) and ML-DSA-65 public keys (1,952 bytes) combined in a dual-usage certificate require hardware that was built for post-quantum key sizes from the ground up — not retrofitted.
What You Should Do Next
Within 30 days: Inventory every certificate type in your environment and identify which ones serve dual purposes (authentication + encryption) versus single purposes. This mapping determines how many dual-usage certificates you would need versus how many separate PQC certificates.
Within 90 days: Run a proof-of-concept with at least one latency-sensitive application — instant messaging, real-time API gateways, or WebSocket-based services — testing ML-KEM key exchange overhead against your current performance baselines. Measure both message size inflation and computation time across ML-KEM-768 and ML-KEM-1024 parameter sets.
Within 180 days: Evaluate your HSM fleet’s capacity to store and process PQC dual-usage certificates. If your current hardware cannot handle combined DSA + KEM key material at the scale you need, begin procurement planning now — HSM refresh cycles typically run 12-18 months.
Frequently Asked Questions
Q: Can dual-usage certificates work with existing TLS 1.3 infrastructure?
A: Not without modification. TLS 1.3 assumes separate mechanisms for server authentication (signatures) and key exchange (Diffie-Hellman or KEM). Dual-usage certificates would require extensions to the TLS handshake to leverage both the DSA and KEM keys from a single credential. Standards bodies including the IETF are actively working on PQC integration for TLS, but dual-usage certificate support is not yet part of any published RFC.
Q: Which of the three schemes — composite, catalyst, or chameleon — should my organization adopt?
A: It depends on your migration strategy. If you are deploying PQC greenfield (no classical fallback needed), composite schemes offer the simplest management. If you are running a hybrid classical-PQC environment during transition, chameleon schemes give you the flexibility to upgrade the KEM component independently. Catalyst schemes sit in between — consider them when certificate size is a binding constraint but you want tighter key binding than chameleon provides.
Q: How much larger are dual-usage certificates compared to classical X.509 certificates?
A: Substantially larger. A classical RSA-2048 certificate with a single public key runs roughly 1,000-1,500 bytes. A dual-usage PQC certificate combining ML-DSA-65 (1,952-byte public key) and ML-KEM-768 (1,184-byte public key) would carry over 3,100 bytes of key material alone, before accounting for signature fields, extensions, and metadata. Expect total certificate sizes of 5,000-8,000 bytes depending on the scheme and algorithms selected.
Last updated: April 15, 2026. Based on analysis of arXiv:2604.08612v1.
