Hi! ~~~~Disclaimer I'm not a cryptographer. ~~~~
Please see below. On 08.07.2026 08:04, Viktor Dukhovni wrote:
On Tue, Jul 07, 2026 at 10:27:56PM -0700, Christian Huitema wrote:I just read Jacob Applebaum's message. Given his description of the late-standardization suspicious change that looks like a backdoor in the ML-KEM specification, I agree with his conclusion. The WG should not ask for publication of the current graph, not until the changes requested by Jacob are made.The removal of whitening of the `m` random input to Encaps is not a plausible backdoor. If all you have is a broken RNG, you're free to apply whitening to obtain a new less bad RNG and use that instead. Nothing stops an ML-KEM implementation from hashing some input (any number of times, mixing in whatever additional inputs, ...) to produce its random values. The abstract algorithm starts from the final output of an adequate RNG that requires no further post-processing. There's nothing suspicious about this simplification. The critique in question makes no sense to me. Don't use a broken RNG.
That sounds about right to me, but as someone who is not a cryptographer, perhaps someone who is could explain how this amounts to a back door, and not a requirement for a good PRNG? And if it's not a back door, should we really relitigate NIST's choices here?
Eliot* By "back door", I mean an intentionally placed undisclosed weakness that could be exploited by the people who placed it there.
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
