Re: [lamps] CMS Kyber: include PK and CT in the KDF?

[Russ Housley <[e-mail]>]

Deirdre:

There was a discussion of this a few months ago.  Inside ML-KEM, the public key is included in the KDF that computes the shared secret.  There was discussion ot addint a hash of the ciphertext to the KDF computation, but no one thought that should be done in cms-kemri since that would be an algorithm-specific detail at a algorithm agile layer.

If there is consensus to do so, the CMS kyber draft could address this in the algorithm-specific layer.

It is _very_ important to me that one ML-KEM labrary be able to support CMS, JOSE, COSE, and so on.  so, whateve happen in one WG needs to be aligned with others.

Russ


> On Apr 11, 2024, at 10:30 AM, Deirdre Connolly <[e-mail]> wrote:
> 
> Looking again at CMS Kyber <https://www.ietf.org/id/draft-ietf-lamps-cms-kyber-03.html>, it seems to not bind the encapsulation key or the KEM ciphertext anywhere in the CMS scheme or the KDF. To mitigate the less-than-ideal binding properties <https://eprint.iacr.org/2023/1933.pdf> of ML-KEM, I would consider including the encapsulation key and ciphertext along with the shared secret `ss` as input to the KDF. 
> 
> ML-KEM, as currently drafted as FIPS 203 IPD <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf>, is LEAK-BIND-K-PK and LEAK-BIND-K-CT at best <https://eprint.iacr.org/2024/523>. To safely use the shared secret output from ML-KEM without opening it up to re-encapsulation attacks <https://cryspen.com/post/pqxdh/>, including the PK and CT concatted with the `ss` as the preimage to the KDF is a secure and easy way to maximally bind the resulting KEK to the KEM public values. This construction is also a secure solution for any KEM with even the weakest of binding properties, so it would be a safe pattern for other KEMs:
> 
> - KEK = KDF(ss)
> + KEK = KDF(ss || ct || pk)
> 
> The ML-KEM standard may change between the current draft and the final one later this summer/year, but even if so, this change would be basically bulletproof either way in terms of security.
> 
> Cheers,
> Deirdre