Re: [openpgp] The Argon2 proposal seems incomplete (Draft 6)

[Justus Winter <[e-mail]>]

Bruce Walzer <[e-mail]> writes:

> On Thu, Jul 28, 2022 at 12:00:57AM +0200, Justus Winter wrote:
>> Bruce Walzer <[e-mail]> writes:
>> 
>> > On Tue, Jul 26, 2022 at 06:51:25PM +0200, Justus Winter wrote:
>> >
>> >> > OpenPGP is a messaging standard and has to be such that
>> >> > interoperability is possible between different systems. That is at
>> >> > odds with normal Argon2 usage.
>> >> 
>> >> If you are doing pre-shared key encryption, you have to communicate the
>> >> key to the recipient, hence you do know in what context the data will be
>> >> decrypted.
>> >
>> > How would this work in practice? Would we ask the user for the Argon2 parameters at encryption time?
>> >
>> >     Enter passphrase: ***********************
>> >     Enter memory available for decryption (KiB): 2000
>> >     Enter execution threads available for decryption: 8
>> >     Enter passes for decryption: 3
>> 
>> How would S2K work in practice?
>> 
>>      Enter passphrase: ***********************
>>      Enter S2K type: Iterated and Salted
>>      Enter hash algorithm: RipeMD160
>>      Enter octet count: 65000000
>>      Error: Invalid octet count, must be a integer solution to (16 + m) * 2^(6 + e)
>>      Enter octet count: 65011712
>
> We were discussing the Argon2 proposal and suddenly we are discussing
> the existing standardized thing.

We are not suddenly discussing S2K, in fact, it was you who brought it
up in your very first mail:

> Another thing I don't know, how much memory is required before the
> memory advantage provided by Argon2 is actually effective and helpful?
> Would there come a point where Argon2 provides no value over, say,
> "Iterated and Salted S2K"?

And again in your second mail:

> As a practical example, GnuPG adjusts the amount of computational
> effort so that it takes 0.1 seconds to decrypt on the system the S2K
> operation was done on.

Now, when you say that:

> I an arguing that the Argon2 proposal as it exists should not be
> included in an OpenPGP draft. I an hoping that argument can stand on
> its own.

And at the same time do not propose an alternative, I think you are
arguing that the current system is sufficient.  I have pointed out that
it is not for two reasons: first, single core performance outscales the
S2K parameter space, second highly concurrent computation environments
that are nowadays available require memory-hardness, which S2K lacks.

>> This is not unlike the situation that you won't be able to
>> decrypt it if you don't support the cipher, AEAD mode, or OpenPGP
>> version (anymore).
>
> Which is why we should avoid such situations if possible by only
> changing these things when absolutely necessary. Note that I strongly
> oppose the addition of AEAD modes for this very reason (among
> others).

The current SEIPv1+MDC is impossible to implement securely.  Efail, one
of the best attacks on OpenPGP ever, is a direct consequence of that.
If you don't understand that, maybe you lack the experience to gauge
whether a replacement for the SEIPv1+MDC system is needed.

> I don't know what you mean by "OpenPGP version".

While this is a bit of a loose term, if you don't understand what I mean
by that, we lack the common terminology to discuss the revision of this
protocol.  Therefore, I will stop engaging.

Justus