Hi John,
On 7/13/26 10:07, John Mattsson wrote:
> I don't think it was a mistake. I was initially very sceptical during
> the public PQC forum discussion, but I changed my mind for several
> reasons:
Your earlier skepticism was well founded, and I think it is worth
quoting what you wrote then [0]:
> I very strongly agree that one should never leak the RNG output. We
> know that signal intelligence agencies in the past have compromised
> RNG standards, tried to increase the amount of leaked information, and
> completely controlled crypto equipment manufacturers.
You also wrote:
> Having an extra hash seems like a small price to pay
and:
> My view:
> - I think the hash should definitely stay.
>
> - The NIST specification should explain why the hash is needed based
> on past attacks and also recommend mixing different sources of
> randomness together.
That was correct in 2023, and the facts that made it correct have not
changed. Are you now also against citing the history?
> 1. The removal was proposed by Markku based on implementation
> experience.
That explains how the proposal arose. It does not answer the security
issue: hidden structure in decapsulator-visible randomness.
Implementation experience matters, but it is not a security argument
that preserving raw Dual_EC_DRBG-shaped structure in `m` is safe. I did
not read Markku as trying to address that problem in ML-KEM. Remember:
we are not commenting on draft-ietf-tls-mlkemhashdrbg-08. We are
discussing ML-KEM in TLS.
The 2023 thread also cuts the other way. Markku described the original
Kyber `m <- H(m)` step as a "nop" from an interoperability and
functionality viewpoint, and said that non-FIPS stacks could remove it
"and no one will notice" [1]. That is exactly why restoring it is such a
clean mitigation for TLS: it does not change the wire format or
decapsulation behavior. It changes only whether the decapsulating peer
receives raw structured RNG-derived `m` or a hashed value.
Markku also reported speedups from removing the hash in a masked
prototype. That is useful implementation data. It is not an analysis
showing that preserving hidden algebraic structure in `m` is safe.
Another person in the same thread reported a tiny computational cost for
hashing. Since NIST doesn't _require_ a masked implementation, the lower
bound seems especially relevant.
> 2. Revealing randomness is very common in cryptographic protocols and
> algorithms, and this trend is increasing with the introduction of
> privacy and grease mechanisms.
Then we should be more careful, not less.
Even if a TLS implementation separates public random bits from private
random bits, ML-KEM still cuts across that boundary: the encapsulating
side chooses `m` from private randomness, and the decapsulating peer can
recover `m`. If that private RBG/DRBG has hidden structure, `m` can leak
state from the private side. That is the specific problem.
So yes, I support stronger guidance for all TLS random bits. But that
broader work does not remove the need to close this ML-KEM opening.
> 3. Deterministic hashing in general, or adding a protection mechanism
> only in ML-KEM, are not good solutions. It may even create a false
> sense of security.
I do not agree with the "false sense of security" framing.
NIST removed an actual defense-in-depth step. There is currently no
protection in `m` against this class of hidden-structure state-recovery
attack. Restoring the hash is not pretending to solve every RBG failure;
it is restoring a concrete protection that destroys the algebraic
structure needed for this attack class.
This is not about adding entropy. It is about preventing state recovery
from structured output. For a few hundred to perhaps a few thousand
cycles, that is a very reasonable trade.
It is also a mistake to suggest that I am not additionally supporting
systematic review of all IETF protocols for similar leaks. We know
large-scale adversaries decrypt large amounts of encrypted data. The
IETF considers pervasive monitoring an attack, and this is part of how
that attack can become practical. We have a duty to address each gap.
This draft is about the gap in ML-KEM, which unlike the broader TLS
randomness problem was created by a specific NIST change: removing a
hash that survived three rounds of the PQC process and that mitigated
this class of attack.
> Security designs should not assume that an attacker will behave in a
> particular way.
Agreed. They also should not preserve known exploitable structure when a
single hash destroys it.
> Restoring Kyber's original hashing step is not safer than using
> m = H(m, additional entropy). The construction m = H(m, additional
> entropy) provides protection against a significantly broader class of
> attacker-controlled RNGs, because it incorporates independent entropy
> that is not under the attacker's control.
If independent entropy is available and specified, maybe. What is your
concrete proposal for that additional entropy source? The same source
that Kyber hashed?
Regardless of the answer, that is not an argument against restoring the
original hash. It is an argument for doing at least that, and possibly
more. A stronger future construction should not be used to justify
leaving raw primary random bit streams as decapsulator-recoverable `m`
now.
Can we agree on the narrow model? If an active peer can use ML-KEM to
sample structured private RBG output from one side, and if that state is
then used for later TLS secrets without a strong reseed or unknown
additional input, that oracle can be combined with passive observation
to attack later TLS sessions. In hybrid cases it can also matter for
later classical key shares generated from the same long-running state.
That is bigger than "an ML-KEM issue" in isolation.
> John Kelsey (NIST)
> I think this is a much better and more informative reference:
>
https://csrc.nist.gov/csrc/media/projects/crypto-standards-development-process/documents/dualec_in_x982_and_sp800-90.pdf
>
> In addition to being out of scope for this list and this discussion, I
> do not think John Kelsey deserves personal attacks.
I strongly disagree with the suggestion that this was a personal attack.
My point was historical and institutional, not personal. The NIST-hosted
email says Don Johnson told John Kelsey that Q was "the public key for
some random private key", that NSA "kyboshed" an alternate generation
idea, and that he "was not allowed to publicly discuss it" [2].
That is exactly the relevant history: NIST-adjacent participants were
prevented from publicly discussing the generation of Dual_EC_DRBG's
parameters. Citing that history is not an attack on John Kelsey. In
fact, John Kelsey did a fairly convincing apology tour, and it is
precisely because I think he was earnest that I believe we must now hold
NIST to an especially high standard of clarity.
It is a reason to be cautious when NIST removes a cheap defense-in-depth
measure and then does not publicly answer reasonable questions about the
security consequences.
So my position remains firm on these points:
- keep this discussion on the TLS list for the TLS drafts;
- add that `m` is recoverable by the decapsulating peer;
- restore Kyber's `m <- H(m)` in draft-ietf-tls-ecdhe-mlkem and
draft-ietf-tls-mlkem at a minimum;
- include the historical context, because the historical context is why
this class of attack is not hypothetical.
- separately pursue stronger TLS/IETF guidance for all random bits;
If you doubt my technical analysis, I am happy to share source code to
reproduce it. Restoring the hash stops these attacks as they relate
directly to ML-KEM. Other TLS protocol fields also need review, but that
is not a reason to leave this one unfixed. And once again, it isn't
about entropy but hidden structure.
Kind regards,
Jacob
[0]
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/jILFbWOkAwAJ
[1]
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/MRa5O0CvAAAJ
[2]
https://csrc.nist.gov/CSRC/media/Projects/Crypto-Standards-Development-Process/documents/Email_Oct%2027%202004%20Don%20Johnson%20to%20John%20Kelsey.pdf
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
