[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1333427611.991462.1390185667930.open-xchange@email.1and1.com>
Date: Sun, 19 Jan 2014 20:41:07 -0600 (CST)
From: Steve Thomas <steve@...tu.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Native server relief support for password hashing in
browsers
> On January 19, 2014 at 6:47 AM Bill Cox <waywardgeek@...il.com> wrote:
>
> On Sat, Jan 18, 2014 at 3:59 PM, Stephen Touset <stephen@...set.org> wrote:
> > My original idea behind the blakerypt session key was to defeat cache
> > analysis.
> >
> > However, the Catena guys seemingly have a much better approach than mine,
> > which doesn't require the hash to be keyed, so I have effectively bowed out
> > of the competition to make room for the professionals here who know what
> > they are doing. :)
>
> I would hate to see entries like Blakerypt bow out because of Catena.
> If I drop out, it will be because of excellent real-world work like
> escrypt. Catena has some excellent theoretical work, but until I see
> an implementation that begins to approach the security of Scrypt, I
> don't see it as a real contender.
So I guess you've seen this ( https://github.com/cforler/catena) and
benchmarked both of them. What were your results? I've been meaning
to do this for a while. Along with others.
> The Catena paper blew me away and I stole some of their ideas
> wholesale. However, it seems like an academic solution at this stage.
> It has nothing to support modern memory architectures, no useful
> parallelism, and no high performance hashing. Of course, all of that
> can be added, but until I see a real-world solution, it remains
> theoretical work in my mind.
Catena uses Blake2b which has parallelism in it. SHA512 was added
because there was a PHP implementation that used SHA512. SHA512 is
built into PHP and will be faster than Blake2b written in PHP.
Content of type "text/html" skipped
Powered by blists - more mailing lists