* Is there any interest for a “more modern” S2K, or is the
Iterated+Salted S2K still considered fine enough for RFC4880bis?
I’d love to see it modernized. I despise the present S2K function. I recognize
that most of my reaction is not entirely rational, but I still despise it.
I know that what I despise about it is the stupid one-byte floating point
number for the “count” and the fact that the count is a number of bytes
generated, which means that it has massively different characteristics if you
change the hash function.
(Consider the same count with SHA256 and SHA512. Since it is a byte count, you
end up with half the number of iterations of SHA512 as SHA256, and on a 64-bit
CPU, they run at more or less the same speed with SHA512 often marginally
faster. This is completely counter-intuitive.)
From a security standpoint, though, there’s no real advantage to PBKDF2, even
if it’s better architected.
So all in all, as much as I’d like to do something, keeping the existing one is
good enough.
* If we want a more modern S2K, then is Argon2i the right choice?
I view this as primarily an implementation issue.
If I were to write that section, I’d put both Argon2i and Argon2d in. There are
reasons to go with either, and I’d leave that to the implementation.
Interoperability matters only when you transfer keys from one implementation to
another, and as time goes on that is less and less of a problem. (And the
grumpy part of me says that if you’re going to transfer to some new
implementation, maybe you want a new key, anyway even as I know that’s not
friendly.)
I believe it’s important also to have something that is merely a spin loop,
like the present iterated+salted or PBKDF2.
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp