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 19:41:44 -0800
From: "Dennis E. Hamilton" <>
To: <>
Subject: RE: [PHC] blakerypt sequential memory-hard function

When limiting our discussion to PHS, I completely agree with all of that.

I brought up auto-tuning when a compressed, exponentially-growing work factor parameter was mentioned.  It was a mistake, since we have driven off into the weeds.

 - Dennis


My use case for auto-tuning is in a place where valuable passwords must never be used, since the hash is not kept private.  The passwords used must be assumed to be compromised and subject to off-line attack.  The auto-tuned case is a palliative.  

Also, it is all done on the client, and as often as the user desires to employ this particular hashed-password situation.  

There is no prospect of having the user perform any sort of separate tuning.  If the user were that fluent, the particular hash method would not be used in the first place.  In the particular use case, the recommendation is to use new cryptographically-random values as faux hashes each time, with no actual password being hashed.  (This is a perfect fire-and-forget case where there is nothing available to be compromised and the only cost is the generation of the cryptographically-random bits.) 

For the curious, here's a screed about the particular case: 

-----Original Message-----
From: Krisztián Pintér [] 
Sent: Friday, December 6, 2013 14:54
Subject: Re: [PHC] blakerypt sequential memory-hard function

let me elaborate a little more on auto-tuning.

on what platform we need that?

on a pc or a tablet, we have plenty of space, time, horsepower to
offer a separate tuning/benchmark version of the algorithm. this way,
we can have a very streamlined, simplistic, safe working version,
obeying the KISS principle. and we have the benchmarking version that
does not even have to take a password, so it can not leak. failure is
not a problem.

on a resource limited platform, like an embedded system / hardware, we
probably want to save every byte/gate. but we also know the platform,
so we don't need to measure anything, we can just hardcode the

so either way, dynamic auto-parametrization seems like tacked on, and
should not be an integral part of the actual KDF.

one more thought: just like with rijndael or keccak, i expect any
standard to limit parameters to a few selected values. it is of course
good if the algorithm itself does not limit us, but we should not
focus too much on it.

at least, this is how i see it.

Powered by blists - more mailing lists