[CFRG] Re: Latest version of draft-sfluhrer-cfrg-ml-kem-security-considerations

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

See SRF inline

________________________________
From: Sophie Schmieg <sschmieg=[e-mail]>
Sent: Thursday, November 20, 2025 6:25 PM
To: Scott Fluhrer (sfluhrer) <[e-mail]>
Cc: Marc Penninga <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [CFRG] Re: Latest version of draft-sfluhrer-cfrg-ml-kem-security-considerations

Hi Scott,

thanks for this doc, it looks really useful. A few questions to discuss, happy to make them into a pull request if we agree:

> One common misunderstanding of the term KEM is the expectation that
>   Bob freely chooses the shared secret, and encrypts that when sending
>   to Alice.  While there do exist KEMs where this is true, this is not
>   true for ML-KEM.

I think the question of whether Bob can choose the shared secret is at least partially a question of definition and API. While there are KEM constructions that allow for such a choice, by definition, a KEM would never export this ability to the caller. I don't know if this statement just adds confusion, given that mathematically, we wouldn't call a primitive that allows choosing the shared secret a KEM, but a PKE.

SRF: Well, a properly implemented KEM wouldn't allow the application to select the shared secret.  However, there may be a concern that a bogus version of the application and the crypto engine would select a shared secret that would be known to some equipment in the middle.  Now, there's a few reasons why this might not be a real concern; both that such an application could just export the shared secret over the wire (or just use guessable entropy, which would have the same effect), and also the draft is about ML-KEM, where this isn't an issue in the first place.  I did want to mention it, as I have heard about the general misunderstanding from several people.


> Notably, this means a
>   public key can be 'poisoned' such that a future adversary can recover
>   the private key even though it will appear correct in normal usage.


I don't think this attack is possible in ML-KEM, at least not without also changing the private key (otherwise the attacker could always just use the poisoned public key for encapsulation). The FO transform catches this type of problem and rejects, (especially since the true public key is hashed into the randomness), so a poisoned public key would not result in a successful encapsulation, and never leak private key bytes. A poisoned public key could allow an attacker to recover the encapsulator's random seed, but a MitM attack would have the same effect, and one property of the FO transform is that the decapsulating party always learns the entire state of the encapsulating party.

On the misbinding: One other result of Kemmy Schmidt is that ML-KEM does have very strong binding properties when using seeds or when using any other threat model than that of a malicious attacker, to the point that I would consider misbinding attacks almost as an issue that is unlikely to be a concern.

SRF: I am in total agreement about these misbinding attacks - if the adversay can control the private key, why do we assume we have any security at all?  If this draft were totally up to me (well, at the moment, it really is, but I hope it'll be up to the RG soon), I'd either get rid of this text or move it into the 'things you shouldn't worry about' section.  On the other hand, Deirdre Connolly feels strongly about this - I consider the current text as a political compromise.

Oh, and as far as seeds go, I'm assuming that the people that this is written for (protocol designers and implementors) have no control over the internals of how ML-KEM is implemented, and so I try to avoid talking about such things.

On Thu, Nov 20, 2025 at 7:56 AM Scott Fluhrer (sfluhrer) <sfluhrer=[e-mail]<mailto:[e-mail]>> wrote:
I'll update the doc with these suggested changes.

In the future, it would be helpful for me if people would just do pull requests ( https://github.com/sfluhrer/ml-kem-security-considerations )
________________________________
From: Marc Penninga <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, November 20, 2025 7:56 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [CFRG] Re: Latest version of draft-sfluhrer-cfrg-ml-kem-security-considerations

Hi,

I agree that having a document on the use of ML-KEM in protocols is valuable, and I think that the RG should adopt and publish this draft. The target audience that Scott outlined seems a good way to scope the document.

Given the target audience, I think the document doesn't need to go deeper into binding issues than it currently does.

While reading, I noted a few nits:

-   The second sentence of the Abstract ("This document discusses how to use ML-KEM and how to use it within protocols") contains "how to use" twice; I suggest "This document discusses how to use ML-KEM within protocols".

-   Introduction: the sentence "In ML-KEM is that randomness from both sides are used to contribute to the shared secret." should be "In ML-KEM, randomness from both sides contributes to the shared secret."

-   The eighth paragraph in section 4 ("The shared secret key for all three parameter sets ...") addresses usage, not security, and would fit better in the Introduction. Especially the remark that the shared secret key can be used directly as a symmetric key is valuable advice for the target audience and deserves a more prominent place in the document.

-   Wouldn't [ID.draft-ietf-hpke-pq](https://datatracker.ietf.org/doc/draft-ietf-hpke-pq/) be a better reference for the use of ML-KEM in HPKE than the expired and non-adopted [ID.draft-connolly-cfrg-hpke-mlkem]?


Marc Penninga

_______________________________________________
CFRG mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
CFRG mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


--

Sophie Schmieg | Information Security Engineer | ISE Crypto | [e-mail]<mailto:[e-mail]>