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: Thu, 25 Jun 2015 08:05:31 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Why protect against side channel attacks

On Thu, Jun 25, 2015 at 01:45:47AM +0000, Marsh Ray wrote:
> Well, it's not the salt per se, but the access pattern it generates.

This is why the salt must not generate any access pattern before it's
passed through a cryptographic hash function, possibly along with the
password.  Then if the salt is large enough and cryptographically
random, you can't realistically derive it from the access pattern.

> Is there an attacker advantage if they have the ability to perform queries on the addresses generated by a unknown salt for a limited set of chosen password inputs?
> 
> I don't recall if the PHC analysis considered this question explicitly for those functions with password-derived access patterns.

We might not have discussed this, but I certainly had it in mind when
working on yescrypt.  Since this attack is easy to avoid, of course any
scheme with password-derived access pattern that we might recommend (if
we do at all) must avoid it.

> It's probably a moot point for a couple of reasons:
> * It doesn't sound like we're actually contemplating a function with a password-derived access pattern side channel, and

You mean as a PHC winner?  Choosing between Argon2i and Catena only?

> * The salt is not a capital-S Secret, by definition, so we're forbidden from reasoning about it as if it were, even if hopefully it is.

Salts are generally just as (not) secret as the hashes are.  Thus, for
offline attacks, from the moment that the attacker obtains the hashes,
salts are not secret at all.  Until then, though, there are good reasons
(not limited to the side-channels aspect) not to make the salts
available to a potential attacker.  Unfortunately, client-side partial
computation of hashes (or responses to challenges) violates this, but
this problem isn't limited to the side-channels aspect and it isn't
fully solved by side-channel safe hashing schemes.

Even e.g. with Catena, use of its server relief feature allows an
attacker to precompute almost-final hashes of common passwords with the
correct target salts before eventually obtaining the actual hashes for
offline attack.

Alexander

Powered by blists - more mailing lists