[TLS] Re: Response to CoI Complaints

On Fri, Jul 17, 2026 at 05:49:30PM -0400, Daniel Apon wrote:
> > On Fri, Jul 17, 2026 at 03:51:32PM -0400, Daniel Apon wrote:
> > > I am happy, of course, to discuss the technical issue about hashing that
> > > Jacob has brought up. I will summarize that here:
> > 
> > My reply up-thread listed _my_ thinking on the matter.  The summary is
> > that because we don't have a practical PQDH we're just always going
> > to have an `m`-like RNG leak from the server to the client in any KEM we
> > choose to use, and it would be nice to know we're not using Dual_EC, but
> > obviously that's not easy to ascertain.  Thus I think all KEMs should
> > come with a statement that one should use DRBGs/RNGs that are not
> > Dual_EC-like.
> 
> Yes, we're locked into KEMs for PQC (so far), so the shared secret
> doesn't have "contributory entropy," but rather one party chooses all
> of the entropy.

Basically.  It's a bit hand-wavy because in some sense both parties
contribute entropy, but in another only the server does.

Others might want to skip to the bottom.

> Yet, the burden is on the entropy-provider party in the KEM (whether
> server or client) to shield itself against leaks of its own data; the
> recipient (who doesn't generate entropy of the shared KEM key) is the
> potential adversary; not the other way around, yes?  So, for the party
> generating 'm' and rather, the party generating the ML-KEM ciphertext
> c = Kyber.CCAKEM.Enc-without-internal-hash-derivation(pk; *coins*),
> it's up to the party itself to pass *coins* in a manner that is safe
> for itself.

Again, the concern here is the Dual_EC kleptography concept, though a
bit generalized.  I'm not entirely sure how the attack would work, but
the concern is that an active attacker who possesses a secret key to the
server's DRBG could use one or a few pure DRBG outputs (`m`) to
compromise many _other_ sessions terminated at the same server (but
where the attacker was _not_ the client).

> As has been pointed out in various places, this is true (in varying
> degrees) for essentially any KEM or KEX("PQDH"/"ECDH") standard.

It's not a concern for DH, but it is for KEMs.  It's not a problem for
DH because in DH the client does not see a DRBG output for the server,
only a public key share corresponding to a private key share derived
from a DRBG output, and this means the client can't mount a Dual_EC
style attack.  In DH the private->public key share operation functions
as the hash that was present in Kyber, but in a way that is provable in
a zero-knowledge way.  The hash that was in Kyber has no ZK proof.

You might retort -as I have- that the `Random` nonces in TLS 1.3 have
the same effect as `m`, but the retort to _that_ is that a TLS
implementation that supports FIPS modules might use a safe DRBG for its
nonces while a negotiated KEM ends up using an unsafe DRBG.  An unsafe
DRBG could be introduced in the future, or it could be Dual_EC (assuming
it really was backdoored, but everyone does).

> From the NIST perspective, this is intended to be handled entirely by the
> SP 800-90 series (800-90A, 800-90B, 800-90C);
> https://csrc.nist.gov/projects/random-bit-generation
> 
> So -- *importantly* -- the questions about whether "the Kyber/ML-KEM patent
> license" is *entirely independent* of Dual-EC-like RNG-flaw issues. If a
> party passes "clean"/un-trapdoored entropy to the ML-KEM specification via
> *coins*, then great. Such a party is immediately good to go, and then only
> relies on the lattice-mathematical arguments about Module-LWE as a secure
> source of asymmetric cryptography for their own security. (Full stop.)

One problem is that a ML-KEM implementation used via a FIPS module that
is safe-enough today might not be tomorrow because the choice of DRBG
might be internal to the module rather than being configurable by the
TLS implementation.

> Indeed, one can obviously explain the decision in the specification of
> Round3-Kyber and the ML-KEM standard as *an intentional decision to
> separate* RNG-trapdooring issues from the ML-KEM algorithm specification
> outright.

Yes.

> (Which is what makes this entire line of conversation for the past days and
> weeks so odd to me.)

It's not odd.  The issue is not whether the change to not hash the DRBG
output to generate `m` is justified/justifiable.  It's whether the risk
of ending up with a kleptographic DRBG is real.

Yes, some have jumped on that change and used it in ways that are not
conducive to identifying and resolving the real/putative issue.  That
was counterproductive.  But there is a real, technical concern.  And so
far in your reply and my reply to it we're only recapitulating that
concern, but now we shall address it finally:

> But to follow up,
> " Thus I think all KEMs should come with a statement that one should use
> DRBGs/RNGs that are not Dual_EC-like."
> 
> I'm sure, from the ML-KEM (and thus, NIST) perspective, some such statement
> should be present here:
> https://csrc.nist.gov/Projects/random-bit-generation/publications
> Or, you could ask for a single-sentence addendum to the "pure-ml-kem"
> draft; that should satisfy all ends, I believe. (I think it's just a
> mis-reading of the NIST standards documents to figure it otherwise.)

Yes, that's essentially what I'm suggesting.  I'm not sure one sentence
will do -- it might have to be two or three, and a reference or three,
and a normative statement ("don't do this").

Here, let me make a start:

   Note that KEMs invariably leak what amounts to RNG outputs from the
   server to the client.  It is imperative that the RNG (DRBG) be secure
   against any attacks that could recover RNG state, whether because the
   RNG design is cryptographically weak or because it is backdoored.
   For example, one should not use the Dual_EC DRBG.  See [reference(s)
   here to NIST and/or IETF documents regarding RNG safety].

For specific KEMs, such as ML-KEM, I'd write:

   Note that KEMs, including ML-KEM, invariably leak...

Nico
-- 

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]