← Latest papers
💻 computer science

Resolving an Apparent Key-Dependent Timing Side-Channel in Bouncy Castle ML-DSA-65 Signing: A Pre-Registered Discrimination

This paper demonstrates that an apparent key-dependent timing side-channel in Bouncy Castle's ML-DSA-65 implementation is actually a statistical artifact of natural rejection-sampling variation, which vanishes when timing is analyzed within a pre-registered protocol that conditions on the exact number of iterations performed, thereby confirming the implementation's security across all standardized parameter sets.

Original authors: Arpan Sharma

Published 2026-09-09
📖 7 min read🧠 Deep dive

Original authors: Arpan Sharma

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

In the world of digital security, the most powerful locks are often the ones that take the longest to pick. For decades, mathematicians have designed encryption systems that rely on complex problems to keep data safe. As computers become more powerful, and as the promise of quantum computers looms, scientists are racing to build new locks that even those future machines cannot break. One of the most promising new designs is called ML-DSA. It is a method for creating digital signatures, the electronic equivalent of a handwritten signature on a contract or a certificate. These signatures prove that a message came from a specific person and has not been tampered with.

However, a new kind of danger has emerged alongside these mathematical locks. It is not a flaw in the math itself, but a flaw in how the math is executed on a computer. This is known as a timing side-channel attack. Imagine a safe that clicks slightly louder when the correct combination is entered, or a door that takes a fraction of a second longer to open when the right key is used. If an attacker can measure these tiny differences in time with extreme precision, they might be able to deduce the secret key. For the new ML-DSA system, the designers built in a safety feature: the process involves a lot of trial and error. The computer tries to generate a signature, checks if it is valid, and if it is not, it throws it away and tries again. Because the number of tries varies randomly, the total time it takes to sign a message also varies. This randomness is supposed to hide the secret key, making it impossible to tell if a specific delay was caused by the key or just by bad luck.

A researcher named Arpan Sharma recently investigated whether this safety feature was working as intended in a popular software library called Bouncy Castle. This library is widely used to secure everything from software updates to secure web connections. When Sharma first looked at the data, he saw something that looked like a leak. By comparing the time it took to sign messages with twenty different secret keys, he found that some keys consistently took longer than others. The difference was small—about 1.35 percent—but in the world of security, even a tiny, consistent difference can be a signal that a secret is being revealed. The question was whether this difference was a real vulnerability, a flaw in the code that allowed the secret key to influence the time, or simply a statistical illusion caused by the random nature of the system.

To answer this, Sharma did not rely on a simple guess or a quick test. He designed a rigorous, pre-planned experiment to separate the signal from the noise. The core of his method was to look at the work the computer actually did for every single signature, rather than just looking at the final time. He built a tool that recorded exactly how many times the computer had to try and fail before it found a valid signature. This is crucial because the time it takes to sign a message is directly tied to how many times the computer has to retry. If one key happened to get a "lucky" set of messages that required fewer retries, it would finish faster, not because the key was different, but because the math was easier that day.

Sharma ran a massive campaign, generating over 1.2 million signatures for each of the twenty keys. He then grouped the signatures based on the exact amount of work they required. He asked a simple question: if two signatures required the exact same number of retries and went through the exact same steps, did they still take different amounts of time depending on which key was used? The answer was a definitive no. Once he accounted for the number of retries, the time difference between the keys vanished. The tiny variations that remained were so small that they could be explained by the natural, random fluctuations of the computer's processor and memory, rather than by the secret keys themselves.

The study went further to ensure that the results were not a fluke of the specific computer or the way the software was loaded into memory. Sharma repeated the experiment with a fresh set of keys and a fresh set of messages. He also ran a control test where he shuffled the order in which the computer handled the data. If the timing differences were caused by the secret keys, the order of the keys would not matter. If the differences were caused by where the data landed in the computer's memory, the order would change the results. The experiment showed that the timing differences did not follow the keys; they followed the memory layout. This confirmed that the apparent leak was an artifact of the computer's environment, not a flaw in the security of the code.

The research also looked at the one part of the code that was known to be slightly different depending on the data. The software checks the size of numbers during the process, and if a number is too big, it stops checking the rest of the list immediately. This is a standard optimization to save time, but it means the computer might stop earlier for some inputs than others. Sharma measured the impact of this shortcut and found it contributed a delay of only about one nanosecond. This is a billionth of a second, a time scale so small that it is far below the threshold of what an attacker could realistically measure or use to steal a key.

The findings were applied to the entire family of these new digital signature standards, including the smaller and larger versions used for different security levels. In every case, the result was the same. The software implementation was clean. The apparent differences in timing were not a sign that the secret keys were being leaked. Instead, they were the natural result of a system that is designed to vary its work to protect those very keys. The study concluded that the Bouncy Castle library is safe from this specific type of attack. The 1.35 percent spread in time that initially raised alarms was simply the sound of twenty different keys drawing twenty different samples from a random distribution, a statistical echo rather than a security breach.

This investigation serves as a reminder of how difficult it is to prove that a system is secure. In the past, researchers might have stopped at the first sign of a timing difference and declared a vulnerability. This study shows that in complex, randomized systems, the first sign is often just the system doing its job. By carefully measuring the work performed and controlling for the environment, the researcher was able to distinguish between a real leak and a statistical illusion. The result is a confirmation that the new digital signatures are robust, and that the random variations in their speed are a feature, not a bug. For the millions of devices that rely on these signatures to stay secure, the message is clear: the lock holds, and the time it takes to turn the key tells you nothing about the secret inside.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →