[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]