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]
Date: Wed, 3 Sep 2014 07:14:56 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] A review per day - Parallela

On Tue, Sep 02, 2014 at 09:50:31PM -0400, Bill Cox wrote:
> The basic idea of Parallela:

It's Parallel, not Parallela.

> use your GPU for defensive purposes.
> 
> Basically, my notes were not very accurate.  First, this is primarily
> an algorithm designed to make defensive use of your GPU, and maybe
> FPGAs.  It runs a very large number of parallel SHA512 hashes
> (3*5*128*loopCount), and then does as many of these in series as you
> like.  I am a fan of defensive use of GPUs.  Against GPU farms, it
> puts you basically on par with them.

For such use, I'd recommend replacing SHA-512 with SHA-256.  Steve's
parallel.pdf lists "low memory applications" as primary use case, and
mentions defensive use of "FPGAs or GPUs" next.  I guess the choice of
SHA-512 over SHA-256 confirms this - "low memory applications" on CPU
come first, where GPUs and FPGAs would be attackers'.

So we might want to keep the choice of underlying crypto hash out of the
spec for Parallel, only suggesting SHA-512 as default for
implementations on CPU and SHA-256 as default for implementations on GPU.
(SHA-1 could work better yet for GPUs, but would raise concerns as it
gets more and more broken for other uses.)

As seen from speeds achieved by recent versions of oclHashcat (not yet
available when Steve submitted Parallel to PHC), SHA-512 is actually not
as bad for GPUs as previously thought, but as far as I understand those
speeds are achieved with low-level hacks, not with pure OpenCL.  For
SHA-256 and below, decent speeds are achieved with OpenCL.  It's nicer
to let defenders use higher-level code such as OpenCL reasonably well.

Alexander

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