Re: [openpgp] New S2K specifiers?

[Jon Callas <[e-mail]>]

> 
> * 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