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

Hi Heiko,

Thanks for the detailed comments!

I'll focus on the last point a bit:

On Friday, September 5th, 2025 at 17:26, Heiko Schäfer <[email protected]> wrote:
> 5. Transferable Persistent Symmetric Keys
>
> I'd strongly prefer not to extend the TSK grammar to allow including
> persistent symmetric key packets.
>
>
> Instead I'd prefer that we define a new and separate grammar for
> "transferable persistent symmetric keys" (TPSK), which allows exactly
> one persistent symmetric key packet per TPSK (i.e. a TPSK consists of
> exactly one key packet, without any signatures or subpackets).
>
>
> Specifying more complex composite TPSKs (that include signatures and
> potentially multiple key packets) could have two benefits:
>
> - Binding signatures allow inclusion of metadata (Bart mentioned that he
> finds it appealing to have that option).
> - Binding signatures allow the keyholder's software to check that the
> subkeys are legitimate, as long as the software knows that the primary
> key is the right one.
>
> However, I'm very unconvinced that either of those two potential
> benefits are worth the complexity of composite TPSKs.

When thinking about splitting vs extending the grammar, we should also
think about how and where the resulting grammar(s) are going to be used,
in an API (such as SOP).

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.

Another option is to specify grammars for TSK, TPSK, and T{PS,S}K; but
that only seems useful if we want to specify certain APIs that only
accept TSKs or only accept TPSKs, as opposed to both/a mix. I'm not
sure if there are cases like that?


Then, working backwards from there, if we're going to allow TSKs using
symmetric keys, there's still the question of whether we should extend
the secret-key packet to allow using symmetric algorithms, or define a
new packet and extend the grammar to include that new packet; and also
(in the latter case) whether a persistent symmetric key should accept
any other "components" such as User IDs and subkeys. Originally, the
idea of allowing those was that it would make the management and usage
of symmetric keys more similar to that of asymmetric keys. But, if folks
strongly prefer to have symmetric keys be a standalone packet, I think
that would also be OK, modulo the point above that they should still be
allowed in a key bundle, IMHO.

I take the (implied) point that extending the TSK grammar may complicate
the API and implementation for OpenPGP libraries. However, if we don't
do so, I worry that we'll complicate the adoption in higher-level APIs
such as SOP, and/or make it more difficult for applications to use
persistent symmetric keys.

Best,
Daniel

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