phc-discussions - Re: [PHC] escrypt 0.3.1

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]

Message-ID: <20140305010802.GA14616@openwall.com>
Date: Wed, 5 Mar 2014 05:08:02 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] escrypt 0.3.1

On Tue, Mar 04, 2014 at 04:51:16PM -0800, Andy Lutomirski wrote:
> On Tue, Mar 4, 2014 at 4:44 PM, Solar Designer <solar@...nwall.com> wrote:
> >         Issues and future work.
> >
> > I am not happy about the complexity.  Clearly, when supporting classic
> > scrypt and more, complexity is higher than scrypt's.  Is this worth
> > keeping, or should we drop support for computing classic scrypt hashes
> > in order to let us simplify things somewhat?
> 
> I'm not convinced that this is very useful.  I don't think that there
> are all that many scrypt users out there, any most would probably be
> happy just using an scrypt library and a PHC-winner library.
> Litecoin, for example, will never upgrade :)
> 
> There's another benefit to dropping compatibility: it will discourage
> people from using scrypt-compatible mode in new applications.

Thanks for sharing your opinion on this.  I hope dropping of features,
including possibly the scrypt compatibility mode, can be done later in
the PHC as "tweaks", if this community at large determines that this is
the better thing to do.

I forgot to mention another advantage to having this mode, at least for
now: correctness testing.  When much of the code is shared with scrypt,
it can be tested against scrypt test vectors - and indeed we've been
doing that for escrypt all the time.  Of course, this does not test the
portions of design and code that are not shared with scrypt...

Alexander