The maximum work factor for RFC4800 S2K is lower than the maximum for (eg)
PBKDF2
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.
Although I'm not sure it really matters that much when off-the-shelf and
cheap GPUs can do billions of these a second.
I'd like to see PBKDF2 simply from an "certification" point of view (it's
well known to various certification agencies - common criteria, cesg, nist)
(although for others that same reason might be a detractor)
-Earle
On Thu, Apr 23, 2015 at 3:37 AM, Alessandro Barenghi <
alessandro(_dot_)barenghi(_dot_)polimi(_at_)gmail(_dot_)com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/23/2015 09:38 AM, Nils Durner wrote:
Hi,
-- Mode 3 has a maximum working factor of 255 (one octet to
specify iterations),
The one octet encodes much larger values, see RFC 4880 section
3.7.1.3. for the formula applied to it. A literal value of 255 in
this octet would compute to an iteration count of 65 millions.
Yep, sorry, my mistake. It is possible to tune the work factor to
match common ones for PBKDF2 in S2K.
The point on fixed memory requirements, on the other hand, still holds
in favor of scrypt
Cheers
Alessandro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlU4y4IACgkQE+mB79BmI3FR1AEAmiJ25uiY3cGP8HC2Kb66ZoO4
S7cD++B76xa598iBzqoBAJhFY2/bQb35Fw15NeLlay6gqY/TNi/LEwNaooyVGHBz
=6tlE
-----END PGP SIGNATURE-----
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp