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  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: Sun, 1 Mar 2015 19:21:03 -0800
From: Bill Cox <waywardgeek@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] PHC status report

On Sun, Mar 1, 2015 at 5:45 PM, Donghoon Chang <pointchang@...il.com> wrote:

> I just want to know whether the PHC panel already knew the negative
> aspects of Catena from the performance-perspective. If the PHC panel knew
> it, I want to know why in the PHC status report it was not mentioned, only
> with full of praises for Catena!
>

I would hope that Catena's competitors would support reviewing Catena
knowing that it can easily be made many times faster.  Fortunately, it
seems the PHC was able to review Catena in this light.

I can't speak for the PHC panel, since I'm not on it.  However, I made
quite a stink about the terribly slow speed of Catena on the forum, posting
benchmarks.  Rather than being offended, Christian invited me to
collaborate on making Catena faster.  With permission, I forked Catena and
replaced the full 12-round Blake2b with the same faster hash function I was
using in my entry at the time.  The result was faster than Scrypt, and
quite competitive with the improved version of RIG, though a bit slower
than Lyra2, TwoCats, and Yescrypt.  The code is here:

    https://github.com/cforler/catena/tree/waywardgeek

I also only described the benchmark results in my paper, page 28:

    https://password-hashing.net/submissions/specs/TwoCats-v0.pdf

In my review of Catena, I also mentioned that Catena's unusable speed is
easily fixable:

    http://permalink.gmane.org/gmane.comp.security.phc/2065

I wrote, "The choice of the Catena team to stick with the full 12-round
Blake2b function should not be held too strongly against Catena. Simply
plug in the Blake2b reduced round function from RIG and Lyra2, and
Blake[sic] becomes faster than Scrypt, though not quite speed competitive
with Lyra2, TwoCats, or Yescrypt."

I think that the PHC panel either read some of what I wrote, or came to the
same conclusions on their own.

Why would I promote a competitor's algorithm with a stronger hash functoin
in my benchmarks?  The most important thing here is for the winner to be
awesome.  Similarly, Alexander helped me make TwoCats awesome, in my view,
to the point that it may have even threatened his entry.  Why?  Again, to
improve the eventual winner.  I have to give both Christian's team and
Alexander a lot of credit for how they helped competitors like me
throughout this competition.  RIG clearly benefited from their generosity
as well.  This is in stark contrast to a couple competitors here who keep
posting contrived "cryptanalysis" papers to inaccurately portray their
competitor's algorithms as weak.  The RIG team was above such attacks - I
don't mean you guys.  Your team rocks.

Bill

Content of type "text/html" skipped

Powered by blists - more mailing lists