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

Daniel Kahn Gillmor <[email protected]> Tue, 21 Oct 2025 09:28:42 -0400
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
On Mon 2025-10-20 14:53:30 +0100, Andrew Gallagher wrote:
> I think this use case is reasonable, and it's an intuitive extension of 
> existing behaviour. Basically we're telling the implementation "here's a 
> bunch of secrets, do your best" and this makes sense regardless of 
> whether these are symmetric or asymmetric secrets. I prefer extending 
> the TSK grammar over defining a new (if trivial) "TSSK" grammar.

With no hats on, i agree that the TSK grammar is an obvious fit for the
persistent symmetric keys.

However, that's not the tricky change that we need to juggle to keep a
high-level API like SOP simple.  The tricky change is dealing with the
CERTS object (aka the "transferable public key").  These objects can be
used to verify signatures and to encrypt data, and until now, those APIs
have two properties:

 - they don't accept a TSK (keeping TSKs and CERTS objects distinct
   might help avoid the silly failure mode where the user accidentally
   transmits their secrets to their peer, rather than their public keys)

 - they don't require a password (while TSKs can be locked, CERTS
   objects can't be).

Designing a safe API that can handle a persistent symmetric key in
places where you normally have a CERTS object seems challenging.  i
mean, it's easy to just say "you can put a persistent symmetric key
anywhere that you put either a KEYS object or a CERTS object", but then
you've lost what was otherwise a pretty useful type check.

As the current maintainer of SOP, i need to work out how to do that
safely for encrypting and verifying -- and it might look different for
each of those operations.  I'll try to propose an MR on sop for folks to
consider, to see whether we can keep the semantics clear and safe.

I think the underlying cryptographic expansion we're talking about for
this draft is relatively straightforward.  But there are many different
ways to choose from for the wireformat.  And the conceptual changes to
the user model are probably the most challenging to model!

I really appreciate all the on-list discussion here as we figure out how
to move forward.

       --dkg

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 324 B)