Skip to main content

Post-quantum cryptography

Introduction​

A cryptographically relevant quantum computer would break the public-key algorithms that today's TLS and PKI depend on: RSA and elliptic-curve key exchange and signatures. No such machine is known to exist, but the transition away from those algorithms has to begin well before one does, for reasons this page explains.

The transition matters more at the edge than in most environments. Industrial equipment stays in service for fifteen to thirty years, sites are numerous and remote, and the certificates and trust hierarchies you establish now will still be in use when the landscape has changed. This page describes what Avassa supports today, and the design position behind it.

The two halves of the problem, and their different urgency​

Post-quantum migration is often discussed as a single event. It is really two problems with very different deadlines.

Confidentiality is at risk retroactively. An adversary can record encrypted traffic today and decrypt it years later, once a quantum computer becomes available. This is usually called harvest now, decrypt later. It means the protection of today's traffic depends on the key exchange used today — waiting is not neutral, because the exposure is already accumulating. Anything with a long confidentiality lifetime is affected now.

Authenticity is at risk prospectively. A forged signature is only useful while the certificate it authenticates is still trusted. An attacker cannot go back and retroactively forge a handshake that already happened. Signature migration therefore becomes urgent later than key exchange does — but it must be complete before quantum capability arrives, and certificate hierarchies with long-lived roots take years to turn over.

The practical consequence is a clear ordering: adopt post-quantum key exchange as early as it can be deployed, and move signatures on a schedule set by the lifetime of the certificates involved and by what the peers and devices in your environment can actually support.

The standards Avassa implements​

Avassa implements the algorithms standardised by NIST in 2024, which are also the algorithms named by national guidance such as the Australian ASD's, and by CNSA 2.0:

  • ML-KEM (Module-Lattice Key Encapsulation Mechanism, NIST FIPS 203) for key establishment.
  • ML-DSA (Module-Lattice Digital Signature Algorithm, NIST FIPS 204) for signatures, in parameter sets ML-DSA-44, ML-DSA-65 and ML-DSA-87 (NIST security categories 2, 3 and 5).

Post-quantum key exchange​

TLS 1.3 connections can negotiate ML-KEM key exchange, configured as a preference order of key-share groups on a TLS CA. Both pure ML-KEM groups and a hybrid group combining X25519 with ML-KEM-768 are available.

The hybrid group is the pragmatic choice for most deployments, and the reason is worth stating. A pure post-quantum group only works if every peer supports it; a connection to a peer that does not simply fails to negotiate. A hybrid group derives its secret from both the classical and the post-quantum exchange, so the connection is protected against a future quantum adversary while remaining at least as strong as the classical exchange alone if the post-quantum component were ever found wanting. It also degrades gracefully in a mixed environment.

Because this is a property of the key exchange rather than of any certificate, post-quantum confidentiality can be turned on without reissuing a single certificate. It is the fastest available answer to harvest-now-decrypt-later, and it is independent of the slower work of migrating signatures.

Post-quantum certificates​

A Strongbox CA can be generated with an ML-DSA key instead of a classical one, and issues ML-DSA-signed certificates. Both the subject key of an issued certificate and the CA's signature over it can be post-quantum, giving a fully post-quantum chain.

This is opt-in per CA. Existing CAs and the platform's own internal certificates are unaffected, and the defaults remain classical (ECDSA). That is deliberate: a CA whose signatures no peer can verify is not useful, so the choice of when a given hierarchy moves belongs with the operator who knows what its relying parties support.

Different CAs in the same tenant can use different algorithms, so a classical hierarchy and a post-quantum one can run side by side. This is what makes a gradual migration possible: a population can be moved onto a post-quantum hierarchy when its software supports ML-DSA, without waiting for everything else.

Migration is an operational capability, not an algorithm choice​

The hardest part of a post-quantum migration is not selecting algorithms. It is being able to change credentials at all: to reissue, redistribute and roll over certificates across many remote sites, repeatedly, without a site visit and without an outage.

Avassa's position is that this capability is the thing worth building first, because everything else follows from it:

  • Short certificate lifetimes with automated renewal. If renewal is genuinely automatic, a short lifetime costs nothing operationally, and a credential can be replaced quickly when the need arises. Renewal that works is also renewal that has been exercised, rather than a procedure discovered to be broken at the worst moment.
  • CA rollover with distribute-before-activate. A new CA certificate can be created and distributed to relying parties ahead of the point where it starts signing, which is exactly the sequencing a root migration requires.
  • Per-site issuance and validation. Certificates are issued and revocation is served close to where they are used, so a migration does not depend on every site holding a WAN link open at the same moment.
  • Automated device enrollment. Equipment can obtain and renew its own certificates, which is what makes re-credentialing a fleet feasible at all.

An environment with these properties can absorb an algorithm change as routine work. An environment without them faces a project, whichever algorithms it has selected.

What is not supported​

Being explicit about the boundaries:

  • Composite (dual-algorithm) certificates, carrying a classical and a post-quantum signature in one certificate, are not supported. The relevant specifications are still drafts. Running parallel classical and post-quantum hierarchies is the supported approach.
  • Stateful hash-based signatures (LMS, XMSS), which some guidance recommends for firmware signing, are not supported. They address code signing rather than network identity.
  • SLH-DSA (FIPS 205) is not supported; ML-DSA is the signature algorithm implemented.
  • Hardware security module (PKCS#11) backing for CA keys is not supported. Where an HSM-protected root is required, the usual pattern is for that root to sign the CAs the platform operates.

A realistic view of the ecosystem​

Post-quantum support in the wider world is uneven. Browsers and modern TLS libraries have shipped hybrid ML-KEM key exchange, which is why post-quantum confidentiality is deployable now. Post-quantum signature support in embedded and industrial software is much thinner, and will remain so for some years.

This asymmetry is the reason for the ordering described above rather than an obstacle to it. Enabling hybrid key exchange addresses the risk that is accumulating today. Moving signature hierarchies can then proceed at the pace the relying parties allow, on a platform where changing a credential is an ordinary operation rather than an event.