Re: [lamps] [EXTERNAL] Does cms-kemri need to include H(ct) as a KDF input?

[Mike Ounsworth <[e-mail]>]

Good point Dan and Peter that KEM combiners need to include the ct's at the combiner level even if the component KEMs already do. I want to point out that that statement ought to apply to both composite KEMs, as well as to protocols that build an AKE out of two or three KEM exchanges as per RFC9180 AuthKEM or [kyber2021], but I do not aware of any KEM-based AKEs being specified within LAMPS -- 4210bis comes close when both the client and server have KEM certificates, but in fact we need to keep the two direction of KEMs isolated and non-interacting because CMP needs to allow for the ciphers used in the Client -> Server direction to be chosen indpendently from those used in the Server -> Client direction.

 

Having read this thread, I think I am convinced that we "might as well" include ct in the KDF, but I am personally somewhat undecided on whether it's better to do so at the kemri level or at the RSAKEM; DHKEM; ML-KEM level; but I think I'm leaning towards doing it in kemri.

 

Cons of doing it in RSAKEM; DHKEM; ML-KEM level: RSAKEM is about to pass WGLC, so we'd have to pull it back or do a 5990tris. Also, this would force a new layer of KDF, and a KDF param, in draft-ietf-lamps-cms-kyber that is otherwise not needed.

 

Cons of doing it in KEMRI: some handwavy-bordering-on-moot argument about duplicating rounds of KDFs if the underlying KEM already does it. However, given that DHKEM is not even adopted yet, we can change that, and I am not aware of any other KEM that does this, hance "handwavy-bordering-on-moot".

 

 

[kyber2021]: “CRYSTALS - Kyber: A CCA-Secure Module-Lattice-Based KEM”, Bos et al. 2021

 

---

Mike Ounsworth

 

From: John Gray <[e-mail]> 
Sent: Friday, December 8, 2023 9:42 AM
To: Daniel Van Geest <[e-mail]>; Carl Wallace <[e-mail]>
Cc: Deirdre Connolly <[e-mail]>; Mike Ounsworth <[e-mail]>; Russ Housley <[e-mail]>; LAMPS <[e-mail]>
Subject: RE: [lamps] [EXTERNAL] Does cms-kemri need to include H(ct) as a KDF input?

 

See Inline also

 

From: Daniel Van Geest <[e-mail] <mailto:[e-mail]> > 
Sent: Friday, December 8, 2023 8:12 AM
To: Carl Wallace <[e-mail] <mailto:[e-mail]> >
Cc: John Gray <[e-mail] <mailto:[e-mail]> >; Deirdre Connolly <[e-mail] <mailto:[e-mail]> >; Mike Ounsworth <[e-mail] <mailto:[e-mail]> >; Russ Housley <[e-mail] <mailto:[e-mail]> >; LAMPS <[e-mail] <mailto:[e-mail]> >
Subject: Re: [lamps] [EXTERNAL] Does cms-kemri need to include H(ct) as a KDF input?

 

Inline also. . . On Fri, Dec 8, 2023 at 11: 27 AM Carl Wallace <carl@ redhoundsoftware. com> wrote: Inline… From: Spasm <spasm-bounces@ ietf. org> on behalf of Daniel Van Geest <daniel. vangeest. ietf@ gmail. com> Date: Friday, December 



Inline also...

 

On Fri, Dec 8, 2023 at 11:27 AM Carl Wallace <[e-mail] <mailto:[e-mail]> > wrote:

Inline…

 

From: Spasm <[e-mail] <mailto:[e-mail]> > on behalf of Daniel Van Geest <[e-mail] <mailto:[e-mail]> >
Date: Friday, December 8, 2023 at 5:48 AM
To: 'John Gray' <[e-mail] <mailto:[e-mail]> >, 'Deirdre Connolly' <[e-mail] <mailto:[e-mail]> >, 'Mike Ounsworth' <[e-mail] <mailto:[e-mail]> >
Cc: 'Russ Housley' <[e-mail] <mailto:[e-mail]> >, 'LAMPS' <[e-mail] <mailto:[e-mail]> >
Subject: Re: [lamps] [EXTERNAL] Does cms-kemri need to include H(ct) as a KDF input?

 

I don’t think that “giving future drafts more to write” is a good reason for putting the ciphertext in one place or another.

[JG]  I didn’t mean to imply more things to write was a reason to put the CipherText anywhere else, I just mean the details of how it is used within CMS could be defined in that document, outside of cms-kemri.   For something like ML-KEM, a ukm structure that included the CipherText as a required piece of data (along with anything else that was needed), could be specified as part of a  its use of CMSORIforKEMOtherInfo.    

