[CFRG] Comments on draft-sfluhrer-cfrg-ml-kem-security-considerations-01

[Rebecca Guthrie <[e-mail]>]

Thank you to the authors for writing this draft- I read through it and have some comments- more substantive comments listed first, followed by comments that lean editorial.

1 Introduction

Paragraph 3

Suggest including this paragraph in Section 4 on ML-KEM Security Considerations instead of here in the introduction. None of the readability of the introduction would be lost if this paragraph does not appear here, and a lot of the paragraph might not be understood by the reader yet if it is kept in its current place. For example, ML-KEM.Decaps has not yet been defined, and Alice and Bob have not yet been introduced w.r.t their roles in ML-KEM.

P4, P5

It would be helpful to the reader if this portion of the document began with a definition or explanation of what a KEM is (it is a type of key establishment like DH or RSA, encapsulation means this, here are the three components (KeyGen, Encaps, Decaps) of a KEM), before comparing KEMs/ML-KEM to other key establishment mechanisms. Doing this will also help the reader better understand the comparison- for example, Alice, Bob, and ciphertext are mentioned, but the reader has not yet been introduced to Alice and Bob (whether or not P3 is included here; Alice and Bob are mentioned there but their roles w.r.t. ML-KEM or KEMs have not yet been defined), and does not know what the ciphertext is.

