Hi Markku,
Thanks for the thoughtful reply.
On 7/12/26 09:08, Markku-Juhani O. Saarinen wrote:
If something like this is added, I recommend using more precise
technical language and adding appropriate references to clarify key
concepts related to random bit generation. I also consider the
recommendation as unnecessarily weak from a security perspective.
Agreed. I should have used the NIST term "approved RBG", not
"randomness source". Thank you for the correction.
I also agree that the stronger and more general recommendation is to
require strong forward and backward secrecy for all random bits used in
TLS, not only ML-KEM's `m`.
I'd say this section is more or less compatible with what the "post-
Snowden" NIST standards already require.
Compatible, yes. Sufficient, no.
TLS deployments are not necessarily FIPS 140 modules, and the TLS draft
should not silently inherit FIPS 203's approved-RBG assumption without
saying so. We aren't discussing draft-ietf-tls-fips-certified-mlkem-08,
so I don't think we should treat this document as aiming for FIPS
certification.
The draft should say plainly that ML-KEM.KeyGen and ML-KEM.Encaps depend
on fresh randomness from an approved RBG, and that the `m` value is
recoverable by the decapsulating peer. Then it should say that this is
why we hash it because we don't need to agree with NIST's mistaken
decision. This is wire-interoperable with a FIPS-certified ML-KEM peer
that decapsulates normally. It may not itself be FIPS-conformant, which
is exactly why the IETF should not silently inherit NIST's choice.
The primary people who may notice are people wishing they could exploit
the backdoor and who are stopped by the hash. It will not stop everyone,
I am sure.
The full space of issues that an oracle-like primitive gives to an
Adversary is not really well explored in these discussions. I have been
focused on just one blatantly ironic one because it is simply too
much.
Regardless a single reason is reason enough to not provide that direct
oracle to whatever is backing it when ML-KEM is used in an IETF
protocol. We don't need or frankly, even desire, to be FIPS certified.
Since it is an American standard, one has to dive into NIST
terminology a bit to read FIPS 203 [...] FIPS 203 actually states
that an approved *RBG* must be used. An RBG and a randomness source
(a.k.a. an entropy source -- as defined in SP 800-90B https://
doi.org/10.6028/ NIST.SP.800-90B )> are different concepts.
Agreed.
For information about RBGs, see SP 800-90C: https://
doi.org/10.6028/ NIST.SP.800-90C
Agreed, and that reference should probably be included if the draft adds
text here that centers around NIST.
So in the world of FIPS cryptographic modules, the hash of shame
would always be hashing a SHA2 or AES-CTR output (with both forward
and backward secrecy). Indeed, if someone were to use non-compliant
random, additional steps may be required.
Yes. For a fully conformant FIPS module, the approved RBG requirement is
doing required, and important work. Consider the IETF/TLS ecosystem,
where the protocol document is used by many implementations that are not
FIPS validated modules. Do we want to inherit their implicit trust
decisions?
No, I think not.
That seems like an entirely different draft to me. NIST (rather than an
In-Q-Tel funded startup or various other defense contractors) could
publish an ISE stream draft rubber stamp of the NIST FIPS 203 spec where
it doesn't require consensus, for example.
Some confusion here seems to stem from the use of the term "RNG",
which is much more vague. I would avoid this term altogether.
Agreed. "RBG", "DRBG", "entropy source", and "random bit stream" are
better terms depending on the exact layer being discussed.
Just requiring the "hash of shame" (which is what we called it in
2023, in reference to NIST's Dual_EC_DRBG blunder) is like a gate
without a fence around it.
I don't agree. This is like hashing structure to destroy it, and it
isn't meant to solve every problem. It is meant to solve _that_ problem.
Regardless if we go with the analogy, a gate at the known opening is
still useful while the fence is being built unless we're now raising
lattice issues which remain a completely different point of discussion.
Restoring Kyber's `m <- H(m)` is not a complete RBG architecture, but it
does close this specific decapsulator-visible raw-randomness covert channel.
It's pretty crazy to me that NIST would even flirt with the idea, let
alone remove it over objections given the historical context. In the
best case, it's suspicious, but in the worst case being stonewalled by
NIST returns us to the history with Dual_EC_DRBG where again NSA made
clear that contractors and NIST were not allowed to speak freely. I
suppose you saw it but in the Don Johnson / John Kelsey email, Johnson
wrote that NSA "kyboshed" the alternative Q-generation idea and that he
"was not allowed to publicly discuss it" [0].
Please do forgive me if I think FIPS certification issues are probably
an anti-goal in a general draft simple because it relates to a FIPS
standardized cryptographic primitive.
I expect that many NIST people wouldn't be read into any such sabotage
anyway. If they tripped over it as we saw in [0], I would expect the
outcome would be the same. We can hope otherwise but I note NIST's
refusal to simply say "go ahead, hash it" while clarifying the IPR
concerns at the same time.
I think a more appropriate general recommendation is to require
strong forward and backward secrecy for *all* random bits used in
TLS, not just those in ML-KEM. If the threat model is the leakage of
an entropy source (or some upstream random bit stream), then one
should be consistent about blocking it everywhere.
I agree with that general recommendation but it's a security mistake to
not fix it in ML-KEM. Similarly it is a mistake to deploy ML-KEM without
a hybrid construction as the original designers of Kyber still list on
their website, and they still repeat this advice. The humility there is
admirable.
I do support also systematically addressing these kinds of issues for
TLS and for other IETF security protocols. The history of applying this
backdoor strategy through IPsec nonces comes to mind. That strategy was
being used by NSA to successfully attack many thousands of IPsec
sessions more than a decade ago.
For this draft, I suppose the minimal text could say:
ML-KEM.KeyGen and ML-KEM.Encaps require fresh randomness from a
NIST-approved RBG as specified by FIPS 203. The IETF does not require
a FIPS conformant implementation. The internal value `m` used by
ML-KEM.Encaps is recoverable by the decapsulating peer. It MUST be
hashed to prevent kleptographic sabotage such as NIST's standardized
backdoor Dual_EC_DRBG and other "SIGINT Enabling" strategies that can
be hidden in statistically random data. Implementations therefore MUST
not use raw primary random bit streams directly as `m`; they SHOULD
use a properly separated RBG/DRBG construction or a context-bound
derivation that provides forward and backward secrecy.
I would also strongly encourage relevant citations about the
unbelievable history. It is difficult for people to believe that these
issues are a real and relevant threat or that we live in a world with
large-scale adversaries. It should also reference various other IETF
drafts that are related.
That suggested text above does not solve the whole problem, but it makes
the relevant assumption explicit and gives implementers the right
direction. I'm not entirely sure that my above text is sufficient. I
would want to think about it very carefully in the full context.
Either way this draft but more importantly the hybrid draft should also
hash `m` to not delay deployment. If the X25519 keypair is generated
after `m` is released unhashed, it is _very_ bad news in this Adversary
model.
A hybrid post-quantum solution without this kind of covert channel is
badly needed. I am sure it will be a tiring road to find the right text
for everyone but it is not correct for the IETF to rubber stamp NIST's
mistake, and certainly not this mistake.
There clearly isn't consensus for this draft. I wouldn't be surprised if
we see another Last Call but I guess it depends on what the definition
of "is" is...
Kind regards,
Jacob Appelbaum
[0] 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]