I think the only place it makes sense to add the ciphertext is to CMSORIforKEMOtherInfo. Other options are in UserKeyingMaterial but the ciphertext isn’t user material, or adding another KDF step for KEMs which want to mix in the ciphertext which doesn’t feel nice.

[JG]  Yes, I agree adding it into ukm may seem like a bit of a hack unless you are thinking of yourself as “an ML-KEM user”.  😊    Perhaps the main question for the group is the following:

1.	Do we need to have the CipherText as part of the input to the KDF for all types of KEMS (ML-KEM, RSA-KEM, EC_KEM, future-KEM)   

a.       If the answer is yes, then lets add it into the CMSORIForKEMotherInfo structure in the cms-kemri draft as required.

b.       If the answer is no, then we don’t add it.

c.       If the answer is sometimes, then we can add it as an optional item to the CMSORIforKEMOtherInfo.   Something like the following:

CMSORIforKEMOtherInfo ::= SEQUENCE {

          wrap KeyEncryptionAlgorithmIdentifier,

          kekLength INTEGER (1..65535),

          ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL,

                           kemct [1] EXPLICIT OCTET STRING OPTIONAL

}

When adding the ciphertext to the CMSORIforKEMOtherInfo ASN.1 structure it could be defined OPTIONAL or not. If not OPTIONAL, it wouldn’t be a per-KEM decision.  If OPTIONAL it could be a per-KEM decision.  My concern with making it a per-KEM decision is I don’t want algorithm-specific logic to make its way into general KEMRI code.  I haven’t implemented this draft yet (but I will), so I don’t know if per-algorithm logic would be a problem.  I suspect for OpenSSL it won’t because the providers interface includes CMS communication, but I don’t know how it would be for other implementations.

 [JG]  Good point.   I don’t think the per algorithm logic should be an issue, but I suppose anywhere there is an “if KEM x add that” statement could lead to implementation bugs…   I guess we could re-ask the question a different way:

1.       Would adding the kemct into CMSORIforKEMOtherInfo for all KEMs cause any issues?   

Essentially if it doesn’t hurt anything, then why not do it, other than it takes some extra computation time.  

[CW] If the thought is that ciphertext should always be incorporated, why is this not feedback to NIST? In the recent pre-hash discussion, the preference was to not push the detail into the protocol level and instead handle it “uniformly in a standardized way at the crypto level”. The ciphertext was incorporated in the round 3 Kyber draft then dropped in the IPD, so feedback may be appropriate. Why are additional CMS steps nicer than another KDF step for KEMs?

 

[DVG] The deadline for comments has passed but I see that there was one comment made recommending the restoration of the ciphertext commitment: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/n8dsN_aMsa8 <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/g/pqc-forum/c/n8dsN_aMsa8__;!!FJ-Y8qCqXTj2!cacphgaKgajO3u-_dnF-MXXxVC0zlwN37QtTxlE8jmqcwyeSv8ygSEKr9b_8DLQ5dRF4cK93XJbC2BrMkuMVmoj71Gbb$> 

Also discussions when it was originally removed: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/C0D3W1KoINY <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/g/pqc-forum/c/C0D3W1KoINY__;!!FJ-Y8qCqXTj2!cacphgaKgajO3u-_dnF-MXXxVC0zlwN37QtTxlE8jmqcwyeSv8ygSEKr9b_8DLQ5dRF4cK93XJbC2BrMkuMVmq92Hvef$>  and https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4 <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4__;!!FJ-Y8qCqXTj2!cacphgaKgajO3u-_dnF-MXXxVC0zlwN37QtTxlE8jmqcwyeSv8ygSEKr9b_8DLQ5dRF4cK93XJbC2BrMkuMVmu9TLzIB$>  with agreement that it should be removed.

 

I'm not a cryptographer so I can't argue whether the ciphertext should be included at the KEM level or the protocol level, I just have Deirdre's "'robustness', session independence and 'contributory behavior'".  Perhaps for session independence (the only formally defined of the terms), ciphertext commitment wouldn't be necessary when the KEM is used ephemerally but in CMS the keypair is reused.

 

BTW, unrelated to CMS but related to ciphertext commitment I've read a statement that including the ciphertext in the KEM shared secret derivation would mean that we don't need to include the ciphertext in the KEM combiners. That's not true, in the combiners all but one of the KEMs may be arbitrarily broken (e.g. two ciphertexts decapsulate to the same shared secret) so in  order to preserve IND-CCA security the combiner needs to include the ciphertext regardless of what the underlying KEMs do.

 

[JG]  One thing that is nagging the back of my brain is that not all CipherTexts can be used to derive the shared secret (like RSA-KEM) because the cipherText is an encapsulation of the shared secret!  I had to look at the details of ML-KEM to see that yes, they are independent of each other for ML- KEM.  So for many KEM’s this can’t be an issue because it just wouldn’t work.   However, the way we are describing its use here for cms-kemri would always work because we aren’t using the kemct to derive a shared-secret, we are using it to derive the KEK.    

 

