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: Fri, 6 Dec 2013 14:09:00 -0800
From: Andy Lutomirski <>
Subject: Re: [PHC] blakerypt sequential memory-hard function

On Fri, Dec 6, 2013 at 9:45 AM, Krisztián Pintér <> wrote:
> Dennis E. Hamilton (at Thursday, December 5, 2013, 5:16:02 PM):
>> The advantage is that the Fibonacci recurrence provides a nice way
>> of deriving k on the fly by seeing how much time is being taken in
>> real time, and incrementing by the next step if a target threshold
>> has not been reached.
> this is a recurring theme, and i never was a great fan of that. now i
> took some time to think through why.
> conclusion
> determining the proper cost parameters should not be a part of the
> actual algorithm, and should come from outside. the parameters must be
> provided in an explicit format, that is, number of cycles, number of
> memory blocks, etc. it allows equivalent forms, like 2^t time, but
> disallows time in milliseconds.
> rationale
> 1. theoretical stand: separate things should be separate. it is
> conceptually different to determine the parameters and using them. use
> small code blocks, avoid swiss army knife antipattern.
> 2. many times we want to calculate the hash on different platforms,
> including the case of switching platforms in the future. it is unwise
> to lock the parametrization to the current platform.
> 3. if we always use fixed parameters, hashing the password the first
> time and checking a password does not differ at code/circuit level.
> this simplifies the code.
> 4. we lose nothing with taking fixed parameters. we can at any time
> offer the user a separate "benchmark" option. together with a table of
> preset values for different platforms.

I'd certainly like a password hash I used to have a function to
estimate the time for given parameters or to find parameters for a
given time and memory usage.  (Also, implementing such a thing might
cause password hashing algorithms that have time complexity that
heavily depends on password length to notice and fix it.)


> the above is an opinion. don't get offended, discuss!

Andy Lutomirski
AMA Capital Management, LLC

Powered by blists - more mailing lists