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

[Bruce Walzer <[e-mail]>]

On Tue, Jul 26, 2022 at 06:51:25PM +0200, Justus Winter wrote:
> Bruce Walzer <[e-mail]> writes:
> 
> > The Argon2 proposal seems incomplete (Draft 6)
> >
> > This fell out of a discussion on a different thread. I think I can now
> > express this in a more coherent way.
> 
> Don't split threads like that.  At best it looks like an obvious attempt
> of leaving the dissenting voices behind.

That was not my intent. My experience has been that where an incorrect
fact has become woven into a discussion that it is better to start
over with the correction as part of the initial assertions than to try
to detangle the exiting discussion. The incorrect fact in this case is
that Argon2 will work in some sort of slower degraded mode in the case
where not enough memory is available.

[...]

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

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

> 
> > I think that more work needs to be done here to generate a valid
> > proposal. At this point it is not clear to me that such a proposal is
> > even possible. We might have to in the end consider other
> > approaches. As it is, we are basically dumping a complicated
> > technology into a long term standard with all the knobs exposed with
> > the hope that someone will come along later and find an effective use
> > for it.
> 
> It is not complicated.  It is not new.  It is widely implemented, and
> the RFC gives recommendation for the parameters.

Multiple, widely different recommendations.

> Note that for the
> legacy S2K mechanisms, even though there are multiple knobs, the RFC
> gives no guidance whatsoever.

The only relevant knob is the count for "Iterated and Salted S2K"
which directly maps to CPU difficulty. One degree of freedom is much
easier to deal with than several. 

> 
> If you have a counter-proposal for a password-to-key derivation
> mechanism, please produce a constructive proposal.

It is probably just me, but the general subject of improved S2K
schemes feels like something that should be discussed in a new
thread. :)

Bruce