Thanks,

Daniel Van Geest

 

 

From: John Gray <[e-mail] <mailto:[e-mail]> > 
Sent: Thursday, December 7, 2023 6:58 PM
To: [e-mail] <mailto:[e-mail]> ; 'Deirdre Connolly' <[e-mail] <mailto:[e-mail]> >; Mike Ounsworth <[e-mail] <mailto:[e-mail]> >
Cc: 'Russ Housley' <[e-mail] <mailto:[e-mail]> >; 'LAMPS' <[e-mail] <mailto:[e-mail]> >
Subject: RE: [lamps] [EXTERNAL] Does cms-kemri need to include H(ct) as a KDF input?

 

I agree, the public key might not be “easily” available at the recipient side, which would require the recipient to fetch it in some way.  The cipherText is available for both the originator and recipient, so it could easily be an input to the KDF.   This has come up because ML-KEM.Encaps no longer includes a hash of the ciphertext in
the derivation of the shared secret.   In KEMRecipientInfo, the shared-secret produced by the underlying KEM algorithm (ML-KEM) for example, is used as an input to the KDF used to derive the Key Encryption Key (the key used to encrypt the bulk content encryption key).  So it is used in a similar way (if you think of the KEK as a kind of shared-secret).  So I can see why it seems like a good idea.

 

I think the specific details of how you SHOULD OR MUST use kemct, as an input to the KDF for ML-KEM, can be specified in (https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamps-kyber/__;!!FJ-Y8qCqXTj2!cacphgaKgajO3u-_dnF-MXXxVC0zlwN37QtTxlE8jmqcwyeSv8ygSEKr9b_8DLQ5dRF4cK93XJbC2BrMkuMVmmzym001$> ).  That would make having future drafts that add KEM algorithms to CMS more than just a list of OIDs and a statement saying it can be used in CMS.  The other reason for doing it this way is that perhaps future KEM’s might not need to use the cipherText in this way.   

 

 

Cheers,

 

John Gray

 

 

From: Spasm <[e-mail] <mailto:[e-mail]> > On Behalf Of [e-mail] <mailto:[e-mail]> 
Sent: Wednesday, December 6, 2023 7:08 PM
To: 'Deirdre Connolly' <[e-mail] <mailto:[e-mail]> >; Mike Ounsworth <[e-mail] <mailto:[e-mail]> >
Cc: 'Russ Housley' <[e-mail] <mailto:[e-mail]> >; 'LAMPS' <[e-mail] <mailto:[e-mail]> >
Subject: Re: [lamps] [EXTERNAL] Does cms-kemri need to include H(ct) as a KDF input?

 

Deirdre, I don’t think I understand the attack where the public key is not mixed into the KDF. Would it still apply if the ciphertext is mixed in? Needing to mix in the public key might cause some issues. Does the recipient have their own public 

 

Deirdre,

 

I don’t think I understand the attack where the public key is not mixed into the KDF. Would it still apply if the ciphertext is mixed in?

 

Needing to mix in the public key might cause some issues.  Does the recipient have their own public key (in the same place that they do the KDF, i.e. not off on an HSM somewhere)?  Is it encoded in the same way that the sender’s copy of the public key is? If we can’t assume that, does the sender include a copy of the public key in KEMRecipientInfo (yuck)?  If so, does the receiver need to verify that the public key in CMSORIforKEMOtherInfo corresponds to their private key? Probably, otherwise the sender could send whatever they want, defeating the purpose of sending the public key.

 

I agree that the ciphertext should be mixed into the KDF. While we’re at it, should anything else be mixed in for similar ‘robustness’ reasons? (RecipientIdentifier? KEMAlgorithmIdentifier? CMSVersion?!)

 

Daniel Van Geest

 

 

From: Spasm <[e-mail] <mailto:[e-mail]> > On Behalf Of Deirdre Connolly
Sent: Thursday, November 30, 2023 11:40 PM
To: Mike Ounsworth <[e-mail] <mailto:[e-mail]> >
Cc: Russ Housley <[e-mail] <mailto:[e-mail]> >; LAMPS <[e-mail] <mailto:[e-mail]> >
Subject: Re: [lamps] [EXTERNAL] Does cms-kemri need to include H(ct) as a KDF input?

 

I am not well-versed in CMS but looking at https://www.ietf.org/archive/id/draft-ietf-lamps-cms-kemri-06.html <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lamps-cms-kemri-06.html__;!!FJ-Y8qCqXTj2!aN-NXsCExIdlniTxBhGmS3I0gRF8wqAI7-LSEeIj26pziq8q8VYGqkehqX5mtxiSs_TmeI6v0Vt8b7v7ZHplt5Fl_7T4-Cbjjg$>  my concerns are:



