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: <20150625205955.GA27847@bolet.org> Date: Thu, 25 Jun 2015 22:59:55 +0200 From: Thomas Pornin <pornin@...et.org> To: discussions@...sword-hashing.net Subject: Re: [PHC] Why protect against side channel attacks On Thu, Jun 25, 2015 at 09:17:47PM +0800, Ben Harris wrote: > I'm curious if there was any period of time since the inception of the salt > that it was considered "public". If you are doing some password-based key exchange (e.g. SRP) then the salt is necessarily public, since the whole password hashing must be done client-side, and at that time the client does not even know whether it is talking to the genuine server. There cannot be any notion of "server-side secret" in that case. Another situation where the salt is necessarily "public" is when doing password-based encryption (of, say, a file): to allow for decryption, any "salt" is embedded in the file header, thus in plain view. In fact, I'd say that salts can be kept private only in the one context of client authentication by a server whom clients trust (admittedly, a very common context). > I guess the outcome of this thread is that side channel resistant > candidates are compatible with public salts? For the (limited?) > applications that require a public salt? If salts must be kept private, then they must also be unguessable, i.e. generated with a cryptographically strong PRNG. This is a nice way to generate salts anyway, but not a method which is mandatorily implied by the term "salt". Usually, the notion of "salt" requires uniqueness, which can be achieved in a number of ways (e.g. UUID, or a simple server-wide counter) that can be highly guessable. If a "salt" in a given algorithm requires other properties, then I agree with Stefan that calling it a "salt" is misleading (but maybe "key" is not the right term either). --Thomas Pornin
Powered by blists - more mailing lists