phc-discussions - Re: [PHC] Memory performance and ASIC attacks

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] [day] [month] [year] [list]

Message-ID: <53FF9CA7.6060202@ciphershed.org>
Date: Thu, 28 Aug 2014 17:18:31 -0400
From: Bill Cox <waywardgeek@...hershed.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Memory performance and ASIC attacks

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/28/2014 02:04 PM, Marcos Simplicio wrote:
> On 28-Aug-14 14:23, Solar Designer wrote:
>> On Thu, Aug 28, 2014 at 12:07:24PM -0400, Bill Cox wrote:
>>> TwoCats and Yescrypt are the most ASIC attack resistant
>>> algorithms in the competition for hash sizes of 32MiB and up.
>> 
>> If so, why not for lower sizes as well?  Do you mention this as
>> the lower boundary just in case, since Pufferfish (and bcrypt,
>> but it's not in PHC) might win at some really low sizes (perhaps
>> way below 1 MiB)?
>> 
>>> Lyra2 is a close second, off by about 2X in my tests, only
>>> because Lyra2 does not have a multi-threading option.
>> 
>> Only 2x worse while completely lacking computation latency
>> hardening? Are you sure it's safe to rely solely on memory
>> latency and bandwidth? Previously, you were not so sure.
>> 
> 
> Well, there is no "multiplication hardening" or anything of the
> sort if we assume that the underlying sponge is Blake2, but that is
> not strictly the case: Lyra2 does not impose any restriction on
> what is the underlying hash, as it was designed as a sponge-based
> wrapper around a hash function. We did use Blake2 in our
> implementation, but any iterative hash function would do the
> trick.
> 
> Notice that this characteristic can be considered good ("it is 
> flexible") or bad ("it transfers the burden of the choice to the
> user"), depending on how you see it, so I cannot say that this is
> any kind of advantage of Lyra2 over any other candidate.
> 
> BR,
> 
> Marcos.

I like that design choice.  I may have to see if I can add a
multiplication chain to it.

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

iQIcBAEBAgAGBQJT/5ykAAoJEAcQZQdOpZUZmyoP/16wXHi0WFZq6bSJirK1vA55
GEtywDxilgyfoiDV0YhQ3+UnqzDMZVxeT2ZgVfpvt5PRLvKVUuwSi/ATOnHdaUX7
z/hTKuV9ZpmAFKFHQKhaU2O6FOUOeTvuWNPqiA/VxrUZqNukUoyqHbjxtje5bdX/
5zMVnmotlAZx8BDJdE/s851Ba6xpjZXFm6F/EUA/2Uyu//Lb6H5Wb1RL0alt5Wtg
WmBeHtoN3NZ8AsnmuFxOKw4EBHrnqw9VWOvI5FEmrYeVIbTI4VD9GPTpV6pfXzsE
VYCHTMBR+rud5wezfVbCv9fokeOanCBDuTeuEHHCc9i9edLh9sVDVO6rjmMysVO1
RCPeg3yWVBfuzZzHSQghTxUgnV9r0UJHx2KlWs8ab2B1umxIwt4xdYX+FH3CX1zh
VtAwKYz2eyRqsniBGFqV41xMpKVB1KgOJz6bfxI10NLQL3YO7ba6eOEI/f8gkBoP
XgalnAmAaUnzO9CjJEKMqogBAQKUD/7EVzAk7aMdpxJZ6GX4xAsa1Hi1Q81cSX/I
xw1fZulHBCYjLQqxTcVtTFoKxFU7zxhW6mgSaSAOmWftn5aLI23ar+XC55MwQl7p
SuU0B5UnubjrQk+iUprhT8UqoOcX6NxT674s/2pcObirHkqjatrh2vI1Dcws4yoG
H/Cow7d8BNa9f96i/ZEA
=Wz76
-----END PGP SIGNATURE-----