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

[Bruce Walzer <[e-mail]>]

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. 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. At any rate, it is very clear that
Argon2 is more complicated to set up than the standardized thing. So
if we are looking for an argument that the proposal is better than the
currently standardized thing then we will not find it here.

> >> Even if you don't, let's say you are archiving some data,
> >> experience tells us that available memory will grow, not shrink, so
> >> whatever memory you can supply now for the encryption, you can be sure
> >> that the future recipient will have enough to decrypt it.
> >
> > Memory here is the memory available to the task, not the overall
> > system. Restricting that memory is all the rage these days because of
> > containerization/virtualization and on mobile to overcome the effects
> > of misbehaving apps.
> 
> If you don't have enough RAM, you cannot decrypt it (in reasonable
> time).

If you don't have enough RAM, you cannot decrypt it at all. A typical
implementation would blow up with some sort of out of memory error.

> 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). I don't know what you mean by "OpenPGP version".

[...]

Bruce