lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Jan 2014 05:44:58 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] cache timing attacks (Re: [PHC] Initial multiply-compute-hardened Catena-3 benchmark)

On Fri, Jan 24, 2014 at 05:37:52AM +0400, Solar Designer wrote:
> ... which leads us to a new concern: what if the same-machine attacker
> without knowledge of the salts does make a likely guess at the password
> (e.g., guesses "123456", which might be correct with 1% probability when
> there's no password policy)?  This attacker can then try to infer salt
> bits, still not knowing whether the password guess was right or not.
> Then, having obtained (via cache timings) the possible salt _assuming_
> that the password was guessed correctly, the attacker can use further
> cache timing attacks to test whether the password guess was in fact
> correct or not.  If not, repeat for second most common password.  Nasty.

Oh, I think this is easily defeated by having a lot of entropy in the
salt, and it being processed in large enough chunks (or in its entirety
at once) - not by individual salt bits (or individual salt-derived bits),
nor other small quantities (e.g. 8-bit would be too small), affecting
individual lookup indices, but rather the salt as a whole (and never a
much smaller portion of it) affecting the indices.  Then the attacker
would have to probe for full salts, and this is too large a space.

Alexander

Powered by blists - more mailing lists