Martin v. Löwis <mar...@v.loewis.de> added the comment: > 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). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
