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, 19 Apr 2017 15:53:53 -0400
From: Erik Aronesty <>
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 <> 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 <> 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:
>> 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 <> 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