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

Daniel Huigens <[email protected]> writes:

> 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

I think it is interesting to consider creating a new kind of key packet
for persistent symmetric (sub!)keys.

> 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.

I think wouldn't mind the new kind of key packet also using PKESK
packets and signature packets.

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

That seems more expensive than MACing the data though, and the
properties are slightly different.  If you lose the key, you not only
lose the way to authenticate the data, you lose the data.  If, for
example, creating that data was very expensive, people may prefer having
unauthenticated data over having no data at all.

> 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.

Defining an TPSK seems less useful to me.  We can also change the TSK
grammar to allow persistent symmetric subkeys.  In fact, by marking them
as non-critical, existing software should just ignore them (though
ignoring them could also mean not stripping them when extracting a TPK
from the TSK).

The challenge of implementing this proposal for us, and I imagine for
other implementations as well, is that suddenly the encryption and
verification operations have a new failure mode when trying to use a
locked key.

So making persistent symmetric keys less similarly-shaped than other
keys has the advantage that we can now say: this is a persistent
symmetric key, and if you want to use it with PKESKs or Signatures to
either create or consume them, you will need to use this other interface
to do that.  I.e. we can avoid shoehorning the new semantics into the
old interface.

Best,
Justus

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

-----BEGIN PGP SIGNATURE-----

wsC7BAEBCgBvBYJogOBzCRCI3H4zOF95HUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u
cy5zZXF1b2lhLXBncC5vcmc+nTIay+bFZtIPUkChixBut0USNqSDWCrehRHihzSn
CBYhBCVqTlXkpy2XrSRo54jcfjM4X3kdAACgWQf7BZomQtKeZ5GaIkoMHAS6HI6D
ufoi1bScPM5sCi+TSQfJWrLcJtOCFC42IeRsMXZdIop2dZaY21bHwOBtdfBRxvWM
RwSHNkU/DbMRKFKY4RzqmDZ6Zlt8oeP/VfhjcAJUhMmjsWLc4nhUnjIddWEs0DHw
XSKj+H9pbJIS+5jLc5U1JYC5wQxw020DQ/SQQEKgNBNBWwmmDckILvXoD7ksBy5L
DrRQ1Clt9Pd/bF1x9JIiWdU+3OD4NIYVBE0jmN6YWQwWpQvmsKBpxS8OmHOUdN1f
mHigWMlmriw8pXjoWkqlQu4u3pD8maMuLEWZoOOM21g/gnxd3kQYTGV0dvjfgQ==
=DjHV
-----END PGP SIGNATURE-----