Although he doesn't say it, I assume he has suppressed warnings about plain uninitialized memory reads since his system will generate spurious warnings even for safe, constant-time comparisons.<p>The thing the author probably doesn't realize is that his approach only helps with the simplest of operations like his target compare loop. With an RSA implementation, <i>all</i> versions would be tagged as vulnerable.<p>This shows up at the end of his post where he flags BN_mod_exp_mont_consttime() as vulnerable. The reason this code is safer (not safe) against side-channel attacks is that it takes advantage of cache layout of x86 processors to ensure that indexed accesses do not reveal private information. His approach also won't be able to model more complex countermeasures such as blinding. It will always flag them as vulnerable.<p>I don't understand why this needs valgrind (dynamic analysis). You can do a fully static analysis by storing the address of your safe_compare() routine, then disassembling starting at that function until it returns. If you hit a branch instruction before, flag an error. This could be one of your pre-commit checks for the repo.<p>In other words, this is not useful for finding timing attacks, it's useful for detecting regression.