Earlier this year, RELI Group’s CTO Atul Singh wrote in Quantum Computing: The Impact on Software Application Design that software teams should start treating encryption as a swappable component instead of a tightly integrated function. But what does swapping encryption actually mean?
To understand the practical implications, we tested the approach in RELI Labs. We took a production-grade identity server, the kind that handles logins for dozens of applications at a federal agency and replaced the cryptography that signs its login credentials with a new post-quantum standard.
It worked. Users sign in exactly as they did before, and because the change is a configuration setting, we can undo it the same way we turned it on.
What surprised us was where the work went. Selecting the signature algorithm and connecting it was a small part of the job. Roughly four-fifths of the effort went into the system around it: how the identity server publishes its public keys, how other parts of the same product read credentials it has just issued, and how those larger credentials fit existing session and cookie limits. Those are architecture and integration problems which is also why authentication is the place to start.
Why Authentication Comes First
Authentication is the system that checks who a user is and then issues a signed credential. When you sign in, that credential works like a visitor’s badge with a tamper-proof seal. The badge says who you are, and every application you open afterward checks the seal instead of asking for your password again.
Today that seal is created with mathematics that a large enough quantum computer will be able to break. Someone who can break it can forge a badge and sign in as anyone they choose, including an administrator. On a federal health or national security system, that impersonation reaches every application that trusts the same identity server.
The timeline has already been published. NIST’s draft transition guidance phases out today’s public-key cryptography around 2030 and bars it by 2035.
Authentication is the right place to start, for a practical reason. One identity server usually handles logins for many applications at once. That gives it the widest reach if something goes wrong, and it is the slowest piece to upgrade. Update the identity server, and every application behind it benefits from the same change. As other RELI experts have written, identity and access management and Zero Trust are now essential for enterprise IT, because authentication is where security decisions add up fastest.
Post-quantum cryptography is ordinary mathematics running on ordinary computers, built so a quantum computer gains no advantage against it. This project used no quantum hardware. Readers who want the background on quantum computers themselves can start with Jason Balser’s What is Quantum Computing?, which explains why those machines are specialized tools rather than general-purpose replacements for the computers agencies already run. The work in this piece is the defense that runs on those existing computers.
Where the Real Problems Showed Up
The mathematics behind it turned out to be the easy part. We used ML-DSA-65, a parameter set of ML-DSA, the NIST digital-signature standard published as FIPS 204. A well-tested open-source library, “BouncyCastle”, already implemented it, and the identity server already included that library. Connecting ML-DSA-65 to the login process took a modest amount of code, and it worked almost right away.
The trouble started when we tried to use it.
First, the server stopped publishing its new public key. Every application needs that key to check a signature, and ours never appeared. There was no error message and no log entry. The code that publishes keys recognized three types of keys and silently discarded anything else. Post-quantum keys are a fourth type.
Second, one of the server’s own internal features began rejecting credentials it had issued moments earlier. The signing process had been built to accept new algorithms, but an older piece of the same product checked tokens against a fixed list, and that list could not be extended. From the outside, it looked like a cryptography problem. However, it was really a compatibility problem.
Neither failure involved cryptography. Both happened where one part of the system passes information to another, and that pattern makes sense in hindsight. An algorithm is self-contained and easy to test on its own, but the connections between components are where old assumptions live. When this software was written, only three kinds of key were in common use, so nobody wrote that assumption down. Post-quantum cryptography changes that, and every place the old assumption was built in quietly becomes a defect.
Size Is the Real Constraint, Not Speed
The first question people ask is about performance, and it is worth answering before it shapes the plan. In our testing, ML-DSA-65 signed credentials faster than the RSA method it replaced, RS256. Checking the signature was slightly slower on a full login. Both finished in well under a millisecond, which a person signing in would not notice. Speed does not change the shape of the project.
The real constraint is the size. In our measurements, ML-DSA-65 signatures were about thirteen times larger than the RSA signatures they replaced, roughly 3.3 kilobytes versus 256 bytes, and full login credentials grew about five times, to roughly 5 kilobytes. That growth shows up in predictable places: limits on how much data a proxy will accept in a request header, how sessions are designed, and one hard ceiling. Web browsers cap a single cookie at about 4 kilobytes, so a post-quantum credential of about 5 kilobytes does not fit. Applications that keep the login credential in a cookie must store that credential on the server and leave the browser with a small session identifier. The person signing in still does so once. The change is in session design.
The same size question comes up again as post-quantum credentials are phased in over the next several years. Cookies, tokens placed in a web address, and several tokens forwarded together between services each need a plan. A single credential in a request header still fits the limits of common proxies to use, often 8 kilobytes. The session change is separate from the signature change.
Every Place Cryptography Is Used
Changing how credentials are signed protects against forgery: someone creating a fake credential that looks genuine. That is the problem this project took on.
Changing the signature leaves every other use of cryptography to be planned on its own. Encrypted connections between a browser and a server address a different risk, sometimes called harvest now, decrypt later, in which attackers record encrypted traffic today and decrypt it years from now. Much of that transport fix will arrive through routine browser and platform updates. Database encryption, application code that encrypts sensitive fields before they are stored, and the security tokens systems exchange with one another are separate decisions. Each needs its own answer. A review of a large application must find all of them, because a signature migration does not carry the others with it.
An agency that treats the signature change as the whole quantum problem will stop looking for the rest. Reviewing a large enterprise application means tracing each use: login credentials, tokens passed between services, cookies and session stores, database encryption, and older application code that encrypts sensitive data on its own. Choosing an algorithm is a smaller task than finding every place one is in use.
What Agencies Should Do Now
The most useful step an agency can take this quarter is an afternoon’s worth of effort, not a budget cycle. For each major application, ask one question: is the cryptographic algorithm chosen by a configuration setting, or is it written directly into the code?
If it is a configuration setting, migration is mostly a matter of changing that setting, and your vendor may eventually handle it for you. If the algorithm is built into the application’s logic, migration becomes a development project. That answer is the difference between a two-week effort and a six-month one, and you can usually find it in a day.
Two smaller steps are worth the same afternoon. Inventory your public-key cryptography specifically, since only public-key methods such as RSA and elliptic curve fail. Symmetric encryption and hashing are broadly safe, because quantum computers weaken them rather than break them. That distinction removes most of the apparent scope from a project that can look overwhelming. And if any application authenticates through infrastructure, nobody has meaningfully updated in a decade, start there, because that lead time is the longest you will face.
Building the Ability to Change Again
It would be a mistake to read this as a story about an algorithm. NIST spent eight years selecting these standards and broke several promising candidates along the way, so today’s standard may itself be replaced one day.
That is why the real goal is not any single algorithm. It is the ability to change algorithms when you need to. The agencies that struggle in 2030 will not be the ones that chose the wrong algorithm. They will be the ones that find out too late that they cannot change algorithms at all without rewriting the application.
This is the kind of question RELI Labs exists to answer before it reaches a customer’s roadmap. We take a real system, migrate it, and learn where the work actually is. The standards are published and the libraries exist. What remains is engineering, and engineering rewards the teams that start before the deadline decides for them.