Is this supposed to be `ss` from `KEM.Encaps(pk) -> ss, ct` ? I do not see the encrypted ss ciphertext `ct` being explicitly fed in the key-encryption key KDF, _nor_ the KEM public key. _Kyber/ML-KEM_ mixes in the public key, but a generic KEM does not make any guarantees on this, as IND-CCA security does not rely on this. Since cms-kemri does not specify Kyber or ML-KEM, but a generic KEM, I would rather see the public key mixed into the KDF input. This way, if a prior KEM pubkey pair is compromised, and a malicious ciphertext handed over, and successfully decrypts to a `ss` (as allowed under IND-CCA), which, if nothing else is mixed into the KDF, means this particular key-encryption key is the same across sessions, and doesn't violate the security guarantees of the KEM.  

 

As to the ciphertext, I generally think it should be mixed into the KDF of any protocol like this that has public information being passed back and forth, for 'robustness', session independence, and 'contributory behavior' (these terms are quoted because the first and third do not have robust formal definitions in the literature even though the lack of these properties seems to correlate with protocol vulnerabilities discovered via symbolic analysis.) To make a more concrete argument, all security analysis of hybrid, composite, or other KEM combinations models the _whole_ KEM, including the ciphertext resulting from KEM.Encaps(pk) -> (ss, ct), in their proofs of security. Under IND-CCA of the KEM, the adversary is allowed to feed whatever ciphertexts they like to KEM.Decaps(pk, ct), including ones that may decrypt to the same `ss` as another session (not likely to happen with honest correct implementations etc etc but this is where the formal proofs show a gap.) Not committing to the ciphertexts along with the public key and `ss` as part of the KDF can further impair session independence / uniqueness of the key-encryption keys.

If you can afford it (computationally, and in terms of document / IETF bureaucracy) I would just do it. If I have misunderstood the draft and how the pieces fit together, my apologies (if I have, maybe that indicates some clarifications could help?) 

In general, all the guidance on KEMs (not just the PQ ones) emphasize that the only security guarantees they are aiming for are IND-CCA2 security, and that Kyber/ML-KEM is an outlier in commiting to the public key at all (some other PQC finalist KEMs commit to the ciphertext in computing the shared secret, but not the public key), and so any designs that specify just a KEM must take care to keep that in mind.

 

On Tue, Nov 28, 2023 at 10:42 AM Mike Ounsworth <[e-mail] <mailto:[e-mail]> > wrote:

Thanks for starting this thread Russ!

 

 <mailto:[e-mail]> @Deirdre Connolly would you be willing to put into writing the attack that you described to me at 118 that necessitates putting the CT into the key derivation?

 

My very hazy understanding is that we are not aware of a practical attack today, but we are concerned that Falko will find one in two years 😉

 

---

Mike Ounsworth

 

From: Spasm <[e-mail] <mailto:[e-mail]> > On Behalf Of Russ Housley
Sent: Tuesday, November 28, 2023 9:35 AM
To: LAMPS <[e-mail] <mailto:[e-mail]> >
Subject: [EXTERNAL] [lamps] Does cms-kemri need to include H(ct) as a KDF input?

 

This topic has also been raised on the CFRG mail list in a more general way. Here, we need to discuss the impact to cms-kemri. FIPS 203-IPD says: The ML-KEM. Encaps and ML-KEM. Decaps algorithms in this specifcation use a dif- ferent variant 

This topic has also been raised on the CFRG mail list in a more general way.  Here, we need to discuss the impact to cms-kemri.

 

FIPS 203-IPD says:


   The ML-KEM.Encaps and ML-KEM.Decaps algorithms in this specifcation use a dif-
   ferent variant of the Fujisaki-Okamoto transform (see [5 , 6]) than the third-round specif-
   cation [ 4 ]. Specifcally, ML-KEM.Encaps no longer includes a hash of the ciphertext in
   the derivation of the shared secret, and ML-KEM.Decaps has been adjusted to match this
   change.

 

My understanding is that dropping the H(ct) from ML-KEM provides a cleaner proof.

 

By including H(ct) as an input to the KDF, an attacker will cause the originator and recipient to derive different keys if the ct value is modified. 

 

The IESG has sent cms-kemri back to the working group to determine what, if anything, needs to change as a result of this change to ML-KEM.

 

Russ

 

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. 

_______________________________________________ Spasm mailing list [e-mail] <mailto:[e-mail]>  https://www.ietf.org/mailman/listinfo/spasm <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!cacphgaKgajO3u-_dnF-MXXxVC0zlwN37QtTxlE8jmqcwyeSv8ygSEKr9b_8DLQ5dRF4cK93XJbC2BrMkuMVmgHbcWuu$>