[openpgp] Re: Persistent Symmetric Keys: new algorithms or new packets?

My 2c is that I prefer the existing proposal (treating the persistent symmetric key as just another algorithm within the existing packet types) rather than creating new packet types, as I think it's much cleaner and the differences between it and public key algorithms are nicely handled just by the non-existence of a corresponding public key encryption subpacket.

We could consider dropping the HMAC part separately (part 2) but I do think that the ability to do self-signatures is likely to be useful so I would keep it.

-Bart

On Tuesday, July 22nd, 2025 at 6:32 PM, Daniel Huigens <[email protected]> wrote:

> 

> 

> Hi folks,
> 

> In anticipation of the meeting session on Friday, I wanted to pose the
> following question to the group:
> 

> I got some feedback in private regarding the persistent symmetric keys
> draft, which came down to two points:
> 

> 1. Reusing and renaming the packets may cause some confusion and
> complexity.
> 2. Given that AEAD offers integrity, do we really need HMAC?
> 

> Taken together, this would lead to an alternative proposal, of defining
> two new packets:
> 

> 1. Persistent Symmetric Key Packet
> 2. Persistent Symmetric Key Encrypted Session Key Packet
> 

> These could then be used to store a symmetric key, and symmetrically
> encrypt a session key using that key. This would still lead to some
> duplication (of the Secret Key and Public Key Encrypted Session Key
> packets, respectively) but a bit less than if we also had to duplicate
> the Signature packet, for example.
> 

> And then, even if you mainly wanted to provide integrity you would just
> also encrypt the data.
> 

> We could then define a new Transferable Persistent Symmetric Keys
> grammar, that consists of just a Persistent Symmetric Key Packet.
> Unlike Transferable Private Keys, they cannot be converted into
> Transferable Public Keys.
> 

> You then also can't make self-signatures, which means you can't set
> metadata on a TPSK, such as a validity period (unless we encode it in
> the packet directly, v3 style), but maybe it's not really needed and
> can be stored externally by the application if necessary.
> 

> This would arguably simplify the proposal and more clearly delineate
> the semantics. However, it would also make persistent symmetric keys
> less similarly-shaped to other keys, which may make them harder to
> work with.
> 

> For example, I think it can be useful to store a persistent symmetric
> key together with a private key, and use it automatically when
> encrypting to yourself. Though, perhaps this could also be handled
> by the application.
> 

> Obviously it's also a bit late to make such a drastic change.
> However, if the WG prefers this, I can update the draft.
> 

> Let me know what you think. And, we can discuss more on Friday :)
> 

> Best,
> Daniel
> 

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

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

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmiAoY0JkJkFRGXvMx5ERRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmd/IhcKUJ5yLP7ShDVDazIBylPNczYAuOPFBtaN
x/x9HxYhBDwVkTeBh+6myif6rJkFRGXvMx5EAAC7sgD9HBdD8uP+cV9Aw3cb
Eq3xIL51JRtT8syvs5op/5qaAsABAO6gTTkpLYIq6V4By7AamKaD7wYoaI1j
xRrv4wCV/YEF
=5ggg
-----END PGP SIGNATURE-----