[openpgp] Re: WG: BSI view on KEM combiners

[Falko Strenzke <[e-mail]>]

Hi Daniel,

Am 04.09.24 um 10:53 schrieb Daniel Huigens:
> Hi Falko,
>
> Pedantically speaking, X25519 vs ECDH-brainpoolP256r1 is not just a 
> different parameter, it's a different algorithm. And in any case, CFRG 
> could definitely help with defining a combination of two KEMS (both 
> the KEM combiner and the specific component algorithms). For example, 
> draft-connolly-cfrg-xwing-kem 
> <https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-04.html> proposes 
> one such combination that we could adopt wholesale in 
> draft-ietf-openpgp-pqc (though that's a separate discussion).
>
What I don't see is what is specific to Brainpool parameters here. 
Everything you suggest regarding CFRG defining a combination of two KEMs 
that we adopt equally applies to the combination of ML-KEM+X25519 (and 
also ML-KEM+NIST-P-...). Otherwise please clarify where you see the 
difference. So how should we understand your standpoint – do you also 
suggest to first ask CFRG to standardize ML-KEM+X25519 (and +X448) 
before we can finalize it in draft-ietf-openpgp-pqc, at the risk of 
delaying the – in my view overdue – introduction of PQ/T encryption in 
OpenPGP?

Are you suggesting that we now adopt draft-connolly-cfrg-xwing-kem, an 
individual draft? Adopting any construction that is not finalized as an 
RFC or at least very close to finalization in my view is not a good 
idea. This is why I am looking forward to the publication of [1] and 
(also any concrete output from CFRG of course, it's just that that 
doesn't seem to be at hand right now).

> Then, if CFRG also defines a combination of ML-KEM+Brainpool, perhaps 
> we could simply add a registration to the public-key algorithms 
> registry, with a reference to the CFRG spec, without needing any 
> separate spec in the OpenPGP WG?
>
I don't think that CFRG will write a spec that defines how an algorithm 
is used in OpenPGP. Key, signature and ciphertext formats still have to 
be formally defined. Or can you point to any precedent case, where 
something similar has been done? I want to point out that RFC 6637 
<https://www.rfc-editor.org/rfc/rfc6637.html>, which introduced ECC into 
OpenPGP, has 14 pages, even though it did not all introduce any new 
algorithms.

But you are certainly right that we wouldn't necessarily need an RFC. 
The introduction of new algorithms can in principle be done based on an 
external specification ("specification required" for registering new 
algorithm IDs).

>> What exact question do you suggest should be asked to CFRG? What 
>> aspect to you expect to be clarified or resolved through that?
>>
> I didn't mean to propose to ask them a question per se, but rather to 
> inform them of the position of the BSI (given that it might have 
> implications for the use of cryptography in all IETF protocols), and 
> then (if they agree it's a valid concern that should be addressed in 
> the CFRG) propose to standardize a combination of ML-KEM+Brainpool 
> (for example), that could then be used in OpenPGP.
>
> This way, we have a higher chance of achieving some consistency 
> between the algorithms used across IETF protocols.
>
I appreciate your intention to achieve more alignment across working 
groups. As I wrote above, I don't see why this should be limited to 
Brainpool parameters. I asked you above whether you suggest this in 
generality for our efforts to standardize PQ/T KEMs. If not, I would be 
happy to understand the reason.

In any case, as stated above, we are happy to check if we can align the 
OpenPGP KEM more with LAMPS based on [1] – but certainly not just for 
the combinations with Brainpool parameters.

By the way, check out the current specification of composite KEM in 
LAMPS 
<https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-04.html>. 
They currently define their own combiner 
<https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-04.html#section-2.3.4> 
and a pretty rich set of PQ/T combinations 
<https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-04.html#section-5-4> 
(compared to OpenPGP):

- MLKEM512-ECDH-brainpoolP256r1
- MLKEM768-ECDH-brainpoolP256r1
- MLKEM1024-ECDH-brainpoolP384r1
- MLKEM512-ECDH-P256
- MLKEM768-ECDH-P256
- MLKEM1024-ECDH-P384

This shows that what we are doing in draft-ietf-openpgp-pqc or proposing 
in draft-ehlen-openpgp-nist-bp-comp is not an outlier, it is how other 
working groups (at least LAMPS) also proceed.

They propose even one more code point than we have in our proposal. If 
anything, this shows that they are already taking the requirement to 
account for NIST and BSI compliance seriously. The same applies to their 
choice of composite signature combinations 
<https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-sigs-02.html>. 
To me this clearly points us to also consider at least a similar set of 
code points in OpenPGP.

Best regards,
Falko

> Best,
> Daniel
>
[1] National Institute of Standards and Technology (2024) 
Recommendations for key-
encapsulation mechanisms, (National Institute of Standards and 
Technology, Gaithers-
burg, MD), NIST Special Publication (SP) 800-227. [Forthcoming; will be 
available at
https://csrc.nist.gov/publications]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: [phone]
E-Mail: [e-mail]
Web: mtg.de <https://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: Privacy policy 
<https://www.mtg.de/en/privacy-policy>