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

[Paul Wouters <[e-mail]>]

On Sep 4, 2024, at 06:09, Falko Strenzke <[e-mail]> wrote:



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, https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-04.html" title="draft-connolly-cfrg-xwing-kem-04" rel="nofollow">draft-connolly-cfrg-xwing-kem 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?

I think that would be wise, yes. A few months delay against an as-of-yet theoretical quantum attack to ensure we got things right would be worth it to avoid wasting years of time of wrongly deployed data ending up being vulnerable.

Are you suggesting that we now adopt draft-connolly-cfrg-xwing-kem, an individual draft?

That draft will be adopted in CFRG.

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

Yes.

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.

It won’t, but.

Key, signature and ciphertext formats still have to be formally defined.

There might be guidance in a CFRG document. If this would still require a specification, the best would be to try and get a generic (hybrid)kem format for these that can be re-used with the different pure and hybrid kems.

I suspect some hybrid kems would see a cfrg document where pure kems would see a non-IETF normative reference.

Ideally, we try to limit the number of RFCs that specify openpgp hybrid constructs.

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 https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-04.html" rel="nofollow">current specification of composite KEM in LAMPS. They currently define https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-04.html#section-2.3.4" rel="nofollow">their own combiner and a pretty rich https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-04.html#section-5-4" rel="nofollow">set of PQ/T combinations (compared to OpenPGP):

Let’s hope the lamps AD will make them pause and wait to align / confirm with CFRG.

Paul