4 ms·
It's fundamentally the same attack as the plaintext case, although here it's breaking signature verification. Here, the computation is real_sig := Sign(ms
by vitus 5y ago
It's fundamentally the same attack as the plaintext case, although here it's breaking signature verification.
Here, the computation is
real_sig := Sign(msg)
Cmp(real_sig, provided_sig)
For a fixed message, Sign(msg) is constant time. So, with enough attempts you can create a high-resolution timer to tease apart subtle timing differences in Cmp.
You're correct that if the computation is
provided_hash := Hash(pepper + pw + salt)
Cmp(real_hash, provided_hash)
then the comparison is Hard (tm) to break.
(But this relies upon transmitting the plaintext password, you might say! If you transmit the hash directly, then you're again hosed. One option I've seen previously is transmitting a hash of the password, then hashing + salting it once more, which relies on avalanche effect as you suggest. I provide no guarantees re: the security of such an approach, though -- talk to an actual cryptographer!)
- a1369209993 5y ago> One option I've seen previously is transmitting a hash of the password, then hashing + salting it once more, which relies on avalanche effect as you suggest. If the client-side hash is fixed, this is no more secure than transmitting the plaintext password, since as far as the server is concerned, it is the password. You could, however, send a nonce to the client, send back H(nonce++password), calculate H(random++Hsent), and compare that to H(random++H(nonce++password)) calculated on the server. > talk to an actual cryptographer I am not your lawyer^Wcryptographer and this is not legal^Wcryptographic advice.
- daef 5y agoDoesn't this imply the server knowing the plaintext password?
- a1369209993 5y agoYes. You could (probably should) add a additional password=PBKDF(real_password) if that's a problem (eg because of password reuse), but it's not a essential feature from a cryptographic perspective.