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: <1037471316.20131206235332@gmail.com>
Date: Fri, 6 Dec 2013 23:53:32 +0100
From: Krisztián Pintér <pinterkr@...il.com>
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.