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

Daniel Huigens <[email protected]> Mon, 10 Nov 2025 13:52:33 +0000
Newsgroups gmane.ietf.openpgp
Message-ID <shTOu3XI2SQ63geMTpXnqdavuygZSTmzjnLRO10N8b_AmAMhNfMaGWxRsfm75E-djEfV33cuW-n7mur47Jt0sfmVnnToaBS_w0P9jGW5WyU=@protonmail.com>
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.

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.

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.

Best,
Daniel

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