When comparing the structure and behavior of KEMs/ML-KEM to other key establishment mechanisms, it could be helpful to the reader to be more explicit in which properties/behaviors are true for all KEMs, and which are true for ML-KEM specifically (for example, ML-KEM's not allowing Bob to choose to use the same shared secret with multiple parties).

A minor note for clarity here is that P4 also says "ML-KEM internally generates the shared secret in a way that Bob cannot select the value," and also "This is different from RSA-KEM... where Bob cannot select the value..." The end of this latter sentence does in fact contrast with ML-KEM, but the first part doesn't, and the phrasing implies that this first part is contrasting as well.

In P5, suggest reordering some of the explanation in the first couple of sentences. Instead of contrasting DH and KEM in the second sentence, consider explaining how DH parties exchanging two public keys means that DH is "asynchronous" and "non-interactive." In sentence three, explain why KEM ciphertext being a function of Alice's public key means that it is neither of these.

The paragraph could also do with a bit more detailed of an explanation as to why a KEM is a drop-in replacement for static-ephemeral but not ephemeral-static.

I think enough information is presented in P4 and P5 that it could be broken off into its own section or subsection- I'm not sure it fits the "introduction" label at this point. Suggest adding either here or in the beginning of section 2 a diagram between Alice and Bob that shows how they use ML-KEM.KeyGen(), ML-KEM.Encaps(), and ML-KEM.Decaps() (and which pieces of data they send to one another).

2.1 ML-KEM Key Generation

"The first step for Alice is to generate a public and private keypair." -> "The first step of ML-KEM is for Alice to generate a keypair consisting of a public and private key."
Rephrase to make clear that this is the first step of ML-KEM (both Alice and Bob) and not just the first step for Alice. Also suggest rewording end of sentence- "public and private keypair" makes it sound like there are two keypairs, one public, and one private.

2.2 ML-KEM Encapsulation

"matrix data"
This should probably be defined/explained or at least provide a pointer to a reference that defines it.

2.3 ML-KEM Decapsulation

"It also repeats the encapsulation process to ensure that the ciphertext was created strictly according to the specification, implicitly rejecting ciphertexts that were not."
Suggest including a brief explanation of *how* repeating the encapsulation function has this effect. What is the result if the ciphertext is good vs. if it is bad?

"...insecure probability..."
What does this mean?

2.4 ML-KEM Parameter Sets

Perhaps in this section it would also be good to mention terms security level, Level 1, Level 3, and Level 5? (FIPS 203 doesn't mention levels 1/3/5 but these terms are used in practice quite often, and FIPS 203 does use the term security level, so mentioning/defining all of these could be useful.

3 KEM Security Considerations

This is a little pedantic, but this section discusses Alice and Bob for a general KEM when section 2 only introduced Alice and Bob's role in ML-KEM. Introducing Alice and Bob in the intro P4/P5 would fix this.

"It is recommended that she zeroize her private key when she will have no further need of it."
Can the draft specify or give guidance on when this might be in the context of a communications protocol? (after she and Bob use the shared secret to successfully establish a shared connection, after the connection is closed, some other time?)

"...protocol exchange transcript..."
I am only familiar with "transcript" being used in the context of TLS. Do other protocols use it as well, should this be framed as an example for TLS, or should a more general term be used instead?

4 ML-KEM Security Considerations

"It is recommended that she zeroizes her private key when she will have no further need of it."
If this is already stated for KEMs in general, isn't it implied that it would be true for any KEM in particular, including ML-KEM? Suggest that KEM security considerations are not restated for ML-KEM; if they were comprehensively restated, the KEM section would just be a proper subset of the ML-KEM section.

"...(and zeroize the private key immediately after)..."
Alice needs to wait until after she performs ML-KEM.Decaps() at least to zeroize the private key. Also, make sure however this is stated aligns with mention of zeroization earlier in this section, and in section 3 ("when she will have no further need of it").

"It is essential that..."
This paragraph should be moved earlier in the section to when key generation is discussed.
--------------------

1 Introduction

P1

"A large reliable quantum computer (often termed a Cryptographically Relevant Quantum Computer or CRQC) would be able to break..." -> "A Cryptographically Relevant Quantum Computer (CRQC) is a large and reliable quantum computer that can break..."

"Even though... read the traffic." -> "Though it is believed that a CRQC does not exist at the time of publication of this document, an adversary today can intercept and store a protocol exchange that is protected by a quantum-vulnerable encryption algorithm, and later, when they have access to a CRQC, decrypt and read the traffic."
Attempt to remove "we"; rephrase to remove "possibility" of attack (may make attack appear unlikely or theoretical)

P2

"Because of this potential threat," -> "Because of this threat,"

"NIST has standardized... which is standardized..." -> "NIST has published FIPS 203, which standardizes a quantum resistant Module-Lattice-Based Key Encapsulation Mechanism called ML-KEM."
Rephrase to only say "standardize" once; suggestion to include "quantum resistant" (or something to that effect) in this sentence so the reader understands the connection between this paragraph and the previous one.

"NIST plans to standardize one or more code-based KEMs in the future."
This is probably not relevant to state here, since the document is about ML-KEM in particular and not NIST KEMs in general. Readers also might not know what is meant by "code-based" without an explanation. Suggest removing.

P3

"The fundamental security property is..." -> "The fundamental security property of ML-KEM is..."

"...the shared secret key and this is true..." -> "...the shared secret key, and this is true..."

"...secure, that is, ..." -> "...secure; that is, ..."

"...submit arbitrary ciphertexts and observe..." -> "...submit arbitrary ciphertexts using a fixed public key and observe..."

P4, P5

"As long a the application..." -> "As long as the application..."

The last sentence of P5 repeats what is stated in P4.

2 Using ML-KEM

"...there are three steps involved" -> "...there are three steps involved."

2.1 ML-KEM Key Generation

"In FIPS 203, this function is..." -> "In FIPS 203, the key generation function is..."

"...public key (termed an..." -> "...public key (known as an..."

"...private key (termed a..." -> "...private key, or a..."

"The seed can be securely retained..." -> "The seed can be securely stored..."

"...data ust..." -> "...data must..."

2.2 ML-KEM Encapsulation

"...perform the what FIPS 203 terms as ML-KEM.Encaps()..." -> "...perform ML-KEM's encapsulation algorithm, called ML-KEM.Encaps()..."
Note that there is an unnecessary "the" after "perform" regardless of if the other proposed change is made

"... you should check whether the library you are using does." -> "...implementations should determine whether the library they use combine these steps."
Remove use of "you" in "you should check"

2.3 ML-KEM Decapsulation

"...perform the what FIPS 203 terms as ML-KEM.Decaps()..." -> "...perform ML-KEM's decapsulation algorithm, called ML-KEM.Decaps()..."
Same suggestion here- unneeded "the" after "perform", and also explicitly state in the body (not just header) that Decaps is decapsulation.

"Although not necessary... this step should not..." -> "Although this step is not necessary... it should not..."

"...as maliciously generated ciphertexts could induce decapsulation failures..." -> "...as a maliciously generated ciphertext could induce a decapsulation failure..."

"...whichcan..." -> "...which can..."

"... you should check whether the library you are using does." -> "implementations should determine whether the library they use combine these steps."

2.4 ML-KEM Parameter Sets

"ML-KEM comes with three parameter sets..." -> "[FIPS 203] specifies three parameter sets for ML-KEM..."

"...which parameter sets they use..." -> "...which parameter set they use..."

"Table 1 shows a summary of how those parameter sets differ:" -> "Table 1 shows the size of the cryptographic material of ML-KEM for each parameter set:"
Suggest not necessarily this exact phrasing, but something explicitly naming that the table looks at the size/length of things in each parameter set. Also suggest removing summary because a summary would be an abbreviated version of the info in the table.

"Table 2 shows an example of ML-KEM performance [EBACS]:" -> "Table 2 shows an example of ML-KEM performance at each parameter set:"
Suggest including mention of parameter set. Also suggest moving [EBACS] reference into Table description ("Table 2: Single-core performance in operation per second on AMD Ryzen 7 7700 from [EBACS]")

"Table 1 and Table 1" -> "Table 1 and Table 2"

3 KEM Security Considerations

"...including ML-KEM" -> "...including ML-KEM."

"To use a KEM, you need to use a high-quality source..." -> "KEMs require the use of a high-quality source..."

"...key-pair..." -> "...keypair..."
For consistency

"...lets Bob be able to verify that the public key he obtains came from Alice and that the ciphertext Alice receives came from Bob (that is, an entity that Alice is willing to communicate with)." -> "...lets Bob verify that the public key he obtains came from Alice, and lets Alice verify that the ciphertext she receives came from Bob."
Make clearer that Alice and not Bob is verifying the latter part. No need to include parenthetical at this point, since Bob has already been introduced.

4 ML-KEM Security Considerations

"To use ML-KEM, you need a source of random bits with security strength equal to greater than the security strength of the KEM during both key generation and encapsulation steps." -> "ML-KEM requires that a source of random bits with security strength equal to or greater than the security strength of ML-KEM be used when generating the keypair and ciphertext during ML-KEM.KeyGen() and ML-KEM.Encaps() respectively."

"...ML-KEM.Decaps..." -> "...ML-KEM.Decaps()..."
For consistency

"...if the protocol allows it (if Alice and Bob exchange messages anyways) that Alice generates a fresh keypair..." -> "... if the protocol already includes Alice sending Bob her public key, she should generate a fresh keypair..."

"Be noted that generally key generation of ML-KEM is very fast, see Table 2. That is, ..."
The "That is" sounds like it is elaborating not on the sentence beginning with "Be noted" but with the earlier sentence that mentions PFS. Suggest cutting this sentence or moving it after the sentence beginning with "That is,..." If moved and not cut, two suggestions:
"Be noted..." -> "Note..."
"..., see Table 2." -> "...(see Table 2)."

"...cryptographical..." -> "...cryptographic..."

"...if so, that should be verified." -> "...they should each verify whether this is the case."

"The shared secret key... are 32 bytes..." -> "The shared secret key... is 32 bytes..."

"As such, it is suitable both to use directly as..." -> "As such, the 32-byte string is suitable for use both directly as..."
I am not certain that "it" is the 32-byte string, but if so, suggest the above change.

"...and for inserting into..." -> "...and as input into..."

Rebecca

Rebecca Guthrie
she/her
Center for Cybersecurity Standards (CCSS)
Cybersecurity Collaboration Center (CCC)
National Security Agency (NSA)