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

[Deirdre Connolly <[e-mail]>]

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

Choosing to do this is basically bulletproof, no matter what happens with
ML-KEM between now and the final FIPS 203. It is also bulletproof in case
anyone happens to copy this pattern for other KEMs without thinking more of
it.

> I still would like to see an analysis of whether the PK is always
available at decryption time.

NIST has just announced they will make storing/using keys as just a seed to
expand the whole keypair will be explicitly supported / described in the
final FIPS 203, allowing a 64byte key seed to be expanded to provide the PK
(in a much more secure way too) at Decaps() time. if CMS-Kyber wants to
explicitly recommend storing keys as seeds and expanding them into memory
only when needed to process the PK in Decaps() that's probably a nice
solution (and is apparently FIPS-compatible even now? It may require
looking up another FIPS document to confirm)

On Thu, Apr 11, 2024 at 6:03 PM Mike Ounsworth <[e-mail]>
wrote:

> > 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]>
> wrote:
>
>
>
> Looking again at CMS Kyber
> <https://urldefense.com/v3/__https:/www.ietf.org/id/draft-ietf-lamps-cms-kyber-03.html__;!!FJ-Y8qCqXTj2!ZlXBL5zdkVBiGN9kO1SGzVWESjCU-Qx4JhNBJbo6Rc_mqMsre90MkvNPbifOgYG0NQ5JvsFw6syNRc5LwlFfawt_J-kL$>,
> 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://urldefense.com/v3/__https:/eprint.iacr.org/2023/1933.pdf__;!!FJ-Y8qCqXTj2!ZlXBL5zdkVBiGN9kO1SGzVWESjCU-Qx4JhNBJbo6Rc_mqMsre90MkvNPbifOgYG0NQ5JvsFw6syNRc5LwlFfa-WRFsEg$> 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://urldefense.com/v3/__https:/nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf__;!!FJ-Y8qCqXTj2!ZlXBL5zdkVBiGN9kO1SGzVWESjCU-Qx4JhNBJbo6Rc_mqMsre90MkvNPbifOgYG0NQ5JvsFw6syNRc5LwlFfa6TeNnwB$>,
> is LEAK-BIND-K-PK and LEAK-BIND-K-CT at best
> <https://urldefense.com/v3/__https:/eprint.iacr.org/2024/523__;!!FJ-Y8qCqXTj2!ZlXBL5zdkVBiGN9kO1SGzVWESjCU-Qx4JhNBJbo6Rc_mqMsre90MkvNPbifOgYG0NQ5JvsFw6syNRc5LwlFfa2woeUJG$>.
> To safely use the shared secret output from ML-KEM without opening it up to
> re-encapsulation attacks
> <https://urldefense.com/v3/__https:/cryspen.com/post/pqxdh/__;!!FJ-Y8qCqXTj2!ZlXBL5zdkVBiGN9kO1SGzVWESjCU-Qx4JhNBJbo6Rc_mqMsre90MkvNPbifOgYG0NQ5JvsFw6syNRc5LwlFfa5CF-wTk$>,
> 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
>
>
>