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

Bart Butler <[email protected]> Wed, 23 Jul 2025 12:26:23 +0000
Newsgroups	gmane.ietf.openpgp
Message-ID	<0EY-XLSa_Ibbry0ilJL_mho0Uw22q5A7ax5cPbTXuG9mzKLS0rNl9PVFfO1xpYC80ZQuncnNGhrCbpWUJcXS3YbdFEtlOmRqWKwsa1eBBiU=@pm.me>
To elaborate on my "likely useful" comment I think it would be nice to have the option to generate a completely symmetric OpenPGP private certificate for archival or other private purposes so I'd prefer to retain the ability to do self-signatures via HMAC as well.


On Wednesday, July 23rd, 2025 at 10:47 AM, Bart Butler <[email protected]> wrote:

> 

> 

> 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]
signature.asc (application/pgp-signature, 343 B)