phc-discussions - Re: [PHC] simplifying yescrypt

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: Tue, 21 Oct 2014 12:32:39 -0200
From: Marcos Simplicio <mjunior@...c.usp.br>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] simplifying yescrypt

Hi, there.

On 21-Oct-14 11:57, Solar Designer wrote:
> On Mon, Oct 20, 2014 at 11:47:15PM -0400, Bill Cox wrote:
>> Not coincidentally, the Lyra2 team and I realized you had some great
>> advice on the forum, and acted on it.
> 
> I think you are (unintentionally) exaggerating my influence on Lyra2.
> Maybe we'll see it in a future revision of Lyra (as there's been some
> talk on adding multiply hardening chains), but I don't feel I influenced
> Lyra2 much.  I've been advocating use of lower values for the T
> parameter than what Lyra designers recommended, and I felt (and
> explained why) the logic behind recommending high T was flawed, but it's
> been a configurable parameter from the start.

To be precise, the tweaks we are considering to add to Lyra2 are not
affected by the multiplication hardenning aspect: the idea is simply to
give the user the ability to choose a different underlying sponge that
includes multiplications, while the "mode of operation" remains the same.

This does not diminishes the influence of Alexander's comments (the idea
of slowing the hardware down is very good!), but just that this lead us
to think about a different hashing algorithm, not exactly about a
different PHS. Anyhow, the user is free to use plain Blake2, Keccak
(preferable if a hardware implementation is available), or anything that
can fit into a sponge construction. The main reason why a "new"
algorithm may be of interest in this context is that we could not find
any good permutation in the literature that included multiplications in
it, hence the idea of a Blake2-based tweak.

> 
>> Lyra2 is simpler, but when it has multi-threading, some TMTO defense
>> for it, better compute-time hardening, and maybe improved GPU defense,
>> it will increase from it's moderate complexity to high complexity.
>> You simply can't compete in all those security dimensions at the same
>> time otherwise.
> 
> Yes, that's my opinion too.
> 

To have an idea on how complicated it will get, you can read the section
that discusses parallelism on the original document. What we have been
testing is basically what is already there, with a few details
added/suppressed to make things easier to describe/implement.