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

On Fri, 12 Apr 2024 at 03:41, Deirdre Connolly <durumcrustulum@gmail.com>
wrote:

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

It would be advantageous if the cryptographic library for PQC KEMs could be
seamlessly integrated without the need to create a new mechanism within the
JOSE/COSE WGs to establish a binding of the encapsulation key and
ciphertext into the shared secret. I also see variations in the KDF usage:
for instance, the CMS specification utilizes KMAC, while the
draft-connolly-cfrg-hpke-mlkem proposes use of HKDF-Extract and
HKDF-Expand. We identified this challenge during our work on
https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-kem/
<https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-kem/>

-Tiru

>
> > 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 <Mike.Ounsworth@entrust.com>
> 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 <spasm-bounces@ietf.org> *On Behalf Of *Russ Housley
>> *Sent:* Thursday, April 11, 2024 4:31 PM
>> *To:* Deirdre Connolly <durumcrustulum@gmail.com>
>> *Cc:* LAMPS <spasm@ietf.org>
>> *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 <durumcrustulum@gmail.com>
>> 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
>>
>>
>>
> --
> Pqc mailing list
> Pqc@ietf.org
> https://www.ietf.org/mailman/listinfo/pqc
>