phc-discussions - RE: [PHC] blakerypt sequential memory-hard function

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]

Message-ID: <010101cef2fe$4103b4e0$c30b1ea0$@acm.org>
Date: Fri, 6 Dec 2013 19:41:44 -0800
From: "Dennis E. Hamilton" <dennis.hamilton@....org>
To: <discussions@...sword-hashing.net>
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

OFF TOPIC

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: 
<https://tools.oasis-open.org/version-control/svn/oic/Advisories/00009-ProtectionKeySafety/trunk/description.html>.

-----Original Message-----
From: Krisztián Pintér [mailto:pinterkr@...il.com] 
Sent: Friday, December 6, 2013 14:54
To: discussions@...sword-hashing.net
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
parametrization.

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.