Post-quantum cryptography and what to do about it now

Why this matters

CompTIA list post-quantum cryptography first among the advanced cryptography topics, and its presence on the exam is a statement about timing: the migration is a live programme in organisations that hold long-lived secrets, not a future concern.

The reason is the threat model, and it is the single most important idea in this lesson. A sufficiently capable quantum computer does not exist today. That is irrelevant to data captured today, because an adversary can record encrypted traffic now and decrypt it when the capability arrives. Any secret whose value outlives that horizon is already exposed.

The exam angle is practical rather than mathematical. It asks whether you can identify which data is actually at risk, what the algorithm categories replace, what crypto-agility means as an engineering deliverable, and why hybrid schemes are the cautious choice during transition. A scope note, stated once: this course covers selection and migration posture, not the lattice mathematics underneath, because CAS-005 does not examine the mathematics and studying it returns nothing here.

The lesson

The threat model: harvest now, decrypt later, and which data it actually applies to

Two distinct classes of cryptography are affected differently, and conflating them produces the wrong migration plan.

Public-key cryptography is broken by a sufficiently capable quantum computer. The algorithms underpinning key exchange and digital signatures in almost all deployed systems rely on problems — integer factorisation and discrete logarithms — that a quantum algorithm solves efficiently. These do not degrade gracefully; they fail.

Symmetric cryptography is weakened, not broken. The best known quantum attack effectively halves the security level, which is addressed by using longer keys. A 256-bit symmetric key retains a comfortable margin, which is why symmetric algorithms and hashes are largely a matter of sizing rather than replacement.

Harvest now, decrypt later follows from the first point. An adversary with storage and patience captures encrypted traffic today and retains it. When the capability arrives, the session keys negotiated by today's public-key exchange are recoverable, and with them the traffic. No future upgrade protects data already captured.

So the question that determines urgency is: how long must this data stay confidential? Add the required confidentiality lifetime to today and compare against a planning horizon for the capability. Data that must stay secret for twenty-five years is at risk under essentially any estimate.

Which data that actually is, and it is a narrower set than "everything":

• Health and genetic records, which are sensitive for a lifetime.
• Government and defence material with long classification periods.
• Trade secrets, formulations and long-lived intellectual property.
• Legal and financial records with decades-long obligations.
• Personal data where re-identification remains harmful indefinitely.
• Long-lived keys and root certificates, whose compromise is retrospective — and which are frequently missed in this analysis.

What is comparatively less urgent: session data with short value, operational telemetry, and anything already public. Signatures deserve their own note: a signature verified today and never again is not a harvest-now target, whereas a signature that must remain verifiable for decades — code signing, long-term archives, certificate roots — is.

The standardised post-quantum algorithms and what each replaces

Standardisation has produced algorithms in two functional categories, and knowing which category solves which problem is the examinable content.

Key encapsulation mechanisms replace key exchange. Where two parties today negotiate a shared secret using elliptic-curve or finite-field Diffie-Hellman, a key encapsulation mechanism achieves the same outcome by a quantum-resistant route: one party encapsulates a secret to the other's public key, and both derive the same session key. The leading standardised scheme is lattice-based.

Digital signature algorithms replace signing. Standardised options include lattice-based schemes suited to general use, and hash-based schemes whose security rests only on the hash function — a conservative choice with large signatures and, in some variants, a strict limit on how many signatures a key may produce, which makes them a poor fit for high-volume signing and a good fit for firmware and root signing.

Three practical properties differ from what they replace, and they are what makes migration an engineering exercise rather than a configuration change:

• Key and signature sizes are substantially larger. That affects protocol messages, certificate sizes, handshake packet counts, storage and embedded devices with constrained memory. A handshake that no longer fits where it used to is a real compatibility problem.
• Performance characteristics differ, sometimes favourably and sometimes not, and the change is not uniform between operations.
• Implementation maturity is younger, so library support, hardware acceleration and side-channel hardening are all less settled.

Diversity across mathematical families is deliberate: lattice-based schemes carry most of the load, and hash-based and other families exist so that a weakness found in one family does not leave the world with nothing.

