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: Sun, 29 Dec 2013 18:25:31 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Initial hashing function. Feedback welcome

On Sun, Dec 29, 2013 at 5:50 PM, Peter Maxwell <peter@...icient.co.uk>wrote:

> Afaik, the important property is more that an adversary cannot calculate
> what's at each memory location, in a random access model, in less cost than
> a memory access.  Or, that the algorithm doesn't create clustered accesses
> that can be calculated in a single independent segment.
>

I'm pretty confident this hash does that.  I imagine the best brains in
this business just noodle a new hash function out of thin air.  Instead, I
iterated with the dieharder randomness test suite until I got a reasonably
fast result without dieharder telling me it's total crud (it passes most,
but not all tests).  I doubt the final derived password has any useful
predictability.


>
>> Is there any reason such a simple hash function should not be used?  I am
>> particularly interested in feedback on this point.
>>
>
> As far as I know, as long as what you've generated has some fairly basic
> properties and would cost more to calculate than the relevant memory
> access, you're fine.  I'm open to being corrected though: it's been a
> while since I've done any reading on this and I'm not entirely convinced
> memory-hard functions are the silver bullet they've been made out to be
> anyway.
>
>

Being a non-expert in the field, I don't know what those basic properties
are!  Some hash functions I tested eventually spit out nothing but 1's or
0's and others spit out the same sequence of values over and over, and this
function does not seem to do that.  Still, it probably has an embarrassing
bug and/or huge security hole...

As for being a silver bullet... the more I learn about scrypt, the more
impressed I become.  The only "mistake" I can point to is that he failed to
foresee the fear people would have for his new algorithm.  If I could make
a 4-character change to his code, it would simply be replacing 1 with 2048,
so that his algorithm would start with industry accepted key stretching,
and build from there.    Thanks for the feedback!

Content of type "text/html" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