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
| ||
|
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.
Powered by blists - more mailing lists