constant-time-testing

Start with dudect, which measures execution time for fixed versus random input classes and applies Welch's t-test to detect statistically significant differences. If leakage appears, use Timecop with Valgrind to pinpoint the exact line where secret data influences branching or memory access.

dudect performs statistical testing on real compiled binaries, detecting timing differences without identifying root causes. Timecop wraps Valgrind to trace poisoned secret memory at runtime, pinpointing exact leak locations but only covering executed paths and missing microarchitectural effects.

Four patterns cause most leaks: conditional branches on secrets, secret-dependent array indexing enabling cache-timing attacks, integer division with secret operands, and variable-time shift operations. Modular exponentiation with square-and-multiply is a classic vulnerable construction.

Yes. Brumley and Boneh demonstrated remote extraction of RSA private keys from OpenSSL by measuring network-observable timing differences in Montgomery multiplication. Sufficient query access to a timing oracle plus secret-dependent execution time enables practical remote attacks.

Short runs under one minute collect insufficient measurements for weak timing signals to reach statistical significance. Run dudect for five to ten minutes minimum, pin it to an isolated CPU core with taskset, and test at production optimization levels like -O3.

Use formal tools like ct-verif, SideTrail, or FaCT when you need mathematical proof of leak absence for high-assurance code. Statistical tools like dudect only provide confidence levels and cannot guarantee absence of leaks, while formal methods require more expertise and modeling effort.