Message-ID: <CAJowKgKh7EHHDR=2ZLG_5+hcM-1AiJqfOvjwEEfdAPrN4CoEmQ@mail.gmail.com>
Date: Wed, 19 Apr 2017 15:53:53 -0400
From: Erik Aronesty <erik@....com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Fwd: memory-hard password hashing

I don't get how "GPU hogs" verification works.

There are several fast double-precision CPRNG's designed for high speed GPU
operation that would be hard to beat with any ASIC.

Not sure how you managed to turn an CPRNG into a secure hash.

On Wed, Apr 19, 2017 at 1:04 PM, Bill Cox <waywardgeek@...il.com> wrote:

> I wrote a GPU-focused memory-hard proof-of-work algorithm with fast
> verification I call GPU Hog.  Basically, it hashes the input key material
> to init a CPRNG that selects several 4 KiB blocks from a multi-GiB pool of
> pseudo-random data.  It hashes the selected blocks together, and if the
> result has enough leading zeros, then you've proven you have done enough
> work.
>
> It requires a modern GPU with high GDRAM bandwidth since it is memory
> bandwidth limited.  For mining, you need all of the pseudo-random data in
> memory to mine efficiently, but for verification, you only need to generate
> the several pseudo-random blocks and hash them together.  Verification is
> faster than a typical public key operation, so it would not be the
> bottleneck in verifying a block-chain.
>
> Is this similar to what you had in mind, or are you specifically looking
> for GPU based password hashing?  I think that password hashing on mobile
> phones and tablets could be considerably strengthened using their graphics
> processors.
>
> Bill
>
> On Wed, Apr 19, 2017 at 9:38 AM, Dean Pierce <pierce403@...il.com> wrote:
>
>> Personally I think "GPU friendly" is not a great thing for passwords,
>> since GPUs are asymmetrically more popular with attackers, but you might be
>> interested in checking out the "Vertcoin" project: https://vertcoin.org/
>>
>> It's a cryptocoin, similar to Bitcoin, with the gimmick that they have
>> always tried to target the GPU mining audience.  Their proof of work
>> started out with an adaptive N scrypt algorithm, but when KnC released
>> scrypt ASICs, they pivoted to a modified Lyra2, at which point a large
>> botnet took control of most of the mining power, and they pivoted again
>> with a Lyra2 more finely tuned for modern GPUs.
>>
>> I think the ideal goal for password algorithms is CPU friendly, where the
>> most efficient machinery for calculating the hash is a commodity CPU.  At
>> that point, you could roll your own ASICs, but they wouldn't be much better
>> than what you could just pick up at Best Buy, and you'd lose out on the
>> economies of scale that CPU vendors have.
>>
>>   - DEAN
>>
>> On Wed, Apr 19, 2017 at 9:07 AM, Erik Aronesty <erik@....com> wrote:
>>
>>> There is a focus on memory-hard algorithms in password hashing, since
>>> that renders them ASIC/GPU resistant.
>>>
>>> However, it is /possible/ for an ASIC to be tightly coupled with DRAM in
>>> ways that can exceed PC memory performance.
>>>
>>> Instead, is there an algorithm that is "very GPU friendly"?
>>>
>>> GPU's are cheap, common and highly optimized for certain operations in
>>> ways that make the construction of ASICs that beat them at what they are
>>> best at very unlikely.   They are, essentially, "floating point matrix
>>> operation ASICs".
>>>
>>> Yes, this means that servers using such a mechanism may want to have
>>> GPUs installed to reduce hashing times and allow a larger number of
>>> operations to increase hashing security.   But I think this is a reasonable
>>> request for many applications.
>>>
>>> If it takes 10 milliseconds to compute a single hash with highly
>>> parallel FLOPs on a modern GPU, that affords a massive amount of security
>>> for a hash - ASIC resistant in ways that memory-hard algorithms cannot be.
>>>
>>> Is there an algorithm that already lends itself to this kind of
>>> application?
>>>
>>>
>>
>

Content of type "text/html" skipped

Powered by blists - more mailing lists