Subject: Re: [openpgp] New S2K specifiers?

From: [email-masked]
Date: Mon, 01 Apr 2019 21:46:43 -0400

On 4/1/2019 at 12:03 AM, "Daniel Kahn Gillmor" <[email-masked]> wrote:
>
>On Sun 2019-03-31 13:10:24 +0100, Damien Goutte-Gattat wrote:
>> * Is there any interest for a “more modern” S2K, or is the
>>   Iterated+Salted S2K still considered fine enough for 
>RFC4880bis?
>
>I think having argon2i included in rfc4880bis would be concretely
>useful; iterated+salted hasn't been the best practice for S2K for 
>well
>over a decade.
>
>The main argument i can imagine against it is if no OpenPGP
>implementation has any plans or desire to implement it, or if 
>there are
>specific objections related to IPR.

=====

Will the new S2K be only for the V5 key format?
Or will it also be used for Conventionally Encrypted messages?

If it will be used for Conventionally Encrypted messages too, then there can be backward incompatibility issues, 
as well as intercompatibility issues with different implementations.

(I still think it's a good idea, but may be a really lot of extra work, so maybe only for V5 keys now).

vedaal

---

From: Jon Callas <[email-masked]>
Date: Mon, 1 Apr 2019 20:32:04 -0700

>  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

---

From: Jon Callas <[email-masked]>
Date: Mon, 1 Apr 2019 20:34:44 -0700

> On Apr 1, 2019, at 6:46 PM, [email-masked] wrote:
> 

It would be for any key, or for conventionally encrypted messages.

> (I still think it's a good idea, but may be a really lot of extra work, so maybe only for V5 keys now).

Remember, definition is not implementation. You’re right that from an implementation standpoint, it might be best to make messages default to the old S2K for a while, but do it for V4 and V5 keys as well.

	Jon

---

From: "Neal H. Walfield" <[email-masked]>
Date: Tue, 02 Apr 2019 08:15:04 +0200

> (I still think it's a good idea, but may be a really lot of extra work, so maybe only for V5 keys now).

s2k is also used for SK-ESKs (symmetric-key encrypted session keys)
[1].  When using SK-ESKs, we may not have a key as a reference point.
That is, it doesn't make sense to add a restriction of the form: only
use argon with v5 keys, as there may not be any keys when we want to
use argon!

I agree with Jon that the implementations can figure out when to phase
it in.  That's at least something that we have experience with.

  [1] https://tools.ietf.org/html/rfc4880#section-5.3

---

From: [email-masked]
Date: Tue, 02 Apr 2019 14:20:28 -0400

=====

The issue is, that if it is not expressly implemented otherwise, the S2K used for the V4 or V5 key private key, 
will be the one that automatically defaults to the S2K for SK-ESK

(reasonable behavior, actually:
The most important security choice for the user is how to protect the user's private key, 
and presumably the user would like to give ESK's the same protection. This is also why the symmetric encryption algorithm choice for the private key, becomes the default algorithm for the ESK).

Current Implementations already do this by default, 
and implementers need to be aware to actively 'undo' it once the new S2K is adopted.

vedaal

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 Apr 2019 12:34:39 -0400

On Mon 2019-04-01 20:32:04 -0700, Jon Callas wrote:
> 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.)

It's not quite this simple, as S2K is also used in SK-ESK's (as Neal
points out elsewhere in this thread).  So that means
"password-protected" OpenPGP messages, which are very often exchanged
between parties, so interoperability is important.

having both specs in the standard makes interop more challenging, so it
would be better to just have one if possible.

        --dkg