Quantum-safe encryption still has an ordinary-computer problem

A device can use cryptography designed to withstand a future quantum computer and still reveal secrets through the ordinary chip running it. Differences in execution time, memory access or power consumption can create clues that the mathematical description of an algorithm does not capture.^[3]

That gap is the focus of EQUIP, a European research project whose grant period began on November 1. With an EU contribution of €2,911,175, it plans to develop and test post-quantum implementations across embedded devices, programmable chips and conventional processors. Its intended applications include connected devices, vehicles and cloud systems.^[1]

The practical question is straightforward: when a product is described as quantum-safe, what evidence supports the safety of the product itself?

Three different things need checking

Start with the algorithm. NIST’s ML-KEM standard specifies a way for two parties to establish a shared secret over a public channel. That secret can then support encryption and authentication. Its security is related to the difficulty of a mathematical problem involving structured lattices.^[2]

Next comes the software that implements those instructions. Finally comes the physical machine executing the software. Evidence about the first layer does not automatically settle the other two.

Consider a program that takes slightly different amounts of time depending on sensitive values it processes. The intended answer might reveal nothing useful. The time taken to produce it can still reveal information.^[3]

A survey by James Howe, Thomas Prest and Daniel Apon describes weaknesses involving secret-dependent branches and memory access. It recommends checking sensitive operations after compilation, the translation of source code into machine instructions. Reviewing the programmer’s original code alone can miss important behavior.^[3]

A real example, not a newly discovered emergency

The KyberSlash research provides a concrete historical illustration. Its authors reported timing vulnerabilities in several implementations of Kyber, the scheme from which ML-KEM was developed. Division operations could take different amounts of time depending on their inputs in particular computing environments.^[4]

The problem was in implementations and their execution environment. The researchers reported demonstrations on Raspberry Pi 2 and Arm Cortex-M4 platforms, and said maintainers patched the disclosed vulnerabilities. These findings are not evidence that every present-day ML-KEM product is vulnerable. Nor do they establish that an arbitrary remote attacker can compromise any such device.^[4]

The example makes an evaluation more specific. “We tested a quantum-safe algorithm” leaves open which version of the software ran, what translated it into machine instructions, and which processor executed those instructions. Those details can change what a test establishes.

What EQUIP plans to add

EQUIP proposes a repeated cycle of designing implementations, testing them and analyzing attacks, with open-source demonstrators among its planned outputs. KU Leuven’s project record confirms the three-year period ending October 31, 2029.^[1][5]

The work also includes fault attacks: deliberately disturbing a computation and examining the consequences. That differs from passively observing leakage. Testing one kind of exposure does not establish resistance to every other kind.^[3]

Three questions to take into a purchasing meeting

For a buyer or engineering manager, three questions make a broad claim easier to evaluate.

Which mathematics? Ask for the algorithm, parameters and standard. This identifies the cryptographic construction the supplier intends to use, rather than relying on the phrase “quantum-safe.”

Which implementation? Ask for the software version, compiler and hardware configuration actually evaluated. A report about one configuration should not silently become evidence for every device carrying the same product-family name.

Which attacker? Ask what access the testing assumed: remote observations, access to the same machine, physical measurements or deliberate disturbances. Different access assumptions describe different risks and demand different evidence.

This is an editorial checklist, not a certification scheme. A useful answer includes the limits of the evaluation, not just a pass label. That gives a purchaser something concrete to compare with the environment where the device will be used.

QubitWire’s earlier SEALSQ implementation-security coverage separated a conference announcement from conclusions that required the full paper. EQUIP poses a different question: how can testing become a repeatable part of deploying post-quantum systems?

The project has only just started. Its grant objectives do not establish completed protections, certified products or successful attack resistance. The useful milestone to watch is the release of demonstrators and evaluation results detailed enough for others to inspect.^[1]

Preparing for quantum computers includes checking the ordinary computers already doing the work.