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  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 <>
Subject: Re: [PHC] A final cheat killer pass with smoke (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

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.

Powered by blists - more mailing lists