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: Wed, 5 Mar 2014 05:08:02 +0400
From: Solar Designer <>
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 <> 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...


Powered by blists - more mailing lists