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(_dot_)strenzke(_at_)mtg(_dot_)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(_dot_)strenzke(_at_)mtg(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp