A Promise About Later: Why Mickai Signs the Past With ML-DSA-65

A signature is a promise about time

Here is the uncomfortable thing about a digital signature. It is not a promise about now. It is a promise about later. When a system signs a record, it is making a claim that someone, possibly years into the future, will be able to check that the record has not changed and that it came from the key it says it came from. The whole value of the signature lives in that future moment of verification. So when I choose a signature scheme for the Open Audit Record (OAR) inside Mickai, I am not really choosing an algorithm. I am placing a bet on how long the promise has to hold, and against whom.

That framing matters because the adversary has changed. For thirty years the working assumption behind public-key cryptography was that the mathematics underneath the common schemes (the difficulty of factoring large numbers, or of solving discrete logarithms over elliptic curves) was hard enough that no realistic computer could break it inside a human lifetime. A sufficiently capable quantum computer breaks that assumption, not by being faster, but by running an algorithm that turns those specific hard problems into easy ones. That is the part people skip past. It is not a speed-up. It is a category change for two of the most widely deployed families of signatures and key exchanges on the internet.

I want to be honest that this is not an abstract worry I dressed up to sell a feature. Mickai is a Sovereign Intelligence Operating System (SIOS), built and running in production, whose single most important job is to keep a trustworthy account of what an artificial intelligence (AI) did. The only part of the stack we are still building is the Pantheon chain. Everything else, including the audit record, is live. That means the decision about which signature secures the record is not a roadmap item I can revisit at leisure. It is load-bearing today, and it has to stay load-bearing in a decade I cannot see.

Harvest now, decrypt later, and its quieter cousin

You have probably heard the phrase harvest now, decrypt later. An attacker records encrypted traffic today, stores it cheaply, and waits for the hardware that can break it. Confidentiality has an expiry date the moment it is captured. That is real, and it is the reason post-quantum key exchange is being rolled into browsers and virtual private networks (VPNs) already, ahead of the machines that would justify it. But there is a quieter cousin to that attack that gets less attention, and it is the one that keeps me up at night, because Mickai is an audit system before it is anything else.

Call it forge later. If the signature on a record can be broken in some future year, then in that year an attacker can manufacture a record that looks like it was signed in 2026, with a key that was trusted in 2026, and present it as authentic history. Confidentiality protects a secret until it leaks. A signature protects the integrity of the past indefinitely, which means a broken signature scheme does not just expose old secrets, it lets someone rewrite what supposedly happened. For a system whose entire reason to exist is a trustworthy, append-only account of what an AI did and when, that is the failure I cannot accept.

The asymmetry between the two attacks is the whole point. With confidentiality, once a secret is old enough to be useless, breaking its encryption later is a hollow victory. Nobody cares about last decade's session keys. But an audit record gets more valuable as it ages, not less, because the further back you can prove what happened, the more weight the proof carries in a dispute, a regulatory review, or a court. The forge-later attack therefore targets exactly the records you most need to defend. The audit record has to outlast the cryptography that protects competing systems, and it has to do it without asking anyone to trust the vendor that produced it.

Why a standard, and why this one

In August 2024 the United States National Institute of Standards and Technology (NIST) published its first finalised post-quantum standards. Among them was Federal Information Processing Standard 204 (FIPS 204), which specifies the Module-Lattice-Based Digital Signature Algorithm (ML-DSA). The scheme grew out of an academic design called CRYSTALS-Dilithium, refined and pinned down through a multi-year public competition where the world's cryptanalysts were openly invited to break the candidates. ML-DSA-65 is the middle of the three parameter sets in that standard, sitting at the security level NIST labels Category 3, which is intended to be at least as hard to break as a 192-bit symmetric cipher.

I want to be plain about why a published standard matters more than a clever algorithm. Cryptography is not a field where you want to be original. Original means unreviewed. The value of FIPS 204 is not that NIST invented something brilliant, it is that the design survived years of adversarial public scrutiny, has a fixed specification down to the byte, and has independent implementations that can be tested against shared test vectors. When I anchor the OAR to ML-DSA-65, I am borrowing the accumulated suspicion of the entire cryptographic community. That is worth far more than any single team's confidence, including mine.

