[TLS] Re: Response to CoI Complaints

*Gasarch's Rule: A proper Reply thread should descend in length 1/2 of
itemized-elements per reply, so as to terminate in log(size)
rounds.Corollary: Each reply will grow by 4x so as to make the limit of the
thread diverge to infinity.*

" 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.
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.

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

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.
(Which is what makes this entire line of conversation for the past days and
weeks so odd to me.)

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.)

--Daniel

On Fri, Jul 17, 2026 at 4:50 PM Nico Williams <[email protected]> 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.
>
> > [...]
> >
> > However, one should clearly see how benign the entire thing is. [...]
>
> I'm sure the justification was bening.  That is not my concern.
>
> > I am very happy to chat about the technical matter; I'm interested in
> this
> > too!
>
> Well, you can find my post up-thread or see the above summary.
>
> > On the other hand, while I am "required" to engage with the TLS WG
> mailing
> > list as a part of my professional duties at my job, I am not "required"
> to
> > engage with [...]
>
> Eh, I'm not asking you to.  And I myself have conveyed how annoying that
> mode of argument is.  But now you're replying to me.
>
> Nico
> --
>

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