phc-discussions - Re: [PHC] Why protect against side channel attacks

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 linux-cve-announce 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]

Message-ID: <20150625050531.GA2157@openwall.com>
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