NIST picks HQC: a second, backup post-quantum encryption algorithm - init.d
IT

# NIST picks HQC: a second, backup post-quantum encryption algorithm

Alessandro Corbelli~7 min read min
Table of Contents

On March 11, 2025, NIST, the U.S. body that defines many of the security standards used around the world, announced its choice of a new encryption algorithm called HQC. The acronym is a mouthful, but the idea is simple: HQC will act as a backup for protecting data against a future threat, sitting alongside an algorithm chosen earlier. It’s worth understanding what that means, what it protects against, and why having a second algorithm, rather than just one, is a sensible decision.

The news in brief

For several years NIST has run a public effort to select algorithms for post-quantum cryptography, meaning encryption methods designed to hold up even against a kind of computer that doesn’t yet exist in usable form. The first standards in this new family were published in 2024. Now another one joins them: HQC, chosen as a backup algorithm for encryption.

The key word here is “backup.” HQC doesn’t replace anything. The main algorithm for encryption remains ML-KEM, already standardized. HQC stands beside it as a second option, kept ready in case the first one shows weaknesses down the road. It’s the fifth algorithm NIST has selected on this path, and the second one aimed specifically at protecting data in transit.

The problem: the threat from quantum computers

To see why any of this is needed, start with the threat. Today most of what we do online is protected by cryptography: when the padlock appears in your browser, the data exchanged between your device and the site is scrambled so anyone intercepting it can’t read it. That protection holds because today’s computers don’t have the power to break it in any reasonable amount of time.

Quantum computers are a developing technology, built on physical principles different from those of ordinary computers. In theory, a powerful enough machine of this kind could one day break much of the cryptography we rely on now. Nobody knows for certain whether or when that moment will arrive: expert estimates range from more than a decade to several decades away.

There’s still a reason not to wait. Anyone intercepting encrypted traffic today can store and archive it, waiting to decrypt it once the technology allows. This strategy has a name, “harvest now, decrypt later.” It means data meant to stay sensitive for years is already at risk today, even though the machine capable of unlocking it doesn’t exist yet. That’s why adopting resistant algorithms early matters, the same reason Chrome started enabling post-quantum key exchange by default on TLS connections.

What HQC is, and what it’s built on

HQC stands for Hamming Quasi-Cyclic. It’s a key encapsulation mechanism (KEM): put simply, it handles the opening moment of a secure connection, when two parties need to agree on a shared secret key without anyone else being able to discover it. That key is then used to encrypt everything else in the conversation. This step is the one most exposed to the “harvest now, decrypt later” strategy, so it’s the first thing to secure.

What makes HQC distinctive is the math it rests on. Every modern encryption algorithm relies on a mathematical problem believed to be very hard to solve. HQC is built on error-correcting codes: techniques originally created to detect and fix errors in data as it’s transmitted or stored, used for decades in areas like satellite communications, older CDs, and QR codes. From that principle you can derive a hard mathematical problem to build the protection on.

Here lies the important difference from ML-KEM, the main algorithm. ML-KEM rests on a different area of math, called structured lattices. Two algorithms, two different mathematical foundations. That’s not a minor detail, as we’ll see.

Why have an alternative: crypto-agility

The reason NIST chose a second algorithm, and one built on different math at that, comes down to caution. These algorithms are relatively new. They’ve been studied hard by experts worldwide, but no one can completely rule out that a weakness might be found in the future. The history of cryptography is full of methods once thought solid and later broken.

The most insidious risk is a systemic one. If every available algorithm rested on the same mathematical principle, a single discovery that cracked that principle would put the whole system in jeopardy all at once. Having an alternative built on independent foundations reduces that danger: if a problem ever emerged with the lattices behind ML-KEM, HQC would be ready, and it uses no lattices at all. And vice versa. The head of NIST’s post-quantum project explained the choice in just those terms: it helps to have a backup standard based on a different math approach, in case the first one one day turns out to be vulnerable.

This way of thinking has a name: crypto-agility, the ability to switch algorithms without having to rebuild everything from scratch. A system designed to be agile can move from one encryption method to another with relative ease as circumstances change. It’s not a flashy quality, but it’s what lets you react quickly if something goes wrong, rather than being stuck with a single solution.

Where things stand: timing and status

It’s worth being precise on one point: the choice of HQC is the start of a process, not the end. At the time of the announcement there was no ready-to-use standard yet.

NIST has laid out a roadmap. A draft standard is expected within about a year of the announcement, so roughly in 2026. Once the draft is published, a public comment period of about 90 days follows, during which anyone can flag problems or propose changes. Only then does the final version arrive, expected around 2027. Until that point HQC isn’t an algorithm to put into production, but a settled choice whose standardization path has been announced.

One honest technical detail is worth adding: at a comparable level of security, HQC tends to require more computing resources than ML-KEM. That’s one reason it stays the second option rather than the first. It isn’t meant to replace the main algorithm in everyday use, but to exist as a reliable alternative on different foundations.

What changes in practice

For most people, right now, nothing changes immediately. There’s no action to take and no software to update by hand because of HQC. The move to post-quantum cryptography is a long process, happening mostly behind the scenes, in the updates to browsers, operating systems, and libraries, a process already measurable: a growing share of web traffic already runs on post-quantum cryptography.

For those who design or run systems, though, there’s a principle to keep in mind: don’t concentrate everything on a single algorithm. The takeaway from this news is precisely crypto-agility. An infrastructure built so it can switch encryption methods in the future, without rewriting half the system, will be far easier to adapt as standards evolve, the same principle behind shortening the lifespan of TLS certificates to limit the damage when something goes wrong. There’s no need to rush to adopt HQC today, but it’s worth building in a way that lets you do so tomorrow without pain.

In short

NIST has chosen HQC as a backup post-quantum encryption algorithm, to sit alongside ML-KEM. Its main feature is the math it’s built on, error-correcting codes, different from that of the main algorithm. That difference is the point: having two independent foundations makes the system more resilient over time, because a single discovery couldn’t bring them both down together. The actual standard will arrive over the coming years, with a draft expected in 2026 and a final version around 2027. In the meantime, the lesson useful to everyone is simple: in security, having a plan B built on different foundations isn’t a luxury, it’s prudence.

Sources

Tux versione Gandalf, mascotte del blog init.d

init.d is the team led by Alessandro Corbelli, a Linux systems administrator and backend developer with over twenty years of experience. He designs and runs cloud infrastructure (Google Cloud, AWS, Azure), server farms and high-availability architectures, and builds custom software in Laravel/PHP and Vue - from the Take2Me food delivery platform to our clients’ management tools. On this blog we share technical notes on Linux, system administration, development, DevOps and e-commerce.


More Posts