[openpgp] Re: SEIPDv1 algorithm obfuscation when using persi stent symmetric keys
Daniel Huigens <[email protected]> Tue, 10 Feb 2026 14:02:44 +0000
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Message-ID | <1-WHKToLVe62A-6conl4dv9QRdQJFEBQiK6K7KmGylWSlgjlUevQz8xvEdTr7__mCDJKo4UzxQpFuV7ScYnQEwefp5CZZjLCr4QocDAj5fw=@protonmail.com> |
Hi all, Due to the cacaphony of opinions on the list, I went with the option that seemed most reasonable to me: I've added the SEIPDv1 algorithm ID inside the encrypted session key, like ECDH and RSA do, but I've not added the option of padding (unlike ECDH), as I don't think it's widely used anyway. Let me know if there are any objections to this. I've also published an updated draft (-03), with updated test vectors. We have experimental implementations in OpenPGP.js and rpgp which now interoperate properly :) Best, Daniel On Monday, January 26th, 2026 at 18:42, Daniel Huigens <[email protected]> wrote: > Hi all, > > In the meeting today I said that for v3 PKESKs using a persistent > symmetric key, we should add a cleartext symmetric algorithm ID > indicating the algorithm used by the following SEIPDv1 packet, > like we did in X25519 and X448. > > In those algorithms, we also mandated for this algorithm to be AES, > to prevent algorithm confusion attacks. However, in the case of > persistent symmetric keys, there is actually a use case for allowing > other algorithms, namely if you're re-encrypting session keys of old > messages that use a different algorithm. So, we should make sure that > the algorithm ID is covered by the integrity tag, either by adding it > to the HKDF info or additional data, or by just encrypting it together > with the session key, as we do in ECDH and RSA. > > The latter may be preferable in this case, because we may not want to > reveal if a message is encrypted using IDEA or TripleDES or so, in case > one of those algorithms is ever broken. There's also no significant > downside to doing so as AEAD algorithms accept any plaintext length, > unlike AES-KW. > > In addition to that, ECDH allows you to hide the session key length > using padding, to prevent distinguishing between AES-128 and AES-256, > for example. Is that something we should care about here? If so, > we could allow padding the session key with zeros, or so. > > (I don't personally think that that's super important, but I'd hate for > someone to claim that symmetrically re-encrypting a session key is ever > a downgrade, for example.) > > Best, > Daniel > _______________________________________________ openpgp mailing list -- [email protected] To unsubscribe send an email to [email protected]