constant-time-testing

Start with dudect statistical testing by writing a harness that compares execution time between fixed and random input classes using Welch's t-test. If leakage is detected, use Timecop with Valgrind to poison secret variables and pinpoint the exact line causing the timing dependency.

Four patterns cause most timing vulnerabilities: conditional branches on secret data, secret-dependent array lookups enabling cache-timing attacks, variable-time integer division, and variable-time shift operations. Conditional jumps cause the most severe timing differences.

dudect performs statistical timing measurement on real compiled binaries but provides no root cause information. Timecop uses Valgrind dynamic tracing to pinpoint the exact line of a leak but cannot detect microarchitecture timing differences and only covers executed paths.

Yes, Brumley and Boneh demonstrated remote extraction of RSA private keys from OpenSSL using network-observable timing differences in Montgomery multiplication. Exploitation requires oracle access through sufficient queries and a timing dependency correlated with secret data.

Compiler optimizations at levels like -O3 can introduce branches or remove constant-time constructs, so inspect assembly output with objdump. Also test on the target CPU architecture, pin tests to an isolated core with taskset, and run measurements for at least 5-10 minutes.

Statistical tools like dudect cannot guarantee absence of leaks, only provide confidence levels, and give no root cause information when leakage is found. Measurement noise can obscure weak signals, so for high assurance combine with formal verification tools like ct-verif or SideTrail.