On Sat, Jul 11, 2026 at 11:14 PM Jacob Appelbaum <[email protected]> wrote: > I would suggest something along these lines:
Hi Jacob, 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. I'd say this section is more or less compatible with what the "post-Snowden" NIST standards already require. > FIPS 203 requires that ML-KEM.KeyGen and ML-KEM.Encaps use fresh > randomness generated by a NIST-approved randomness source. Since it is an American standard, one has to dive into NIST terminology a bit to read FIPS 203 (recall that FIPS specs are primarily written for implementors of FIPS cryptographic modules, even though others use them as well.) 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. The standards are very clear that a randomness/entropy source alone is not an RBG. Basically, in the FIPS world, a randomness source is a necessary component of an RBG, but additional conditioning and processing steps are required to build an approved RBG out of it. (Well, in RBG1 is a special case where the randomness source can be a separate module.) For information about RBGs, see SP 800-90C: https://doi.org/10.6028/NIST.SP.800-90C 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. > Implementations should not use raw primary RNG output directly as > the ML-KEM `m` value, because that value is recoverable by the > Decapsulating peer. Some confusion here seems to stem from the use of the term "RNG", which is much more vague. I would avoid this term altogether. It is true that the "RNG" term is used in European Common Criteria (AIS 20/31) schemes; there a relevant protection profile should require a DRG (deterministic generator) with strong backward secrecy and forward secrecy (DRG.2, DRG.3, DRG.4). But perhaps CC assurance terminology would be going a bit too far for an IETF spec. > Implementations should use a properly separated > RBG/DRBG and/or a context-bound derivation for ML-KEM encapsulation > randomness, and as the original design of Kyber did `m <- H(m)`, > the `m` value should be hashed by a suitable secure cryptographic > hash function. This is a defense-in-depth measure against > hidden-structure RNG failures, including Dual_EC_DRBG-shaped > kleptographic attacks. 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 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. Chers, -markku
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
