Re: [openpgp] Discussion regarding signalling of preferences for multiple encryption-capable keys

Hi there,

I would prefer not to mix signalling about using multiple subkeys
(if any) with hybrid algorithms. For example, what if you want to
express "please use these X25519+HRSS keys, *and* these X448+SIKE
keys (in that combination)"? It becomes very complicated.

For post-quantum crypto, I would prefer, as Greg also suggested,
to just define algorithm IDs for combinations of algorithms (e.g. one
for "X25519+HRSS" and one for "X448+SIKE"), and then have only one
(sub)key packet for the X25519 and HRSS keys, for example (with the
algorithm ID defining how to encode them). Of course there's some risk
of an "explosion of combinations", but I think we should work to
restrict that anyway, and having a set number of permissible
combinations is better than allowing arbitrary combinations.

Of course, then there's no backwards compatibility (by default)
in the sense of being able to use only the X25519 key by itself.
So, if you want that, you'd have to additionally add a separate X25519
("Curve25519 over ECDH", really) subpacket. Those keys are small so I
think that's fine. (Also, if we don't do that, it means we lock
ourselves into the weird "Curve25519 over ECDH" scheme even longer.)

Or, you might want to have a separate backwards compatible primary key
as well, for signatures; in that case you could just generate two
separate certificates. We have a similar issue currently with v4 and v5
keys; there you might also want to serve both for a while. If we
prepare our software now to support using multiple concatenated keys
(the spec already allows this), with the semantics being "use the first
one you support", for example (to be discussed), then that would help
us with the transition to post-quantum crypto as well.

Best,
Daniel

------- Original Message -------
On Thursday, April 14th, 2022 at 15:06, Falko Strenzke <falko.strenzke@mtg.de> wrote:

> I cannot post to the Design Team list, so I post it on this mailing list:
>
> Regarding the discussion around multiple encryption-capable subkeys, I
> would like to make the following remarks on behalf of the project
> PQC@Thunderbird. At IETF 113 we presented our ongoing project for the
> standardisation of PQC in OpenPGP. Well aware that this is not in the
> scope of the crypto refresh, we still want to make a comment on the
> signalling mechanism for a preferred usage of multiple encryption
> subkeys, as it is currently being discussed by the Design Team. The
> reason is that a related issue will in our view most likely also arise
> in the context of multi-algorithm encryption. What we refer to as
> multi-algorithm encryption is often also referred to as hybrid
> encryption and means the combined encryption with two public key
> encryption schemes in such a way, that the combined scheme is only
> broken when both constituent schemes are broken. "Both constituent
> schemes" will typically be a classical scheme and a PQC scheme. For such
> a combination of two public-key encryption operations, an algorithm for
> the derivation of the session key from the input-keys encrypted in each
> PKESK is also needed. Proposals for this exist and typically involve the
> use of a KDF.
>
> So far to introduce the background. Now we come to the point were the
> signalling of the intended subkey usage matters in this approach: If a
> user wants to restrict others to only sending him encrypted messages
> using multi-algorithm encryption with two specific encryption subkeys
> from his keyring in combination – i.e. not allowing them to use either
> of the two keys in the default "single-algorithm" manner, the question
> arises
> * how to signal to the sender that a certain encryption subkey must only
> be used in a multi-algorithm combination with another (specific) subkey
> from the same keyring (e.g. to indicate: "use this PQC key only in
> multi-algorithm encryption together with ECDH")?
>
> In our understanding this problem could be solved by a signalling
> mechanism analogous to the one discussed now regarding parallel
> encryption. The mechanism would have to be enhanced by a flag signalling
> the intended use of a key in the multi-algorithm context only.
>
> We just want to provide this piece of information for the case it
> matters for the ongoing discussion in Design Team.
>
> Best regards,
> Falko
>
> --
>
> MTG AG
> Dr. Falko Strenzke
> Executive System Architect
>
> Phone: +49 6151 8000-24
> E-Mail: falko.strenzke@mtg.de
> Web: www.mtg.de
>
>
> MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
> Commercial register: HRB 8901
> Register Court: Amtsgericht Darmstadt
> Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
> Chairman of the Supervisory Board: Dr. Thomas Milde
>
> This email may contain confidential and/or privileged information. If
> you are not the correct recipient or have received this email in error,
> please inform the sender immediately and delete this email. Unauthorised
> copying or distribution of this email is not permitted.
>
> Data protection information: www.mtg.de/en/privacy-policy
>
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp