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 05:26:34 +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 05:06:52PM -0800, Andy Lutomirski wrote:
> On Fri, Mar 7, 2014 at 3:45 PM, Solar Designer <solar@...nwall.com> wrote:
> > [...] 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.)
> 
> Well, if people really want "at least as secure as PBKDF2" (sigh) and
> scrypt compatibility (I've already expressed my opinion on that), then
> how about something that's ugly but should be provably good:
> 
> MGF1-SHA256(password legnth || password || PBKDF2(whatever))

I thought of simply using "password length || password" instead of the
password itself as input to PBKDF2, but I don't like having to copy the
password to produce "password length || password", nor customizing the
PBKDF2 implementation to avoid the need for such copying.

Alexander