phc-discussions - Re: [PHC] Are password trailing 0's a problem?

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]

Date: Sat, 8 Mar 2014 03:45:05 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Are password trailing 0's a problem?

On Fri, Mar 07, 2014 at 03:30:37PM -0800, Andy Lutomirski wrote:
> It seems odd to me that PBKDF2 is being used in any PHC proposals.

For escrypt, this is in part because of the scrypt compat mode.

PBKDF2-HMAC-SHA256 also has the advantage of being well accepted, so
being able to say that cryptographic security of a new password hashing
scheme is provably no worse than PBKDF2-HMAC-SHA256's may be helpful.

BTW, Bill's choice of BLAKE2 for the sole cryptographic primitive, while
sound technically, may be problematic for some prospective users.

> AAUI PBKDB2 was intended as a password hashing algorithm,

I'd say it was intended as a key derivation function, not as a password
hash.  It has problems when used as the latter and the output size is
naively set to be larger than the underlying hash's block size.

> and it's not very good.

Yes.  It is not.

> The modern PHC candidates really want to use at as a
> function that maps arbitrary-length strings to arbitrary-length
> strings and that has "some of" the properties of a PRF, where "some
> of" is possibly not very well thought through.
> 
> Why not use a simple, modern primitive for this?  To me, the obvious
> candidate is Keccak.  It's immune to generic attacks like this, which
> was half the point of developing it in the first place.

Maybe.  However, if I were to bring a new crypto primitive in, I'd
prefer it to be suitable not only for the initial/final steps, but also
for per-block data mixing.  Keccak favoring hardware implementations is
not great for that.  (Unfortunately, BLAKE2 is not going to be SHA-3.)

> ISTM that it
> would be embarrassing for the PHC winner to have less resistance to
> generic attacks than a hash function should provide.

I agree.  So I am thinking of a suitably minimal change to scrypt's use
of PBKDF2 so that the two problems pointed out in this thread today
would not affect escrypt (except in scrypt compat mode).  Unfortunately,
those minimal changes feel hackish.  For example, I could XOR the
least significant byte of password length into each derived key block
after the initial PBKDF2 call.  How does this sound to you?  (One byte
should be enough since it contains all the info that is otherwise lost
with padding.  And there's no endianness issue.)

Alexander