Comparative Timing Characterization of Early-Exit and Fixed-Work Secret Comparisons on ESP32 and ESP8266

In the hidden world of computer security, there is a quiet danger that has nothing to do with broken locks or stolen keys. It is about time. When a computer checks if a secret code matches a password, it usually does so by comparing the two strings of characters one by one. If the first letter is wrong, a standard program stops immediately and says "no." If the first ten letters are right and the eleventh is wrong, the program keeps working until it finds that mistake. This difference in how long the computer takes to think can be a leak. A skilled observer, watching how long a response takes, could theoretically count the seconds to figure out how many letters were correct before the mistake happened. This is known as a timing side channel, a way of stealing information not by breaking the code, but by listening to the clock. For decades, security experts have warned that software must be written to take the exact same amount of time regardless of where the mistake occurs, a practice called constant-time programming. But on the tiny, inexpensive chips that power everything from smart home devices to simple sensors, it is not always clear if these rules hold up in the real world, or if the hardware itself introduces new surprises.

A recent study set out to test this reality on two of the most common microchips found in the world: the ESP32 and the ESP8266. These chips are the brains behind countless affordable internet-connected devices. The researcher, working alone, built two different ways for these chips to compare secret 16-byte codes. The first method was the standard, vulnerable approach: it would stop as soon as it found a mismatch. The second method was the "fixed-work" approach, designed to be secure: it would force the chip to check every single byte of the input, no matter how early a mistake appeared, ensuring the total time remained the same. To see how these methods behaved, the researcher sent thousands of test codes to the chips. Each test code was crafted to match the secret password for a specific number of letters at the start—sometimes none, sometimes all sixteen—before deviating. The chips measured their own internal clock cycles to record exactly how long each comparison took, repeating the process hundreds of times for every possible starting length.

The results painted a clear picture of the vulnerability in the standard method. On the faster ESP32 chip, every time the test code matched one more letter of the secret before failing, the chip took exactly forty more clock cycles to finish the job. On the slower ESP8266, the delay was twenty-five cycles per extra matching letter. This created a perfect, predictable staircase of time. If the code matched zero letters, the chip finished quickly; if it matched fifteen, it took significantly longer. In fact, the timing was so consistent that in many of the test groups, every single one of the three hundred attempts produced the exact same clock count. For the ESP32, a single measurement of the time taken was enough to tell the researcher exactly how many letters matched the secret in that specific session. This confirmed that the standard "stop early" method leaks information directly through the time it takes to run.

In contrast, the fixed-work method behaved exactly as security experts hope it would. When the researcher used the version that forced the chip to check all sixteen bytes, the time it took did not change based on how many letters matched. Whether the test code failed on the very first letter or the very last, the chip spent the same amount of time processing the data. The median time remained flat across all scenarios. However, the study also revealed a cost to this safety. The fixed-work method always took longer than the vulnerable method, especially when the test code failed immediately. On the ESP32, the secure method took nearly eight hundred cycles even when the first letter was wrong, whereas the vulnerable method finished in less than seventy cycles. The secure method essentially wasted time checking the rest of the letters to ensure the total duration stayed constant. This trade-off between speed and security is a fundamental reality of embedded systems, where every extra cycle of processing drains a battery or slows down a device.

The study also uncovered some unexpected quirks in how these chips behave under pressure. While the average times were stable, a small number of individual measurements were much higher than the rest, jumping to nearly double or triple the expected time. These spikes happened mostly when the chips were allowed to handle normal background interruptions, rather than when they were isolated in a quiet state. This suggests that while the core logic of the secure code works, the surrounding environment of the chip can still cause occasional, unpredictable delays. The researcher noted that these measurements were taken directly inside the chip's own memory, not over a network, meaning that while the timing leak is real and measurable on the device, it does not automatically prove that a hacker could steal a password from across the internet. The noise of a real-world connection would likely hide these subtle differences.

Ultimately, this research provides a concrete map of how timing leaks appear on specific, widely used hardware. It shows that the simple act of stopping a comparison early creates a precise, measurable signal that reveals the secret. It also demonstrates that a simple change in code—forcing the computer to finish the job regardless of the result—can eliminate that signal, though it comes with a performance penalty. The findings are a reminder that in the world of embedded security, the way a program is written matters just as much as the math it uses. The chips did exactly what they were told to do, and in doing so, they revealed that without careful design, even the most basic operations can whisper secrets to anyone listening to the clock.