[openpgp] Re: SEIPDv1 algorithm obfuscation when using persistent symmetric keys

[Daniel Huigens <[e-mail]>]

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