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

[Justus Winter <[e-mail]>]

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

>> 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).  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).  If your computation environment is unsuitable, you
won't be able to decrypt it.  That is no different from the status quo.

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

On the one hand you are worried that the recipient won't be able to
decrypt it because of computational constraints, on the other hand you
are unhappy that the algorithm can be tuned to the target system.  Which
one is it?

And, it even gives you an algorithm to tune the parameters.  You were
quite fond of how GnuPG tunes the S2K octet count.  You should be extra
happy that the same can be done for Argon2.

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

It is easier, but it denies recent advances in the kind of computation
environments that are available to adversaries.

Best,
Justus