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:56:02 -0400
From: Erik Aronesty <>
Subject: Re: [PHC] Fwd: memory-hard password hashing

Just set the number of iterations high enough until I've achieved the 1ms I
want, or whatever is needed...?

On Wed, Apr 19, 2017 at 3:53 PM, Erik Aronesty <> wrote:

> 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