Hi Rob,
On 7/15/26 04:46, Rob Sayre wrote:
On Tue, Jul 14, 2026 at 7:26 PM Jacob Appelbaum
<[email protected]> wrote:
But, yes, just hash it.
Does this mean that you support a note about restoring the Kyber
hash strategy, in addition to explicitly listing the hard
requirements such as the NIST-approved RBG and NIST-approved
entropy source?
Yes!
Glad to hear it. Thank you for confirming.
I can't see why you wouldn't do it.
Trust no one.
Exactly. The draft should describe this dispute honestly, not only
through NIST's later framing. If the IETF omits the key facts, it risks
looking like it helped obscure NIST's tradeoff rather than explaining it
to implementers. I would almost say that is no longer merely a risk.
Kyber's own specification was direct. In Encaps, Kyber hashed `m` with
the comment:
"Do not send output of system RNG." [1]
Prof. Dr. Peter Schwabe made the same point on pqc-forum: Kyber would be
used with many randomness sources, "not all FIPS certified", and the
hash was a cheap way not to leak the output of whatever RNG the system
used [2]. That is the designer-side framing: do not expose raw system
RNG output.
NIST later reframed this in FIPS 203 Appendix C.1 as a safeguard against
"flawed randomness generation processes", and removed it because ML-KEM
requires NIST-approved randomness generation [0]. I still think the
draft should quote the relevant parts of FIPS 203 Appendix C.1 directly,
not merely paraphrase them.
In the pqc-forum discussion, NIST acknowledged the non-FIPS deployment
gap:
"In the case of a standardized version of Kyber being deployed in a
non-FIPS-certified setting, it is possible than [sic] an attacker can
back-door the RBG to learn all future outputs." [3]
Quynh Dang, writing from NIST as a main author of FIPS 203, later put
the same point even more directly: NIST requires an approved RBG, and if
the system RBG is broken or attacker-controlled, "the security of the
whole system should be assumed to be broken anyway" [4].
That is the nuance. I am not claiming that ML-KEM's lattice problem is
backdoored. Quynh says "top level cryptographers know ML-KEM was not
back-doored" [4], and I am not disputing that statement in that sense.
The issue is different: NIST removed Kyber's defense against exposing
system RNG output, and NIST itself acknowledges that in non-FIPS
settings a backdoored or attacker-controlled RBG can break the whole
system. That is why I have called this a "backdoor accommodation" in my
2023 public comments to NIST that went unaddressed, not proof that the
lattice KEM itself is backdoored.
Does NIST's change prevent exposure of system RNG output? No. Does it
protect against the hidden-structure class of failures when the
approved-RBG assumption is not met, or if an approved RBG later turns
out to have hidden structure? No. It sounds very much like the
Dual_EC_DRBG-shaped failure mode to me.
The point is not that NIST banned non-FIPS deployments. They did not as
far as we can tell, even if the IPR situation is unclear. The point is
that NIST removed Kyber's protection while acknowledging that, outside a
FIPS-certified setting, this backdoored-RBG scenario is possible and
that the whole system should then be assumed broken. This TLS draft is
not limited to FIPS-certified deployments, so it must surface the
assumption. It is obvious that many people did not understand the nuance
of their statement. There is still more nuance to tease out, I suspect.
That is why a generic "use a good RNG" sentence is not enough. "Good"
obscures the intentional tradeoff NIST made. Real implementations may
use /dev/urandom, /dev/random, /dev/hwrng, getentropy(), getrandom(),
OS get-random-bytes APIs, hardware RNGs, or library wrappers. Some may
be excellent in well-designed systems. They are not automatically the
same as the FIPS 203 approved-RBG and entropy-source requirements.
I think the TLS text should say, compactly:
FIPS 203 requires ML-KEM.KeyGen and ML-KEM.Encaps to use fresh random
bytes from an approved RBG of appropriate security strength, including
the relevant SP 800-90 entropy-source and RBG requirements [0][10-12].
The CRYSTALS-Kyber specifications hashed the initial encapsulation
randomness `m` before use with the comment "Do not send output of
system RNG" [1]. FIPS 203 removed this step, stating that it was
unnecessary because ML-KEM requires NIST-approved randomness
generation [0]. NIST also acknowledged on the official NIST pqc-forum
used for ML-KEM's standardization process that, in a
non-FIPS-certified setting, a backdoored RBG can learn all future
outputs [3], and later stated that if the RBG is broken or
attacker-controlled, "the security of the whole system should be
assumed to be broken anyway" [4].
In TLS, `m` is recovered by the decapsulating peer as part of
computing the shared secret(s). Implementations that do not meet the
FIPS 203 approved-RBG requirements, or that want defense in depth
against hidden-structure RBG failures, MUST restore Kyber's strategy
by hashing `m` before encapsulation. Otherwise, they should expect
catastrophic failures in attacker-controlled or hidden-structure RBG
settings, including SIGINT-enabling failures of the kind exemplified
by Dual_EC_DRBG. Dual_EC_DRBG is the public standardized and now
withdrawn NIST example of hidden structure in random-generator output;
removing Kyber's hash leaves this class of structure unmitigated at
`m` [5][6].
That is not changing the TLS wire protocol. It is explaining the
assumption, the history, the NIST warning, and the conservative
implementer guidance for a draft that is not limited to FIPS-certified
deployments. If this draft is intended only for FIPS-certified settings,
it should say so.
There is also a separate transparency concern: CIA's In-Q-Tel support
for SandboxAQ is public, but not obvious from the draft context [7][8].
People paying close attention may know this; ordinary implementers
likely will not. The point is not guilt by association; people funded by
such a funder can still make good technical decisions in support of
IETF end-user protection goals. For every PROJECT BULLRUN participant,
we should hope there is also an NSA person like Brian Snow. Those may
very well be the people in this group. The point is that facts relevant
to trust, deployment, and incentives should be visible to everyone
reading the draft.
Do not obscure facts that matter.
Do not omit security-critical advice to implementers, especially when it
is a rare point of agreement between NIST and critics of some of NIST's
specific choices. It delays deployment, and it harms end users.
Explicit is better than implicit, as the Zen of Python says. It is good
standards work too. It is also a much better way to avoid later claims
that the IETF helped bury a known NIST tradeoff or helped enable
NSA and GCHQ surveillance through silence.
The IETF has a rational interest in spilling some ink to be proactively
be transparent about these deeply technical matters. What the IETF does
here will impact societies everywhere. TLS is that important. The cost
of adding text addressing these issues, along with the extra citation
urls, is not higher than the predicable damage that will be done to the
IETF by even appearing to enable NIST to weaken Kyber, in the very
specifically desribed manner, as NIST freely admits.
Kind regards,
Jacob Appelbaum
[0] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
[1] https://pq-crystals.org/kyber/data/kyber-specification-
round3-20210804.pdf
[2] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4
[3] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/
m/MRa5O0CvAAAJ
[4] https://mailarchive.ietf.org/arch/msg/tls/Yl6GkDF-DBAU_O8zavc1fG0VPpw/
[5] https://csrc.nist.gov/csrc/media/projects/crypto-standards-
development-process/documents/dualec_in_x982_and_sp800-90.pdf
[6] https://csrc.nist.gov/CSRC/media/Projects/Crypto-Standards-
Development-Process/documents/
Email_Oct%2027%202004%20Don%20Johnson%20to%20John%20Kelsey.pdf
[7] https://www.insidequantumtechnology.com/news-archive/sandbox-aq-
gets-backing-from-cias-venture-arm-in-q-tel/
[8] https://www.sandboxaq.com/post/welcome-iqt-paladin
[9] https://www.python.org/dev/peps/pep-0020/
[10] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90Ar1.pdf
[11] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90B.pdf
[12] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90C.pdf
[13] https://man7.org/linux/man-pages/man2/getrandom.2.html
[14] https://man.openbsd.org/getentropy.2
[15] https://man7.org/linux/man-pages/man4/random.4.html
[16] https://docs.kernel.org/admin-guide/hw_random.html
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
