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

["brian m. carlson" <[e-mail]>]

On 2022-07-29 at 14:55:51, Bruce Walzer wrote:
> The issue I am most concerned about is that it appears that the Argon2
> proposal was dropped into the draft without any definite rationale. I
> think that things like benefits, costs, and in this case, usability
> should be pinned down before discussion and potential inclusion in a
> draft. You can't really come to terms with something if no one can be
> sure exactly what it is. The fact that we are currently discussing
> mere practicality supports my concern. This sort of thing can bring
> the entire process into disrepute.

It's my experience that Argon2 has been discussed quite a bit on the
list, at least in the past.  It is the winner of the Password Hashing
competition and is extensively used.  It's memory hard, which is the
cryptographic norm these days, and it has a variety of implementations
across languages, including in languages such as Rust which can be used
in web browsers.

It is the case that there are more parameters here.  The RFC provides
recommended parameters for when there isn't any other context.  Whether
an implementation allows for customization of these parameters or use of
parameters other than the defaults based on additional context is a
quality of implementation issue.  For example, a custom implementation
which is designed to be used only on embedded devices will almost
certainly use a different parameter set which is not customizable but
which is appropriate for the context.

It is also the case that the sender can send a message which exceeds the
resources of the receiving system.  If the sender earnestly wishes to
communicate to the receiver, that is of course silly and should be
avoided.  This is, however, no different than using a cipher or AEAD
algorithm that the receiver cannot support (or, for that matter, using
any other password hashing algorithm, such as bcrypt, with excessive
settings for the parameters), and can be dealt with in exactly the same
way, and the customizability here is also a quality of implementation
issue.  If the sender wishes to be very conservative, they can use a
sending implementation which uses the RFC-recommended small parameter
set, just as they can adopt the must-implement algorithms when sending.

The fact that there are more parameters is intrinsic to all memory-hard
password hashing functions.  scrypt and yescrypt have similar parameters
as well; Argon2 is not alone here.  If we are to adopt the state of the
art in password hashing functions, we will have to acknowledge this as
an intrinsic quality of the algorithm we adopt.

The WG charter is to work on a crypto refresh.  That implies that we
should adopt a set of algorithms which are presently thought to be
secure and are expected to be so long term.  Argon2, in my view, fits
that criteria, as would other memory-hard password hashes like scrypt.
I don't believe that an algorithm which is not memory-hard would
qualify, given current cryptographic norms, and I doubt such an
algorithm would achieve working group consensus.

If you specifically believe that some other algorithm is superior given
the working group charter, I'd invite you to propose that algorithm.
However, I think given the contributions of other contributors, that the
status quo is clearly inadequate in terms of security, and since, in my
view, a memory-hard password hash is the only viable choice
cryptographically, we need to consider some algorithm meeting that
criterion.  Nobody has yet proposed such an alternative that has met
working group support, so unless you plan to do so, I would suggest we
keep Argon2.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA