[issue15061] hmac.secure_compare() leaks information about length of strings

[Martin v. Löwis]

Martin v. Löwis <martin at v.loewis.de> added the comment:

> Note that this does not relief you from using a time-independent comparison
> function. If you call some hash function (which time is known to the
> attacker), then you compare it against a stored hashed version. If you use
> a normal compare you're leaking the hash. This is indeed not as bad as
> leaking the password, but it has been demonstrated that one-direction
> functions are still vulnerable to some sort of attacks, so it's not ideal
> either.

But you don't leak the hash - you leak the first byte of the hash if you
make 256 tries, and the first two bytes if you make 65536 tries. To leak
the first four bytes of the hash, you need to make 2**32 tries.
So this is equivalent to a brute-force attack, which works just as well
against a time-independent function. So using a time-independent
function does not add any security.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15061>
_______________________________________