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] [day] [month] [year] [list]
Date: Thu, 04 Sep 2014 06:35:00 -0400
From: Bill Cox <>
Subject: Re: [PHC] Cryptographically strong salt is not overkill

Hash: SHA1

On 09/04/2014 01:58 AM, Brandon Enright wrote:
> On Thu, 4 Sep 2014 00:45:29 +0200 Thomas Pornin <>
> wrote:
>> On Wed, Sep 03, 2014 at 05:37:27PM -0400, Bill Cox wrote:
>>> If any salt generator that produces data that is
>>> distinguishable from random data makes it into CipherShed, I
>>> will be pretty pissed off. Don't forget that some users have a
>>> valid need to store the salt in plain-text without letting an
>>> attacker know that it is in fact not just random data.
>> I'll still stand by my assertion. A cryptographically strong
>> PRNG is overkill for a salt.
>> [...] However, the need for strong randomness does not come from
>> the saltness, but from the other, completely orthogonal
>> constraint coming from your specific scenario.
> Even in Bill's scenario a cryptographically strong salt isn't
> needed. Usually the notion of something being "cryptographically
> strong" involves the PRNG resisting an attacker gathering long
> sequences of successive output.
> For a 128 bit salt, all that's needed is that for a given seed,
> there is no distinguishing attack utilising only 128 bits of the
> PRNG output. Even many poor PRNGs are indistinguishable from random
> when you only have the first 128 bits of their output (e.g.
> Mersenne Twister).
> Brandon

I should also mention that we store the password hash in plain text,
and that it must also be undetectably non-random.  We discussed this
on this list, and I think the majority consensus was that password
hashes should have this property, because some users use password
hashes for key generation, and some keys need this property.
Certainly CipherShed's do.

I only brought this up because people writing salt generation or
password hashing code should probably take these user's needs into
account.  It is the safe thing to do.  I think Thomas got it right in
his code.  The comment just made me think that other authors on this
list might get it wrong.  Please don't!

Version: GnuPG v1


Powered by blists - more mailing lists