Post-Quantum Security — future-proofing the keys

What you’ll get here

an intuitive answer to “what does quantum computing have to do with my blockchain account, and what is Smart Engines doing about it now?” — with a clear line between what’s already protected and what isn’t yet. For the audit-grade detail (algorithms, cert format, offline verification), continue to Post-Quantum Security › Security reference.

Everything else in Core Concepts is about who can sign and what they’re allowed to sign. This page is about a different axis entirely: time. The signatures that protect your account today rest on math that a future quantum computer could break. Smart Engines is hedging against that future now, not later.

🧠 For Normies

A “quantum computer” isn’t just a faster laptop — it can solve certain math problems that today’s computers effectively can’t. Two of those problems are exactly the ones that make blockchain signatures safe. No one has a big enough quantum computer yet, but the worry is real: an attacker can record signed data today and forge or unlock it years later once the machine exists. The defense is to start using quantum-resistant math before that day arrives.

---

The problem: Shor’s algorithm and “harvest now, decrypt later”

Today’s blockchain keys (Ed25519, ECDSA, secp256k1) are safe because reversing them means solving the discrete-logarithm or integer-factorization problem — practically impossible for normal computers. Shor’s algorithm, run on a large enough quantum computer, solves both efficiently.

The danger isn’t only future transactions. It’s the harvest-now, decrypt-later attack: an adversary captures signed audit data or encrypted traffic today and waits. Your audit trail has to stay trustworthy for years — possibly across the arrival of practical quantum computing.

%%{init: {'flowchart':{'htmlLabels':true,'curve':'basis'}}}%%
flowchart LR
    Today["Today<br/><i>data signed with<br/>classical keys</i>"] --> Harvest["Attacker records it"]
    Harvest --> Wait["…waits years…"]
    Wait --> QC["Quantum computer arrives"]
    QC --> Break["Shor's algorithm<br/>forges / breaks<br/>classical signatures"]
    Today -.->|Smart Engines adds| PQ["Quantum-resistant<br/>attestation alongside"]
    PQ --> Safe["Audit trail still<br/>verifiable & trustworthy"]

🧠 For Normies

Think of it like a letter sealed with a wax stamp everyone trusts today. The “harvest-now” attacker photographs the sealed letter and waits for the day they invent a perfect stamp-forger. Smart Engines adds a second seal, made with quantum-resistant math — so even when the old stamp can be faked, the second seal can still prove the letter is genuine.

---

The fix: NIST-standard lattice cryptography

Post-quantum cryptography (PQC) uses math problems that even quantum computers can’t solve efficiently — for Smart Engines, lattice-based problems standardized by NIST.

🧠 For Normies

A “lattice” problem is like finding the shortest path through an enormous multi-dimensional grid of points. There’s no known shortcut — not for normal computers and not for quantum ones. That “no shortcut” property is what makes the new signatures future-proof.

Two NIST standards matter, doing two different jobs:

Job	Standard	What Smart Engines uses	Where you’ll see it
Signing (prove authenticity)	FIPS 204	ML-DSA-87 (Dilithium5) — highest NIST security level	Live Validator attestations on internal records, such as app-registry listings, app-data writes and BaaS receipts. Enforcement is soft: a missing certificate is logged, not refused.
Encrypting (keep secret)	FIPS 203	ML-KEM (Kyber), in a hybrid with classical encryption	Live The default for the platform’s internal encryption: DKG shares in transit (ML-KEM-1024), app secret envelopes and their key-encryption key, license envelopes, cross-cluster messages, secrets the platform writes to its infrastructure, IPFS access keys and registry admin secrets.

⚠️ Be precise

Two limits apply today. First, each validator’s ML-DSA key is derived by default from its classical ed25519 identity key, so until operators provision independent ML-DSA keys (built, not enabled by default), the attestation is only as strong as ed25519. Second, ML-KEM refuses new legacy-format writes by default, but data sealed before that was enforced can still sit in the older format until it is rewritten. See the security reference for the exact status.

---

What’s actually protected today

Validators attach a quantum-resistant attestation to internal platform records: a quorum of validators each sign the record’s fingerprint with ML-DSA-87, and those signatures are bundled into one certificate you can verify yourself, offline. You check each signature against the validators’ keys as committed in the validators’ signed registry on Hedera HCS — never against the keys the certificate itself carries — so a forged cert with invented signers can’t pass. The SDK’s verifyPqcAttestation and fetchRegistrySnapshotFromMirror do this for you. For the exact anchoring rules, see the security reference.

%%{init: {'sequence':{'showSequenceNumbers':false}}}%%
sequenceDiagram
    autonumber
    participant Artifact
    participant Quorum as Validator quorum
    participant You as You (offline)
    Artifact->>Quorum: here is the fingerprint (sha256) to vouch for
    Quorum->>Quorum: each validator signs with its ML-DSA-87 key
    Quorum->>You: bundle of signatures → one certificate
    You->>You: recompute fingerprint, verify each signature against the HCS registry, count the quorum
    Note over You: No network call to Smart Engines needed — you verify trustlessly.

This connects directly to the platform’s core idea (DKG & TSS): the attestation isn’t one party’s signature — it’s a quorum of validators, the same trust model as everything else here.

🧠 For Normies

Important records come with a tamper-evident receipt signed by many validators using quantum-resistant math. You don’t have to trust Smart Engines — you can check the receipt yourself, on your own machine, without an internet connection.

---

What’s not protected yet — the honest line

The actual signature a blockchain stores still uses that chain’s native curve (Ed25519, secp256k1), because the chain’s own consensus must verify it. So today the quantum-resistant layer is the off-chain attestation trail — not the on-chain ledger signature. Each chain will move to native post-quantum verification on its own timeline; until it does, the validators also attest the hash of each Hedera and XRPL transaction they sign, as a “shadow” PQC certificate that rides alongside the native signature.

🧠 For Normies

The blockchain itself still uses its old-style signatures — Smart Engines can’t change how a public chain checks transactions. What it can do (and does) is keep a separate, quantum-resistant record that proves what happened. When the chains themselves upgrade, the on-chain signatures will follow.

---

Recap

Threat

Quantum computers + Shor’s algorithm break classical blockchain signatures; “harvest now, decrypt later” makes it a today problem for long-lived audit trails.

Fix

NIST lattice cryptography — ML-DSA-87 (FIPS 204) for signing and ML-KEM (FIPS 203), in a hybrid, for internal encryption.

Protected now

A quorum-signed, offline-verifiable PQC attestation on internal records (soft enforcement), and hybrid ML-KEM encryption by default for internal secrets.

Not yet

On-chain ledger signatures stay on native curves until each chain adopts PQC natively. Validator ML-DSA keys are derived from ed25519 by default.

---

Next steps

Post-Quantum Security › Security referenceAlgorithms, the PqcCertV1 cert, offline verification, and the precise enforcement status.

DKG & TSSThe quorum that produces each attestation.

Zero Single-SigThe on-chain guarantee this future-proofs.

GlossaryML-DSA, ML-KEM, lattice, KEM, attestation defined.