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, 03 Sep 2014 06:21:45 -0400
From: Bill Cox <>
Subject: Re: [PHC] A review per day - Parallela

Hash: SHA1

On 09/02/2014 11:14 PM, Solar Designer wrote:
> 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'.

Low memory applications seem very hard to protect in general.  I doubt
my PIC microcontroller will be able to mount a really good defense of
any kind.  Time for really good passwords in that case.

> 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.)

I was a bit surprised to see that Steve wrote a new SHA512
implementation for this contest.  But, it's just a widget he calls.
It could have easily been passed as a parameter to this hashing.

The hashing does the inner-outer thing like HMAC, and it looks right
to me.  However, that's probably the most complicated part.  An RFC
for Parallel would be pretty simple.

> 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

And for ASICs, it looks like about 2X larger, and just as fast as
SHA256, though I haven't looked at it carefully enough to say that
with confidence.  We could still stick an ugly number of such hashing
cores on an ASIC.

Instead of hashing SHA256 or whatever, can we come up with an
algorithm that makes good use of the various RAMs on a GPU, while
running the cores all at full speed?  That would be a heck of a lot
tougher to attack with an ASIC, and password hashes might have a bit
longer life before they become insecure.

Version: GnuPG v1


Powered by blists - more mailing lists