[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150417183352.GA27042@openwall.com>
Date: Fri, 17 Apr 2015 21:33:53 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Cc: Agnieszka Bielec <bielecagnieszka8@...il.com>
Subject: Re: [PHC] winner selection
Hi Thomas,
On Tue, Apr 14, 2015 at 02:32:10PM +0200, Thomas Pornin wrote:
> On Mon, Apr 13, 2015 at 09:13:48PM +0000, Marsh Ray wrote:
> > I don't mind if we endorse other functions for special cases, as long
> > as we are abundantly clear that they are endorsed only when used for
> > their special semantics and are not to be considered alternative
> > recommendations for the general case.
>
> If we are talking about Makwa here, then I would like to make the
> (possibly bold) claim that Makwa, without considering delegation, is an
> acceptable replacement of bcrypt. More precisely, it has been reported
> that using GPU is not worth it when trying to brute-force a bcrypt
> hash; general-purpose CPU with a few kilobytes of RAM are a better
> bargain for that job. My claim is that the same holds for Makwa.
>
> I would really like to see this claim either confirmed or disproved by
> people with expertise on GPU programming and access to recent GPU.
Thank you for making this claim. Here's our tentative plan for working
on PHC finalists as part of a potential GSoC project:
http://www.openwall.com/lists/john-dev/2015/04/17/2
Agnieszka does not yet have much expertise on GPU programming, so this
will not result in a convincing confirmation of Makwa's GPU resistance,
but it might disprove your claim.
As to "access to recent GPU", we'd be happy to provide you with remote
access to our machines with (semi-)recent GPUs. Please e-mail me your
SSH public key if interested.
> If the claim is confirmed, then Makwa is not completely a "special-case
> function"; being a possible drop-in replacement for bcrypt (and, of
> course, PBKDF2) qualifies as "general case" for me.
>
> (I may even argue that a memory-hard function that gobbles up a gigabyte
> of RAM does NOT qualifies as a drop-in replacement for bcrypt, because
> it cannot be assumed that a given application that uses bcrypt will have
> a spare gigabyte of RAM. In a similar way, bcrypt or PBKDF2 are not
> drop-in replacements for a single MD5 since they -- by design -- use a
> lot more CPU. This point really means that the notion of "general case"
> is a matter of subtlety.)
I am also of the opinion that not all memory-hard PHC candidates that
target large memory sizes are suitable as replacements for bcrypt when
set to a low enough m_cost. They might lose to bcrypt at that m_cost.
Alexander
Powered by blists - more mailing lists