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

Hi, all.

On 09/09/2025 13:13, Daniel Huigens wrote:
> The way I envisioned this feature originally, I had in mind that an
> OpenPGP implementation could automatically choose whether to encrypt
> a message symmetrically or asymmetrically for each "recipient" (which
> potentially includes the sender), depending on whether it has a
> symmetric key for them or not.
> 
> And then, when decrypting a message, it could automatically choose the
> right key to decrypt, based on whether it was encrypted symmetrically
> or asymmetrically.
> 
> To make all of that work seamlessly and without the user having to think
> about it, I imaged an API could work as follows:
> 
> $ sop generate-key > alice-priv.asc
> # bundle of TSKs, one symmetric and one asymmetric
> $ sop extract-cert < alice-priv.asc > alice-pub.asc
> # asymmetric TPK
> $ sop encrypt --one-recipient-per-certificate-bundle [1] alice-priv.asc bob-pub.asc < msg > enc.asc
> # message encrypted symmetrically for alice and asymmetrically for bob
> $ sop decrypt alice-priv.asc < enc.asc
> # decrypted message
> 
> [1]:https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/124
> 
> If we want to enable SOP to specify an API like that, we should have a
> grammar that allows a mix/bundle of symmetric and asymmetric keys.
> To me, the simplest way to do that would be to extend the TSK grammar.

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.

A

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