[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08) (was Re: Re: Response to CoI Complaints)
Nico Williams <[email protected]> Sat, 18 Jul 2026 16:04:25 -0500
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <alvqWXLmRYISMuVr@ubby> |
On Sat, Jul 18, 2026 at 12:46:40PM -0500, [email protected] wrote: > I see you have had enough free time to write several long messages. > > Do you have enough time to write a short one? In particular, I asked > you a few days ago what I believe to be a question of vital > importance. Does pre-hashing m do anything? I am not Jacob. I can answer this a bit concisely: - IF you found yourself using a backdoored RNG, pre-hashing `m` would destroy the structure of the RNG's output - it is not possible to distinguish whether `m` was pre-hashed - therefore it is difficult to build a test suite for validation of the use of pre-hashing, and it is therefore justifiable to remove it So: not much, because you can't be certain that the implementation you're using does indeed pre-hash `m` (not even FIPS validation might be enough to be certain). ======================================================================== It's important to note that with plugin-based designs it's entirely possible that the RNG used for generating TLS 1.3 `Random` nonces is safe and the one used for a KEM's `m` is not, and to be unaware of what RNGs are used for what even. Relatedly: because all KEMs have this RNG output leakage problem we should have used cascading/nested hybrid constructions to extend the lifetime of classical DH in a PQ world and avoid RNG output leakage. Nico -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]