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

On Thu, Apr 11, 2024 at 2:31 PM Russ Housley <housley@vigilsec.com> wrote:
>
> 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.

Huh? CMS and TLS handle ECDH very differently today.
>
> 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.

That library exposes Ecapsulate, Decapsulate, and Kegen functions. It
will function just fine even if a protocol layers a combiner on top.
>
> Russ
>
>
> On Apr 11, 2024, at 10:30 AM, Deirdre Connolly <durumcrustulum@gmail.com> wrote:
>
> Looking again at CMS Kyber, 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 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, is LEAK-BIND-K-PK and LEAK-BIND-K-CT at best. To safely use the shared secret output from ML-KEM without opening it up to re-encapsulation attacks, 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
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


-- 
Astra mortemque praestare gradatim