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]
Date: Wed, 8 Jan 2014 19:43:16 -0500
From: Bill Cox <waywardgeek@...il.com>
To: Poul-Henning Kamp <phk@....freebsd.dk>
Cc: discussions@...sword-hashing.net
Subject: Re: [PHC] Lyra, Password Key Derivation Based On The Sponge Construction

Wow... MD5crypt.  I am a noob, and I've been telling my wife that I've name
an algorithm after my cat.

Sorry about being noisy.  I'm just looking for every opportunity to push my
primary point about the design of memory-hard KDFs: they should be fast,
fill lots of memory, and any CPU cycles wasted on computing a
crypto-strength hash per memory location is a waste of time.

I think there's a lot of fear about putting forward entries that don't use
proven cryptographic hashes in the inner loop.  Alexander has proven such a
system can be pretty fast, but there's 2X-ish or more in speed left on the
table.  I'd love to see what he an the others would come up with if they
felt comfortable deviating from known hashes.

Bill


On Wed, Jan 8, 2014 at 7:27 PM, Poul-Henning Kamp <phk@....freebsd.dk>wrote:

> In message <
> CAOLP8p4cB2+w8ZA2YCEXqCVh-AvHDxNqKcDnVZG4SWOyEYJM2Q@...l.gmail.com>
> , Bill Cox writes:
>
> Bill,
>
> Since I havn't been very active on this list, I apologize for not
> adding a disclaimer in my email to the effect that I am one of the
> persons on the judging panel of the PHC, just to alert people to
> where I'm coming from.
>
> In other words:  I'm not a total NOOB in this line of work  :-)
>
>
> The point(s) I tried to make is much finer than the broad strokes
> you paint them with:
>
> You are absolutely right that there is no way to get more entropy
> than we are offered, and that was *exactly* my point:
>
> Any algorithm which sets up a big state structure, needs to pay a
> lot of attention to how to lightly dust it with what little entropy
> is available *and* at the same time pay attention to not making
> it unnecessarily easy to deduce the state using covert channels.
>
> In your RC4 example, you seem to overlook that the salt is not
> unknown to an attacker, and with a 20/256 bits ratio of unknown to
> known bits, only the 20 bits really count:  Knowing the salt, the
> attacker know exactly where the 20 bits _went_, and only needs to
> deduce what they _did_.
>
> Poul-Henning
>
> PS: This is not going to be a decisive factor in my judging, but it
> one aspect that will add grains to one or the other side of the
> scales for me.
>
> PPS:  I'm not entering a contestant, MD5crypt was enough for me ;-)
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@...eBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>

Content of type "text/html" skipped

Powered by blists - more mailing lists