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

[Mike Ounsworth <[e-mail]>]

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

 

Agreed, hence cross-posting to PQUIP.

 

 

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

 

+1 to this suggestion.

We're on a deadline to get these RFCs out in short order after FIPS 203, and
have to act on what we know now. Given the analysis at this point, it seems
prudent to bind the PK and CT, and it seems like draft-cms-kyber (and
equivalents in other protocol WGs) is the right place to do it.

 

I still would like to see an analysis of whether the PK is always available
at decryption time. I would like to hear from smartcard, HSM, IoT, TPM type
people about whether it's fair to assume that the CMS / JOSE / COSE / etc
layer of a decryption routine will have access to the public key at
decryption time, or whether that will force some folks into awkward
re-architecturing exercises. For example, if someone has a TPM architecture
where only the wrapped private key is stored locally (cause why would you
ever need to encrypt for yourself?), then I could see that being an annoying
architecture change to also keep the public key. On the other hand, ML-KEM
is greenfield, so maybe it's ok to say "When ML-KEM; your private key object
MUST contain the public key".

I'm asking whether there's an engineering architecture concern here that
overshadows the security gain. Maybe I'll stop rambling here.

 

---

Mike Ounsworth

 

From: Spasm <[e-mail]> On Behalf Of Russ Housley
Sent: Thursday, April 11, 2024 4:31 PM
To: Deirdre Connolly <[e-mail]>
Cc: LAMPS <[e-mail]>
Subject: [EXTERNAL] Re: [lamps] CMS Kyber: include PK and CT in the KDF?

 

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 



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]
<mailto:[e-mail]> > wrote:

 

Looking again at
<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-ietf-lamps-cms-kyb
er-03.html__;!!FJ-Y8qCqXTj2!ZlXBL5zdkVBiGN9kO1SGzVWESjCU-Qx4JhNBJbo6Rc_mqMsr
e90MkvNPbifOgYG0NQ5JvsFw6syNRc5LwlFfawt_J-kL$> 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
<https://urldefense.com/v3/__https:/eprint.iacr.org/2023/1933.pdf__;!!FJ-Y8q
CqXTj2!ZlXBL5zdkVBiGN9kO1SGzVWESjCU-Qx4JhNBJbo6Rc_mqMsre90MkvNPbifOgYG0NQ5Jv
sFw6syNRc5LwlFfa-WRFsEg$> 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
<https://urldefense.com/v3/__https:/nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS
.203.ipd.pdf__;!!FJ-Y8qCqXTj2!ZlXBL5zdkVBiGN9kO1SGzVWESjCU-Qx4JhNBJbo6Rc_mqM
sre90MkvNPbifOgYG0NQ5JvsFw6syNRc5LwlFfa6TeNnwB$> FIPS 203 IPD, is
<https://urldefense.com/v3/__https:/eprint.iacr.org/2024/523__;!!FJ-Y8qCqXTj
2!ZlXBL5zdkVBiGN9kO1SGzVWESjCU-Qx4JhNBJbo6Rc_mqMsre90MkvNPbifOgYG0NQ5JvsFw6s
yNRc5LwlFfa2woeUJG$> 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 r
<https://urldefense.com/v3/__https:/cryspen.com/post/pqxdh/__;!!FJ-Y8qCqXTj2
!ZlXBL5zdkVBiGN9kO1SGzVWESjCU-Qx4JhNBJbo6Rc_mqMsre90MkvNPbifOgYG0NQ5JvsFw6sy
NRc5LwlFfa5CF-wTk$> e-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