phc-discussions - Re: [PHC] A final cheat killer pass with smoke

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, 8 Jan 2014 18:59:16 +0100
From: Krisztián Pintér <pinterkr@...il.com>
To: Stefan.Lucks@...-weimar.de
CC: discussions@...sword-hashing.net
Subject: Re: [PHC] A final cheat killer pass with smoke

Stefan.Lucks@...-weimar.de (at Wednesday, January 8, 2014, 5:20:22 PM):

> The "smoke" approach should defend against that, but on the whole this
> looks more complicated than stacking two or more bit-reversal graphs, ;-)

there is another thing to consider here, namely the time-memory
"front" or how to describe it. that is, if we maximize time parameter
to a value, what is the supported highest memory, and vice versa, if i
want to use a certain amount of memory, what is the minimum time
parameter. if you add more rounds of bit reversal, you add to the
time, but not the memory, thus reduce the time-memory "front".

i can't prove, but i think this has a fundamental root, not just
accidental. with fixed access pattern, the better your algorithm is
time-memory front-wise, the worse it is against parallelization, and
vice versa. unpredictable access patterns help, but they come with
caveats.

btw do we have performance estimations for catena? afaik scrypt gives
something like 130MB/s (nonlinear?), my proposal, which i either
submit or not, gives 50MB/s linear.

personally, i would choose fixed access pattern over high time-memory
front. sooner or later we will need to use stronger passwords or stop
using passwords altogether anyway. we all live on borrowed time. brute
force is a lesser problem than side channels, i think.