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 22:59:55 +0200
From: Thomas Pornin <>
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

	--Thomas Pornin

Powered by blists - more mailing lists