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: <CAFOKM3qmntt3GK3KGq5123pfzVbUgfJTgMOPH4XSwaYXqAUU1Q@mail.gmail.com>
Date: Wed, 19 Apr 2017 09:38:26 -0700
From: Dean Pierce <pierce403@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Fwd: memory-hard password hashing

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