In a previous blog post, we discussed key exchange in TLS. This is how two parties can share information with each other securely. By sharing key material without disclosing it on the network, the two parties can now generate shared keys to do bulk encryption of the message traffic.
In another blog post, we showed that a hybrid key exchange mixes both a traditional and a post-quantum algorithm. The most common one (X25519MLKEM) is already seeing wide support on the World Wide Web (WWW), and is, as the name suggests, a combination of the X25519 elliptic curve and the post-quantum ML-KEM 768. This prevents a passive observer from intercepting and storing traffic, and then decrypting it later (a threat called “harvest now, decrypt later” [HNDL]).
Another threat occurs when an attacker tries to impersonate a trusted entity (i.e., a vendor emailing an invoice for payment, an ecommerce website, and so on). This requires positive action: The attacker interposes themself between you and the other party, so that they can fool you. This is harder to do (and, importantly, can't be done retroactively), so much of the post-quantum focus so far has been on key exchange.
Digital signatures
Digital signatures that use traditional mechanisms such as RSA or elliptic curve, will also be crackable when a cryptographically relevant quantum computer (CRQC) becomes available.
One of the algorithms that the National Institute of Standards and Technology (NIST) has approved for signatures is a post-quantum algorithm called the module-lattice digital signature algorithm (ML-DSA) published as FIPS 204.
Another post-quantum algorithm is the stateless hash-based digital signature (SLH-DSA), published as FIPS 205, but it is better suited to particular use cases (for example, firmware updates). We will discuss that in more detail in a future post.
Signatures are used to indicate that a document hasn't been tampered with and to identify the entity making that claim. On the web, the document is a certificate, which identifies both the DNS name and public key of the server (i.e., the signer is the certification authority [CA]).
Web certificates have comparatively short lifetimes, and will be moving to 47 days by March 2029. But signatures are also used on electronic documents. Some of these could have high value or much longer lifetimes and fall within the current threat of HNDL.
The three variants of ML-DSA
The table shows the three variants of ML-DSA, with increasingly larger key and signature sizes.
Algorithm |
Strength |
Public key size |
Private key size |
Signature size |
RSA 2048 |
112 |
256 |
256 |
256 |
P-256 Elliptic |
128 |
32 |
32 |
64 |
ML-DSA-44 |
128 |
1312 |
2590 |
2420 |
ML-DSA-65 |
192 |
1952 |
4032 |
3309 |
ML-DSA-87 |
256 |
2592 |
4896 |
4627 |
Digital signatures, including the three variants of ML-DSA
We can see that ML-DSA is between 20 and 80 times bigger. A typical TLS certificate chain will have two or three entries: the CA root (which is omitted if the browser already has it in its local trust store), the signing intermediate CA, and the leaf certificate identifying the server in question.
While this might be acceptable for TLS, it definitely has an impact on other protocols (which we will also discuss in detail in a future post).
The formatting of a hybrid signature
When making a hybrid signature, there are two fundamental approaches:
Adding a second signature, which is not always possible
Defining a new identifier for a single signature that has both values (known as a composite signature)
The Internet Engineering Task Force (IETF) has been wrestling with the format for a composite signature for more than six years. (In comparison, the TLS hybrid key exchange drafts took approximately one year.)
The current draft contains about 50 pages of copy, and another 100 pages of test vectors with sample keys and signatures. It's big — but, if you're an implementer, it is pretty straightforward.
The complication arises because the document defines 18 different combinations: a mix of the three ML-DSA sizes, different hash mechanisms, and multiple RSA and elliptic curves. The full list can be found in the ASN.1 definitions (look for the Object Identifiers section).
However, it could have been much worse: To its credit, this draft specified specific parameter values, rather than leaving them open, and explained the rationale for their choices.
That smorgasbord of choices has an impact on protocol development and run time. It is unlikely that vendors will support all the choices, and most Web Public Key Infrastructure (PKI) CAs cannot issue public WWW certificates until the CA/Browser forum issues its recommendations. It could be up to industry associations to define a profile (subset) of this, and vendors will have to adapt to multiple markets.
To wait or not to wait?
Some industry segments have already decided and aren't waiting for hybrid signatures. The American National Standards Institute (ANSI) has a committee known as X9 whose mission is "to create standards that improve payments and protect financial information both in the US and internationally."
They have created their own PKI and hired Digicert to run and maintain it. The X9 PKI has three roots, one for each ML-DSA variant.
Interestingly, at a recent industry forum meeting, X9 staffers reported that two other industry verticals — health-care and hospitality — expressed their interest in prototyping work with the X9 post-quantum PKI. Since both verticals have a lot of user financial data, X9 is allowing them to use the PKI, as long as everyone realizes that the primary focus is on the financial industry.
Akamai’s phased approach: A progress update
Akamai’s approach to securing end-to-end delivery transport includes three phases:
- Phase one: Akamai-to-origin (Akamai-to-website)
- Phase two: Client-to-Akamai (browser-to-Akamai)
- Phase three: Akamai-to-Akamai
Phase one: Akamai-to-origin
Post-quantum cryptography (PQC) to origin servers using the X25519MLKEM768 hybrid key share has been available to all customers as an opt-in limited availability feature. We are currently planning on enabling this by default for all customers beginning in Q1 2026 with our general availability (GA) feature release.
We encourage all customers to enable PQC to their origins. Keep in mind that the feature is backward compatible, allowing customers to enable it even if their origin infrastructure currently can’t support PQC.
Note: Customers have the ability to opt out ahead of the GA “on by default” platform behavioral change.
Phase two: Client-to-Akamai
We launched PQC support for client browser-to-Akamai connections as a limited availability opt-in feature on September 1, 2025.
This setting is independent of the enablement of PQC from Akamai-to-origin — meaning that even if your origin cannot yet support PQC, you can still enable PQC on the client-to-Akamai connection to protect your users.
This feature is expected to enter GA in Q1 2026.
We encourage all customers to enable PQC for all clients. The majority of today’s client browsers support PQC, making quantum-safe connections broadly available to end users.
Note: Customers will have the ability to opt out ahead of the GA “on by default” platform behavioral change.
Phase three: Akamai-to-Akamai
We are on track to complete the PQC update for mid-tier connections across all of Akamai’s networks in Q1 2026. With this change, all Akamai-to-Akamai connections will be quantum-safe, and customers who have enabled client-to-Akamai and Akamai-to-origin PQC will enjoy full end-to-end quantum resistant traffic protection against the active HNDL threat.
Conclusion
Based on what we have seen and heard from customers so far, we expect to support pure ML-DSA signatures first. Of course, we will pursue hybrid certificates in line with CA/B Forum guidelines for the Web PKI as they become available.
Stay tuned
In our next post in this series, we will discuss the impact of PQC on a variety of other facilities, such as Secure Shell.
Tags
