Post-Quantum Cryptography

No cryptographically relevant quantum computer exists today. That fact is true and almost irrelevant to the decision an architect needs to make this quarter. The threat to RSA and ECC is not "quantum computers will eventually exist" — it's that an adversary can capture your encrypted traffic today, store it, and decrypt it retroactively the moment a sufficiently powerful quantum computer arrives. If the data has to stay confidential for longer than that arrival window, it is already exposed. This is an engineering deadline, not a speculative one, and it is measured against your data's shelf life, not against a quantum computer's release date.

Vector Alpha: The Quantum Threat Mechanics

Public-key cryptography as deployed today — RSA, Diffie-Hellman, and Elliptic Curve Cryptography — rests entirely on the assumption that certain math problems are computationally intractable for classical computers. Shor's Algorithm doesn't attack the encryption; it demolishes that assumption.

How Shor's Algorithm Breaks RSA, DH, and ECC

RSA's security depends on integer factorization: given a large number that is the product of two large primes, finding those primes is classically hard — the best known classical algorithms scale sub-exponentially, which is enough to make factoring a 2048-bit RSA modulus practically infeasible. Diffie-Hellman and ECC rest on a structurally related problem: the discrete logarithm problem, either in a multiplicative group (classical DH) or over an elliptic curve group (ECDH/ECDSA). Both problems belong to the same mathematical family — hidden subgroup problems — and that shared structure is exactly what Shor's Algorithm exploits.

Shor's Algorithm runs on a quantum computer and solves both integer factorization and discrete logarithm problems in polynomial time, using quantum period-finding via the Quantum Fourier Transform to extract the hidden periodicity that the classical hardness assumption depends on. In plain terms: the property that makes factoring hard for a classical computer — no efficient way to find the period of a related function — is exactly the property quantum superposition lets you exploit efficiently. A sufficiently large, sufficiently stable quantum computer running Shor's Algorithm reduces RSA-2048 and ECC-256 from computationally infeasible to break to feasible.

Harvest Now, Decrypt Later — The Threat That's Already Active

"Harvest Now, Decrypt Later" (HNDL) is not a future attack. It is a present-tense data collection strategy that only becomes a decryption event in the future. An adversary with the resources to do bulk traffic interception — a nation-state actor sitting on internet backbone infrastructure, for instance — does not need a quantum computer today. They need storage, and they need your ciphertext to still matter by the time they get one.

Vector Beta: The NIST Post-Quantum Standards

NIST's Post-Quantum Cryptography standardization process finalized a set of algorithms built on hardness assumptions that, as far as current research shows, resist both classical and quantum attack. The dominant family is lattice-based cryptography.

Lattice-Based Cryptography, for a Working Engineer

A lattice is a regular, infinite grid of points in n-dimensional space, generated by integer combinations of a set of basis vectors. The hard problem the new standards rely on is the Learning With Errors (LWE) problem: given a set of noisy linear equations — A·s + e = b, where A is a known matrix, s is a secret vector, and e is small random error/noise — recovering the secret s is believed to be hard for both classical and quantum computers, because the noise term e destroys the clean algebraic structure that made Shor's Algorithm effective against factorization and discrete logs.

KEMs vs. Digital Signatures — Two Different Jobs

The NIST standards split into two categories solving two structurally different problems: establishing a shared secret between two parties (Key Encapsulation Mechanisms), and proving a message came from a specific party without forgery (Digital Signatures). Conflating the two is a common architectural mistake — a KEM cannot sign, and a signature scheme cannot establish a shared session key.

Vector Gamma: Implementing Crypto-Agility

Crypto-agility is the architectural capacity to swap the underlying cryptographic algorithm — key exchange, signature scheme, cipher — without a ground-up infrastructure rebuild. It is the property that determines whether your post-quantum migration is a configuration change or a multi-year re-architecture.

Hybrid Cryptography: The Practical Transition Strategy