There is a second reason a standard matters that has nothing to do with mathematics, and it is regulatory. The direction of travel for serious institutions is toward post-quantum migration as a stated requirement, not a nice-to-have, and the regimes tightening around high-risk AI (the European Union (EU) AI Act brings its high-risk obligations into force from August 2026) increasingly expect durable, verifiable records of automated decisions. When the record is signed with a named, published government standard rather than a proprietary scheme of our own, an auditor or regulator does not have to take our word for what protects it. They can point at the same specification everyone else points at. A bespoke signature, however elegant, would put us in the position of explaining and defending our own homework. A standard lets the homework defend itself.

What lattices actually buy you

The hard problem under ML-DSA is not factoring and it is not elliptic curves. It is a problem from lattice theory, roughly the difficulty of finding short vectors in a high-dimensional lattice, expressed through what cryptographers call the Module Learning With Errors problem. You do not need the linear algebra to grasp the strategic point. The reason lattice schemes are interesting is that the known quantum algorithm that demolishes factoring and discrete logarithms (Shor's algorithm) does not apply to them. The structured shortcut that quantum computing offers against the old schemes simply is not known to exist here.

That is a careful sentence and I will not dress it up. We do not have a mathematical proof that lattice problems are hard for quantum computers. We have a strong absence of attacks despite enormous, sustained, well-funded effort to find one. In cryptography that is the normal state of confidence. The schemes we trusted for decades were trusted on exactly the same basis, an absence of breaks rather than a proof of impossibility. The honest claim is not that ML-DSA is unbreakable. It is that it moves the bet from a problem we know is quantum-vulnerable to one that, after intense public review, shows no sign of being so. You do not get certainty in this field. You get the best-reviewed wager available, and you take it early.

The price you pay, stated honestly

Lattice signatures are not free, and anyone selling them as a drop-in upgrade with no cost is not being straight with you. An elliptic-curve signature of the kind that has secured the web for years is tiny, on the order of sixty-four bytes, with comparably small keys. An ML-DSA-65 signature is several thousand bytes, and its public key is larger again, well over a kilobyte. In round terms a single post-quantum signature can be many times the size of the classical one it replaces. Verification is fast, which matters for an audit log that gets checked far more often than it gets written, but the records are heavier and the keys are bulkier.

For most of the internet that bloat is a genuine engineering headache. It inflates every handshake, every certificate chain, every constrained device that has to hold a key in a few kilobytes of memory. I am not going to pretend that away. But here is why the trade lands differently for an audit record than it does for a billion web handshakes. The OAR is written once and meant to be verifiable forever. The cost of a larger signature is paid one time, at the moment of writing. The benefit, a record that does not become forgeable the day a quantum computer is switched on, is collected across the entire future lifetime of that record. When the asset you are protecting is the integrity of history itself, a few extra kilobytes per entry is the cheapest insurance I have ever bought.

It helps that the OAR runs on hardware we control rather than on a thumbnail-sized sensor at the edge of someone's network. The fifty brains of Mickai, twenty-five domain and twenty-five operational, sit on the Poseidon silicon substrate, where storage and verification cycles are abundant. The places where post-quantum signatures genuinely hurt are the places with no room to spare. An audit substrate built on purpose to hold a permanent record is precisely where you can afford the heavier scheme, so we chose the parameter set for durability rather than for thrift, and the budget absorbs it without complaint.

Sign before you act, not after

There is a design decision in Mickai that is easy to miss and does most of the real work, and it is upstream of which algorithm we picked. In the OAR, every AI action is signed before it executes, not logged after. That ordering is the whole game. Most systems treat the log as a description of what happened, written once the thing is already done. A description written after the fact is a story, and stories can be edited by whoever controls the pen. By signing the intended action first, and only then carrying it out, the record stops being a retrospective account and becomes a precondition. There is no action without a signed, sealed entry that came first.

Then those entries are hash-chained, each one cryptographically bound to the one before it, so the log is append-only in a way you can check rather than merely promise. You cannot quietly remove entry forty without breaking the chain at forty-one, and you cannot rewrite entry forty without invalidating its signature. ML-DSA-65 is what makes each link in that chain a post-quantum-durable commitment. The lattice signature is not decoration on top of a logging feature. It is the thing that makes sign-before-execute mean something a decade from now, when the keys that signed those early entries are long retired and the only thing standing between you and a forged history is whether the mathematics still holds.

Offline, in an ordinary browser, with no trust in me

The property I am proudest of is the one that sounds least impressive until you sit with it. The OAR is verifiable offline, in an ordinary browser, with no trust in the vendor. No call home to a Mickai server. No licence check. No proprietary tool that we control and could change. You take the record, you take the public key, you run the verification, and the mathematics either holds or it does not. This is the point where the choice of a published standard pays off in full, because ML-DSA-65 has independent open implementations. The verifier does not have to be ours. It can be anyone's, audited by anyone, and it will reach the same answer.

This is the difference between trust me and check for yourself, and it is not a slogan. Plenty of audit and compliance products will show you a dashboard, green ticks rendered by the same company whose behaviour you are trying to audit. That is a conflict of interest dressed as assurance. If the only way to verify a record is to ask the vendor whether it is valid, you have not verified anything, you have received a press release. A signed, offline-checkable record inverts that relationship. The vendor cannot lie about the record without the mathematics catching them, and the person checking does not need permission, a connection, or faith. They need a public key and a few minutes.

I will put my own money where that claim is, because the architecture is not just an idea. The portfolio behind Mickai is 101 filed United Kingdom patent applications, about 2,234 claims, owned by Mickai LTD with me named as inventor, and the audit mechanism is described in those filings rather than hidden as a trade secret. We are also actively training our own models now, fine-tuning and specialising open foundations (Llama 3.2 and Qwen 2.5) and building a sealed corpus, with funding scaling the work toward fully native weights. None of that changes the verification story by a single byte. Whatever the brain inside, the record it produces is checkable against published mathematics by someone who owes us nothing.

How long does ML-DSA-65 actually protect you

The honest answer has two layers. The first is the protection horizon. Nobody can hand you a date for a cryptographically relevant quantum computer, and anyone who gives you a confident year is guessing. What we can say is that the migration is being treated as urgent by serious institutions precisely because the timeline is uncertain and the harvest-and-forge attacks work retroactively. Choosing a Category 3 parameter set rather than the minimum is a deliberate margin. It costs more bytes for a deeper safety buffer, on the reasoning that an audit record needs to survive not just the first quantum computer but decades of improvement after it.

The second layer is the one nobody likes to print. No signature scheme is forever. Cryptography is a living field, and the responsible assumption is that ML-DSA will itself one day be superseded, whether by a quantum advance, a lattice breakthrough, or simply a better-reviewed successor. That is not a flaw in the plan, it is the plan. What protects the OAR across that horizon is not faith that one algorithm is eternal, it is that the record format is built to migrate. Because every entry is signed and chained, you can re-anchor and re-sign the historical record under a new scheme before the old one weakens, carrying the verified past forward intact. The durable thing is not the algorithm. It is the discipline of a signed, append-only, independently checkable record that can change its locks without losing its history.

Where the record finally rests

All of this lives on real ground. The fifty brains of Mickai run on the Poseidon silicon substrate, and every action they take is sealed into the OAR before it runs. Above that sits Pantheon, the sovereign Layer 1 we are building to anchor the audit root to Bitcoin, so that the chain of signed records is itself pinned to the most expensive-to-rewrite ledger humanity has produced. Pantheon carries its own token, PAN, with a fixed supply of five billion. The post-quantum signature secures each individual link. The anchoring secures the chain as a whole. Neither layer asks you to trust us, and that is the design intent, not an accident of it.

I will close on the bet I started with, because it is the right place to land. A signature is a promise about a future moment of verification, and the only signatures worth making are the ones you expect that future to honour. We could have shipped the small, familiar, classical signature and let the audit record quietly inherit an expiry date that no customer would notice until the day it mattered. We chose the heavier, newer, standardised lattice scheme instead, paid the bytes, and accepted the honest caveat that even this will one day need replacing. The reward is a record of what an artificial intelligence did that an ordinary person can check, offline, years from now, against mathematics that the whole world has been invited to break and has not. That is the only kind of trust I am willing to sell, the kind you do not have to take on my word.