Crypto-agility as the real deliverable: inventory, abstraction, and the ability to swap

This is the section that matters most for the exam and for the job. The deliverable of a post-quantum programme is not an algorithm; it is the ability to change algorithms.

The reasoning is straightforward. The transition will involve several changes over years — hybrid first, then post-quantum only, with parameter revisions and possibly a replacement if a scheme is weakened. An organisation that migrates once by hand will be in the same position at the next change. An organisation that builds agility does each subsequent change cheaply.

Crypto-agility has three components, and they map to three pieces of work:

A cryptographic inventory. What algorithms are in use, where, by what, protecting what, and for how long that protection must hold. This is the first step every published migration guidance names and it is the one organisations discover they cannot do — because cryptography is embedded in applications, appliances, protocols, libraries, hardware, third-party services and code nobody maintains. Sources: code and dependency scanning, TLS configuration scanning across the estate, certificate inventories, key management system contents, vendor attestations, and the software bill of materials from lesson thirty.

Abstraction. Applications should call a cryptographic service or a well-defined interface rather than pinning a specific algorithm in their own code. Where the algorithm choice is a configuration item rather than a source change, migration becomes deployment rather than development.

Negotiation and versioning. Protocols should negotiate algorithms rather than assume them, and data formats should record which algorithm protected them so a future reader can tell. Stored ciphertext with no algorithm identifier is a migration problem waiting years.

The prioritisation that follows the inventory is the same risk ordering as everywhere else in this course: confidentiality lifetime × exposure. Long-lived data crossing untrusted networks first; short-lived internal traffic last; long-lived signing keys treated separately because their exposure is retrospective.

Hybrid key establishment during the transition, and why it is the cautious choice

Hybrid key establishment performs both a classical and a post-quantum exchange and combines both results into the session key. The session is secure unless both are broken.

Why that is the right posture during transition, and the reasoning is worth being able to state:

• The post-quantum schemes are newer. Their security rests on assumptions with less cryptanalytic history than the classical ones. A weakness found in a new scheme would be catastrophic for an estate that had abandoned the old one; in a hybrid it is survivable.
• The classical schemes are known to fail eventually, so relying on them alone leaves harvest-now-decrypt-later open.
• Combining them costs little — one extra exchange, larger handshake messages — against a genuinely asymmetric risk.

The costs are real and bounded: larger handshakes that can exceed path limits and cause fragmentation or failures on constrained paths, slightly more computation, and middleboxes that reject handshakes they do not recognise. That last one is the practical obstacle in enterprise estates and is why staged rollout with measurement matters.

For signatures the calculus differs. A hybrid signature means producing and verifying two, which doubles size and verification cost on every use, and the harvest-now argument does not apply the same way — a signature verified today is not retrospectively forgeable. The usual position is hybrid for key establishment now, and migrate signatures on a slower schedule driven by how long each signature must remain verifiable, with firmware and root signing first because those keys have the longest lives.

Scope note: this course covers selection and migration, not the underlying mathematics

The closing note, placed deliberately, because this is a topic where interest and examinable content diverge sharply.

What CAS-005 can reasonably ask, given that this is one bullet in a five-bullet domain:

• What harvest-now-decrypt-later means and which data it threatens.
• That public-key cryptography is broken and symmetric is weakened.
• What a key encapsulation mechanism replaces and what a signature scheme replaces.
• What crypto-agility is and why it is the deliverable.
• Why hybrid is the cautious transitional choice.
• The first step of a migration, which is the inventory.

What it will not ask, and what returns nothing for the study time: lattice problems, the structure of the standardised schemes, parameter derivations, or comparative cryptanalysis. That material belongs to cryptographic engineering and is a genuinely large field.

The practical study advice mirrors lesson fifteen's. Be able to answer, for your own estate: what cryptography protects our longest-lived secrets, where is it implemented, how would we change it, and how long would that take. A candidate who can answer those four can answer any question this objective is likely to pose — and the questions are the same ones the job asks, which is not always true of exam material.