On Mon, 23 Feb 2026, 7:06 pm D. J. Bernstein, <[email protected]> wrote:
> Writing off-list since the list is censored. > Writing on-list because that's the entire reason I'm a member. > Jack Grigg writes: > > Compute in the hybrid solution would predominantly be determined by > ECDHE, > > not ML-KEM. See e.g. [0] [1] for numbers. > > It's true that on big CPUs the _cycles_ for ML-KEM are lower than the > _cycles_ for ECDHE. I'm glad you agree that my statement was correct. Cheers, Jack However, the dominant cost of ECDHE+ML-KEM by far is > the _communication cost_ for ML-KEM. See > > https://blog.cr.yp.to/20260219-obaa.html#cost > > for many numbers and supporting links. > The myth that removing ECC from ECC+PQ produces an important speedup is > the most effective part of the NSA/GCHQ anti-hybrid advertising. I > disputed the NSA/GCHQ claims years ago in > > https://blog.cr.yp.to/20240102-hybrid.html > > but of course they simply keep flooding the zone with misinformation. > > The draft-ietf-tls-mlkem motivation statement was circular for almost > all of the draft's existence, but version -06 of draft-ietf-tls-mlkem > a day before "last call" suddenly claimed "constrained environments > where smaller key sizes or less computation are needed". Note the word > "needed". The claim was then _edited_ but there was no _erratum_. The > replacement text refers to "smaller key sizes or less computation" as a > "use case"; this doesn't say explicitly that the savings are important > but it still makes the reader _think_ they are, which isn't true. > > ---D. J. Bernstein >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
