phc-discussions - Re: [PHC] Fwd: memory-hard password hashing

lists.openwall.net		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]

Message-ID: <CAJowKg+jiMq96m4pOxo6q+E4R8S9z7YKDmeax+mnB+ZocZYERw@mail.gmail.com>
Date: Wed, 19 Apr 2017 15:56:02 -0400
From: Erik Aronesty <erik@....com>
To: discussions@...sword-hashing.net
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 <erik@....com> 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 <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