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

["Ehlen, Stephan" <[e-mail]>]

Dear Daniel,

sorry for the slow response. Before responding to newer e-mails regarding the draft
that includes brainpool and NIST curves, I should finally answer your question here:

Given our current recommendations, the BSI would most likely not accept
a composite of ML-KEM-1024 + X448 for use in products used to process confidential information.

Personally, I don't agree with your analysis that the quantum-vulnerable part of a composite algorithm is somewhat less important or doesn't need to be approved since it is only fallback. 
Note that it is our general recommendation to use a hybrid and to NOT use pqc algorithms (except HBS) standalone. Therefore, there is no recommendation from BSI to use ML-KEM standalone at this point. We are recommending the use of hybrids in order to provide more robustness and 
in particular to offer protection from unexpected advances in cryptanalysis of the PQ-scheme involved or sidechannels / implementation issues etc. Therefore, it makes perfect sense to insist that this "fallback" option is recommended by BSI, as well.

Best,
Stephan

> -----Ursprüngliche Nachricht-----
> Von: Daniel Huigens <d.huigens=[e-mail]>
> Gesendet: Dienstag, 13. August 2024 14:28
> An: Ehlen, Stephan <[e-mail]>
> Cc: [e-mail]
> Betreff: Re: [openpgp] Re: WG: BSI view on KEM combiners
> 
> Hi Stephan,
> 
> Thanks for the detailed response!
> 
> On Monday, August 12th, 2024 at 17:28, Ehlen, Stephan wrote:
> > I'm sorry, but it is not really possible to give a one-size-fits-all answer here.
> > It really depends on the use-case.
> 
> Alright, I'll try to make it more concrete :)
> Do you think the BSI would object to the use of ML-KEM-768 + X25519
> and/or ML-KEM-1024 + X448 in OpenPGP, as proposed by [1], with a
> key combiner as described in Section 4.2.2 of that document
> (or a variant of it that's compliant with SP800-56C)?
> Let's say the use case is encrypted email communications with the
> German government, for example.
> 
> In this case, X25519/X448 is there purely as a "fallback" in case
> ML-KEM turns out not to be secure. In other words, the combination is
> at least as secure as using ML-KEM by itself. (IMHO, this is what
> makes it a bit of a special case, e.g. it would be strange if using
> ML-KEM by itself would be considered BSI-recommended and/or -approved
> but ML-KEM + X25519/X448 isn't, IMO.)
> 
> Best,
> Daniel
> 
> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-04