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-next>] [day] [month] [year] [list]
Date: Wed, 8 Jan 2014 22:07:00 -0500
From: Bill Cox <>
Subject: What's your favorite entry so far, and why?

If I were a judge on this competition so far, I'd be pulling for escrypt.
 It bothers me that the next great memory-hard KDF might carry a lot of
baggage from scrypt, but Alexander has made it far faster than any of the
other serious competitors (NoelKDF has a way to go before it's serious),
and the depth of analysis he's done in addition to all of the work everyone
has done analyzing scrypt has helped make escrypt, from what I can tell so
far, the best entry in the competition.  It's the safest, in that we
already know it's weaknesses which are not fatal.  It's fast, though faster
still would be better, and it has some well thought out extensions, such as
protection against TMTO when using multiple threads.

>From a theoretical point of view, Catena wins so far.  Avoiding cache
timing attacks is desirable, and Catena shows how to do it.  I am concerned
that the authors recommend only 10-ish MB of memory, when escrypt can hash
1GB in a second.  Protection in memory-hard KDFs is proportional to memory
used!  While I'm a fan of the algorithm, if Catena were more speed
competitive, I would consider it a stronger candidate.

The others I've read about so far are all interesting in the ways the
authors intended.  EARWORM has a great name, and maybe the author's don't
give their work enough credit, but they aren't AFAIK trying to be a general
purpose KDF.  Lyra is cool, and I look forward to seeing what it becomes,
but without benchmarks, I can't evaluate it.

IMO, the metal meets the road at benchmarks.  Raw speed by itself isn't
everything.  An algorithm needs protection against parallel hardware
attacks, and issues like cache timing attacks count.  However, IMO, an
algorithm isn't a solid competitor until we see at least prototype code.
 Any algorithm short of around 1GB/second of memory filling capability is
weak, IMO.  Of course, I was always a speed freak :-)  When I hear 10MB or
50MB or 100MB/second, I just hope that these guys improve their speed.
 Anyway, I obviously have my biases, even though I'm right :-)  What are
your thoughts so far?


Content of type "text/html" skipped

Powered by blists - more mailing lists