Date: Wed, 03 Sep 2014 06:21:45 -0400
From: Bill Cox <waywardgeek@...hershed.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] A review per day - Parallela

-----BEGIN PGP SIGNED MESSAGE-----
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.

Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUBuu1AAoJEAcQZQdOpZUZS14P/20H/zXlKYDklb+IMVX3OXA5
MGOA7/JM72tsKGKpW3RqmdxztKyc3CA/yXsdjn4opth4156fbmHvUsbxgwpE+aS6
IahqPtewHGV+TCs7zWZQ3+RYpa4tvqHIUdTOvMidoLcpQo9iElYhPNUsT3Wi8tSo
gg/2anmIrwmYOzQr/oyFQ784yE33z0Me5bwx8kXva4EaAothEJ63ufXWPuRl7zmV
pEm2hW03elluS07TI43wEHIrIVg4J1yCpjTybZDMazqSRZHRuEPG+LrPGzShWVvo
eHEtouWWkz3G+cTm0Ipc9Up/el+f7twwQPZCVOWyY010J3aONlWSrZlu8rE25kMG
a+WcIpn1oSmpHGXWCcL1GUBu+uY763JrabETGhCKlFsrNt5o4s5NK+wWfa+aap57
hTExx5v9gSGXZZqGw2Vn8F1BEH5PRTcNa45syekIiX5e6GtDO0/ddi4rPzkSmROr
a11Al6FDm7DfAB9KLcZ5kqOl0ab0TwYGqNNAN4fLXgYUYLxrKujlSsyIW0qdlanY
CMWFbtimGVmlSWTMVgjHXxBCVf5pCM/oXpHq/VdR5MTPhxLVFFKYO1XXwqXSz4Sb
S0y6yQ+uYLO7MJeoKilxPPL1343j0U3fPiiV3UeZgyuhJCIBOOUsiSK6AXrL0KYX
L+bvXwItJ2nz4vlFwpjc
=HdJm
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists