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

[Hubert Kario <[e-mail]>]

On Friday, 12 April 2024 05:48:25 CEST, Watson Ladd wrote:
> On Thu, Apr 11, 2024 at 2:31 PM Russ Housley <[e-mail]> 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.

Sure, but the point is to allow for code reuse across protocols.
So, having a common higher level operation that's used verbatim
in CMS, JOSE, COSE, XMLenc, etc. is Good™. No need to have functionally
the same code in each and every implementation of the higher level formats.

>> Russ
>> 
>> 
>> On Apr 11, 2024, at 10:30 AM, Deirdre Connolly 
>> <[e-mail]> 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 ...
>
>
>

-- 
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic