[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]