> That's why the vulnerable cases are far more likely to be related to
> *signature* checking. In those you can generally provide both the
> hash input (the message) and the hash target (the purported
> "signature").

I see. I wonder how feasible this attack is, though, since the signature
validation involves a lot of computation (including
hashing the original message), of which comparing the signature
values is but a tiny step.

In addition, for public-key signatures (RSA and DSA), I fail to see the
threat. I can verify the signature offline, so I don't need to rely on
timing attacks to find out what the correct signature would be. Plus
I still need to brute-force the signatures, whether for offline
generation, or in the timing attack, because it's *not* the case
that the expected signature gets compared with the provided signature.
Instead, something derived from the message gets compared with something
derived from the purported signature.

It's really only HMAC which may be vulnerable. In

http://seb.dbzteam.org/crypto/python-oauth-timing-hmac.pdf

the author discusses that the real protection against this attack is
to fix the actual bugs in the OAuth implementation (when OAuth is
designed to prevent replay attacks which would also prevent this
attack). In the end, he claims that using time-independent comparison
would "add even more security", but in the same hand-waving fashion
shown in this issue (i.e. without providing any proof that his proposed
attack actually works - which I claim it won't, due to the noise
caused by the HMAC generation).