{
    "content": {
        "text": "Post-quantum cryptography: the standards are done, the migration is not\n\nIn August 2024 NIST finalized the first three post‑quantum cryptographic standards. They are no longer drafts, candidates or research directions. They are the algorithms that federal systems will be required to use, and the ones most commercial deployments will follow.\n\n- **FIPS 203** — Module‑Lattice‑Based Key‑Encapsulation Mechanism Standard, specifying **ML‑KEM**, derived from CRYSTALS‑Kyber. This replaces the key exchange protecting a TLS session.\n- **FIPS 204** — Module‑Lattice‑Based Digital Signature Standard, specifying **ML‑DSA**, derived from CRYSTALS‑Dilithium. The general‑purpose signature algorithm.\n- **FIPS 205** — Stateless Hash‑Based Digital Signature Standard, specifying **SLH‑DSA**, derived from SPHINCS+. Slower and larger, but its security rests only on hash functions, providing a structurally independent backup if lattice assumptions are weakened.\n\nTwo more are still in progress: **FN‑DSA** (from Falcon), a lattice signature with much smaller signatures than ML‑DSA, and **HQC**, a code‑based key encapsulation mechanism selected in 2025 as a mathematically distinct alternative to ML‑KEM. The diversity is deliberate; standardizing two families that fail for different reasons is insurance against a break in either one.\n\n## Why the timeline is shorter than it looks\n\nThe obvious reading is that nothing needs to happen until a cryptographically relevant quantum computer exists, and that such a machine is years away. For signatures, that reading is roughly correct: a signature verified today and never again is not threatened by a machine built in 2035.\n\nFor confidentiality it is wrong, and the reason is **harvest now, decrypt later**. An adversary who records encrypted traffic today can decrypt it whenever the capability arrives. The question is not when quantum computers arrive, but how long the data in your traffic stays sensitive. Medical records, identity documents, sealed legal material and long‑lived credentials all outlast the gap comfortably. For that data the exposure started the day it crossed the wire.\n\nNIST IR 8547 sets the direction: quantum‑vulnerable algorithms are to be deprecated and ultimately removed from NIST standards by 2035, with higher‑risk systems expected to move earlier.\n\n## What migration actually involves\n\nThe algorithm swap is the easy part. The hard parts are structural.\n\n**Inventory first.** Most organizations cannot answer, from records, where RSA and elliptic‑curve cryptography is used across their systems. It is in TLS terminators, code signing, firmware verification, document signing, VPNs, hardware security modules, and embedded devices with a decade of remaining service life. Migration cannot be planned against an unknown surface, and building that inventory is usually the longest single step.\n\n**Sizes change, and things break.** ML‑KEM and ML‑DSA keys and signatures are substantially larger than their elliptic‑curve equivalents. That collides with fixed‑size fields, embedded flash budgets, single‑packet handshake assumptions and protocol buffers sized years ago. These failures surface in integration, not in cryptographic review.\n\n**Hybrid is the realistic transition.** Combining a classical key exchange with a post‑quantum one means the session is secure unless both are broken. Major browsers and TLS libraries have already deployed hybrid key exchange, which is why a meaningful share of web traffic is post‑quantum protected today without anyone having chosen it explicitly.\n\n**Crypto‑agility is the durable lesson.** Systems that hard‑coded RSA are the expensive ones now. FN‑DSA and HQC are still arriving, and the standards will change again. The property worth building is the ability to change algorithm without changing architecture.\n\n## Where to start\n\nInventory what you use, classify data by how long it must stay confidential, enable hybrid key exchange where your stack supports it, and treat algorithm choice as configuration rather than as a structural commitment.\n\n*Sources: NIST FIPS 203, 204 and 205 (August 2024); NIST IR 8547; NIST Post‑Quantum Cryptography project.*",
        "summary": "An overview of NIST's finalized post‑quantum cryptography standards (FIPS 203, 204, 205) and the practical challenges of migrating from legacy RSA and elliptic‑curve cryptography, including inventorying usage, handling larger key sizes, adopting hybrid key exchange, and building crypto‑agility.",
        "keywords": [
            "post-quantum cryptography",
            "NIST",
            "FIPS 203",
            "FIPS 204",
            "FIPS 205",
            "ML-KEM",
            "ML-DSA",
            "SLH-DSA",
            "migration",
            "crypto-agility",
            "hybrid key exchange"
        ],
        "entities": [
            "NIST",
            "FIPS 203",
            "FIPS 204",
            "FIPS 205",
            "ML-KEM",
            "ML-DSA",
            "SLH-DSA",
            "FN-DSA",
            "HQC",
            "RSA",
            "Elliptic-curve cryptography",
            "TLS",
            "CRYSTALS‑Kyber",
            "CRYSTALS‑Dilithium",
            "SPHINCS+",
            "Falcon",
            "NIST IR 8547"
        ],
        "links": [
            "https:\/\/data.aisenseapi.com\/content\/2026\/08\/26\/content_1787741325_29284cdc9e31.md"
        ],
        "structured_data": [
            {
                "name": "FIPS 203",
                "standard": "Module‑Lattice‑Based Key‑Encapsulation Mechanism Standard",
                "algorithm": "ML‑KEM",
                "description": "Replaces the key exchange protecting TLS sessions; derived from CRYSTALS‑Kyber."
            },
            {
                "name": "FIPS 204",
                "standard": "Module‑Lattice‑Based Digital Signature Standard",
                "algorithm": "ML‑DSA",
                "description": "General‑purpose digital signature algorithm; derived from CRYSTALS‑Dilithium."
            },
            {
                "name": "FIPS 205",
                "standard": "Stateless Hash‑Based Digital Signature Standard",
                "algorithm": "SLH‑DSA",
                "description": "Hash‑based signature scheme derived from SPHINCS+; larger but provides a backup independent of lattice assumptions."
            },
            {
                "name": "FN‑DSA",
                "standard": "Pending lattice signature standard",
                "algorithm": "Falcon",
                "description": "Lattice‑based signature with smaller signatures than ML‑DSA."
            },
            {
                "name": "HQC",
                "standard": "Pending code‑based key encapsulation mechanism",
                "algorithm": "HQC",
                "description": "Mathematically distinct alternative to ML‑KEM, selected in 2025."
            }
        ]
    },
    "structure": {
        "@context": "https:\/\/schema.org",
        "@type": "TechArticle",
        "title": "Post-quantum cryptography: the standards are done, the migration is not",
        "technical_specification": [
            "FIPS 203 – ML‑KEM",
            "FIPS 204 – ML‑DSA",
            "FIPS 205 – SLH‑DSA"
        ],
        "version": "2024-08",
        "headline": "Post-quantum cryptography: the standards are done, the migration is not",
        "description": "An overview of NIST's finalized post‑quantum cryptography standards and the practical steps needed for organizations to migrate from legacy RSA and elliptic‑curve cryptography.",
        "author": {
            "@type": "Person",
            "name": "Anonymous"
        },
        "datePublished": "2024-08-01"
    },
    "ai_meta": {
        "token_est": 420,
        "chars": 2543,
        "crawler_hint": "tech-article",
        "richness_score": 0.86,
        "embedding_ready": true,
        "provider": "ollama",
        "model": "gpt-oss:120b",
        "expires": "2027-02-22T11:48:45+01:00"
    },
    "reasoning": "The input was cleaned of markup artifacts, excess newlines, and UTF‑8 issues. The article is classified as a TechArticle, so the JSON includes both generic Article fields (headline, description, author, datePublished) and TechArticle‑specific fields (title, technical_specification, version). Keywords and entities were extracted from the text. Structured data was created for each of the five standards mentioned, providing name, standard type, algorithm, and a brief description. Metadata estimates token count, character count, a crawler hint, a richness score, and marks the content as ready for embedding."
}