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

[Ángel <[e-mail]>]

On 2022-07-29 at 22:21 +0000, brian m. carlson wrote:
> 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.

What if the goal of the sender is not to communicate with the receiver
but to break it?

I'm late to the party, but this is a point that has not been mentioned
before and I think it is worth pointing out.

A client SHOULD have some limit to avoid a "Zip bomb" equivalent with
the Argon2 function (this is not specific to Argon, the same issue
exist with any other memory hard function). Let's call it a "memory
bomb".

It's not acceptable that an attacker sends a symmetric encrypted email
requiring orders of magnitude more memory than available and that
causes:
* A PGP remailer to go down
* A MUA to crash
* An open browser to crash
* A backup server no longer accepting backups
* The receiving system slows down until it swaps everything and the OOM
killer is finally run

even if there is some user interaction needed (like providing a
passphrase) where the user is not warned beforehand of the adverse
effects.


As a mitigating factor, the S2K is used in two cases:
* Storage of private keys (and one should not be importing untrusted
private keys)
* Usage with symmetric encryption (whereas most scenarios should
actually be using public-key cryptography instead)


However, I wouldn't be surprised if programs intended to be used with
public key crypto actually attempted symmetric decryption, such as
trying a private key passphrase against a Symmetric-key Encrypted
Session Key or importing a private key when provided what should have
been a public key.


I think this deserves a security note in the document about the need of
enforcing _some_ limit. Options available to implementations include
setting an arbitrary limit to the memory they are willing to use for
S2K (hardcoded or in config), dynamically compute an "appropriate
limit", to support processing packets larger than those limits but
requesting user confirmation for potentially using lots of memory…


Regards