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

[Bruce Walzer <[e-mail]>]

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.

Argon2 is a hash with a primary benefit of memory hardness intended to
prevent efficient attacks from GPU/FPGA/ASIC hash crackers. It is
normally only used and usable in situations where the hashing is all
done on the same system. Assigning more memory results in more
resistance against GPU/FPGA/ASIC hash crackers so the normal practice
is to assign as much memory as possible. This is often more than a
gigabyte of memory.

RFC 9106 (the reference for Argon2 in the draft) has no explicit
provision for the case where there is not enough memory available to
do a Argon2 hash. Dealing with this situation is treated as an attack
(time-memory tradeoff) in the context of Argon2 (RFC 9106, sec
7.2). Implementations could not be expected to handle this situation
and there is no standard that covers it.

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. The current Argon2 proposal creates a
potential memory requirement on the part of the receiver of a
terabyte. If we were to limit it to current common Argon2 usage then
we would be in the gigabyte range which would still be beyond the
capacity of many systems. If we, say, limited it to 4 MiB to be
compatible with another discussion, then we would end up with a very
low resistance to GPU attacks. GPU attacks are the most likely as they
are the cheapest.

Since the protection given here is a continuum it would be good to
come up with a minimum tangible benefit for use in evaluating any
proposal. For example, I would consider an approach that did not at
least allow a user to drop a word from their passphrase to be not
worth the bother.

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.

Bruce