Re: [openpgp] Memory requirement for Argon2 (draft-06, sec 3.7.1.4)

[Bruce Walzer <[e-mail]>]

On Mon, Jul 18, 2022 at 10:22:21AM +0000, Daniel Huigens wrote:
> Hi Bruce,
> 
> Since Argon2 is a symmetric construct, as a first assumption I think
> it's not unreasonable to say that the file will most likely be
> decrypted on the same device it was encrypted on.

True, but OpenPGP primarily exists for interoperability between
different systems/devices. The interoperability of both encrypted
files and encrypted private keys in this case. In cases where
interoperability is not required then you won't see the use of
something like OpenPGP. Remote backup systems are a good example, they
almost always create their own encryption structure, to meet the needs
of their own process.

> Of course, that won't
> always be the case, but if it's not it's not the end of the world, it
> will just be slower (or faster).

Then the question is more specifically: how much slower? There has to
come a point where it takes long enough to no longer be usable.

> In my opinion, the first recommended option should be fine, if the
> implementation doesn't know about the hardware that will be used to
> decrypt. The reason we don't standardize it is because these
> recommendations might change in the future.

OK, then 2GB it is. How much computational effort can I put in to make
it so that the time to decrypt is reasonable over a reasonable range of
systems after having specified 2GB?

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. Picking a reasonable upper limit of 10 seconds
means that the target system can be two orders of magnitude slower
before we hit our limit. That's a lot of range. How could I do
something as good using the parameters of Argon2? Instead of just one
parameter I have at least three. It makes it a complicated problem
with a lot of required assumptions.

Looking at this from the perspective of usability, how can I, the
application programmer provide some benefit to the user by picking
Argon2 instead of the current alternative? The potential benefit is
that the user could have a passphrase that is one word shorter (two
words shorter is unrealistic). Would it be possible to provide that
one word benefit? If yes, it is not clear to me how to set the
parameters so as to do that without risking an unreasonably long wait
on some reasonable systems. If no, then why bother with Argon2 at all
for OpenPGP?

I can't help but point out that this feels like another example of
what can happen when methods are grafted from one medium (client
server) to a different medium without careful consideration. There is
a potential advantage here, but more work needs to be done to clearly
identify it and properly define the path to realizing it.

Bruce