-----BEGIN PGP SIGNED MESSAGE-----
On 04/23/2015 05:18 PM, Earle Lowe wrote:
> The maximum work factor for RFC4800 S2K is lower than the maximum
> for (eg) PBKDF2
Yes, although it is possible to match ones commonly used now (1k-3k)
and have a reasonable margin for raising the value (hitting around
100k is not a problem, which keeps the now-dying Moore law at bay for
another 10 yrs at worst).
> As the maximum for RFC4800 is specified in bytes, the iteration
> count (number of hash invocations) goes down as the size of the
> hash increases.
> The max iteration count for SHA1 ~= 2^22; SHA256 ~= 2^21; SHA512
> ~= 2^20, etc, etc
> (65011712 / sizeof hash)
> So in this case, you can have a much higher work factor for the
> other algorithms.
Looking at section 188.8.131.52, the formula for the work count is defined as:
#define EXPBIAS 6
count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);
where c is the octet-sized value stored. I could not find the
dependence of the work factor from the hash size: could you possibly
point me to it?
> Although I'm not sure it really matters that much when
> off-the-shelf and cheap GPUs can do billions of these a second.
With respect to this, picking a memory hard KDF such as scrypt
nullifies the benefits of massively parallel hardware, as there's no
way of getting both fast and large memories for [G|C]PUs, and a
sizeable amount of SRAM takes up a lot of space in a dedicated ASIC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
_______________________________________________ openpgp mailing list openpgp@xxxxxxxx https://www.ietf.org/mailman/listinfo/openpgp