[openpgp] Re: on the risks of AEAD as signature [was: Re : draft-ietf-openpgp-persistent-symmetric-keys-02.txt]

On Mon, 2025-11-10 at 13:52 +0000, Daniel Huigens wrote:
> Hi dkg & all,
> 
> As far as I can tell, if you control the key generation of the
> persistent symmetric key, and store it securely/encrypted, then
> there's no risk here.
> (If you don't, then you have bigger issues as Falko points out.)
> 
> The reason we added an HKDF step for AEAD in SEIPDv2 and S2K usage
> octet 253 was to thwart cross-AEAD-mode attacks, not key commitment.
> That's not an issue here if we bind the key material to the AEAD mode.
> 
> However, Lara Bruseghini pointed out (in parallel) that there's
> another potential reason we might want an HKDF step, namely the usage
> limits of GCM. The maximum number of messages that can be safely
> encrypted is 2^32, which is perhaps in the realm of feasibility to
> reach when encrypting many small messages or incremental updates to
> a draft message. And, since we're talking about persistent/long-lived
> keys here, this is more of a concern than in other scenarios.

This limit exist because nonce-reuse is catastrophic, and given you
have 2^64 bytes per message the birthday paradox forces this small
limit. Using AES-GCM with a fixed key is extremely tricky if you can't
ensure that nonces are never reused, it should definitely not be done.

> Thus, it may be worth adding an HKDF step anyway. This would remove
> the message limit and the need to further analyze/debate the need for
> key commitment, domain separation, and so on.

A potential alternative is to standardize the use of AES-GCM-SIV.
It is slower on encryption, but that shouldn't be a huge issue for
openpgp. I would still recommend the use of a key derivation step
regardless.

> Finally, it would also allow us to move the AEAD mode and symmetric
> algorithm ID back from the key packet to the PKESK/Signature packets,
> which would remove the need to generate a new key when switching/
> upgrading to a new algorithm, making migrations easier.
> It would also make parsing slightly nicer, as the IV size is then
> more easily known.
> 
> So, if that seems reasonable, I'll add an HKDF step to the editor's
> draft.

Key derivation in these cases is always a very good practice, and
should always be done unless there is a compelling reason not to.

Simo.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]