No serious enterprise architecture jumps directly from ECDHE to pure ML-KEM. Post-quantum algorithms are newer, with less than a decade of public cryptanalytic scrutiny compared to ECC's multi-decade track record. Hybrid key exchange combines both: the final session key is derived from the combination of a classical ECDHE shared secret and a post-quantum KEM shared secret, such that an attacker must break both the classical and the post-quantum component to recover the session key.

Vector Delta: Full-Stack Integration Scenarios

The theory converges on two concrete integration surfaces: the Java backend terminating TLS and encrypting data at rest, and the Vue 3 / Nuxt 3 frontend handling client-side token storage and encryption.

Backend (Java): TLS Termination, Sessions, and Database Encryption

The JDK's default TLS provider does not yet ship ML-KEM/ML-DSA support in most enterprise-standard runtime versions, which is precisely why crypto-agility matters at the provider level: Bouncy Castle's PQC implementation (bcpg / bc-fips with post-quantum algorithm support) can be registered as a java.security.Provider, giving an application access to ML-KEM and ML-DSA without waiting on the platform TLS stack to catch up.

import org.bouncycastle.jce.provider.BouncyCastleProvider;
import org.bouncycastle.pqc.jcajce.provider.BouncyCastlePQCProvider;
import javax.crypto.KeyGenerator;
import java.security.KeyPairGenerator;
import java.security.Security;

public class PqcProviderConfig {

    public static void registerProviders() {
        Security.addProvider(new BouncyCastleProvider());
        Security.addProvider(new BouncyCastlePQCProvider());
    }

    public static KeyPairGenerator mlKemKeyPairGenerator() throws Exception {
        // ML-KEM-768 — NIST security level 3, the recommended default
        // for most enterprise TLS termination scenarios.
        KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-KEM-768", "BCPQC");
        return kpg;
    }

    public static KeyPairGenerator mlDsaKeyPairGenerator() throws Exception {
        // ML-DSA-65 for certificate and token signing.
        return KeyPairGenerator.getInstance("ML-DSA-65", "BCPQC");
    }
}

Frontend (Vue 3 / Nuxt 3): Client-Side Constraints

The browser's native WebCrypto API — the standard interface for crypto.subtle operations — does not currently expose ML-KEM or ML-DSA as supported algorithms in any shipping browser implementation. This is the single most important constraint for frontend architects: post-quantum cryptographic operations in the browser today require a WebAssembly-compiled library, not a native browser API call.

import { ref, onMounted } from 'vue'

export function usePqcSession() {
  const ready = ref(false)
  // ML-KEM is not in WebCrypto — loaded via a Wasm-compiled PQC library,
  // lazily, so it never blocks initial page render or Core Web Vitals.
  const pqc = ref<typeof import('../wasm/pqc-kem') | null>(null)

  onMounted(async () => {
    const mod = await import('../wasm/pqc-kem')
    await mod.default()
    pqc.value = mod
    ready.value = true
  })

  function encapsulate(serverPublicKey: Uint8Array) {
    if (!pqc.value) throw new Error('PQC module not ready')
    // Runs the ML-KEM encapsulation in Wasm — the actual TLS-level
    // handshake is still handled by the browser/OS network stack;
    // this pattern applies to APPLICATION-LAYER PQC payloads only,
    // e.g. end-to-end encrypting a payload before it hits the wire.
    return pqc.value.encapsulate(serverPublicKey)
  }

  return { ready, encapsulate }
}

Closing: The Migration Clock Already Started

The post-quantum transition is unusual among security migrations in one specific way: the exposure event predates the fix by an unknown number of years, which means the correct response cannot wait for certainty about the timeline. Crypto-agility is what converts an existential architecture problem into a routine configuration change — and hybrid key exchange is the concrete, already-deployable step that makes today's TLS traffic resistant to a threat that may not fully materialize for another decade, precisely because the data being protected today needs to still be confidential then.

The organizations that treat this as a slow-burn compliance checkbox will find themselves migrating in a panic once a CRQC timeline becomes concrete and public. The organizations that build crypto-agility into their TLS termination, their signing infrastructure, and their key management today are the ones for whom the eventual full post-quantum cutover is a configuration flag flip, not an infrastructure rebuild under a deadline they don't control.