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: Sat, 8 Mar 2014 05:26:34 +0400
From: Solar Designer <>
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 <> 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.


Powered by blists - more mailing lists