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
| ||
|
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
Powered by blists - more mailing lists