[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

["D. J. Bernstein" <[e-mail]>]

Benjamin Kaduk writes:
> Can you repeat your analysis for a scenario involving a 16-bit CPU
> operating at a 100 MHz clock speed and with a 5 kBps network
> connection?

Is this 5000 bytes/second send plus simultaneously 5000 bytes/second
receive? Or 5000 bytes/second shared by send and receive?

For, e.g., ML-KEM-768, can the 1184 bytes (0.2368 seconds) one way be
overlapped with the 1088 bytes (0.2176 seconds) the other way, or do
they have to occupy 2272 bytes out of 5000 (0.4544 seconds)?

Either way, this communication for ML-KEM-768 is clearly slower than
X25519 in the scenario you're describing, since a 16-bit MSP430X takes
just 8 million cycles (https://eprint.iacr.org/2015/343) for DH, and
thus just 16 million cycles for keygen+DH (with a trivial reuse of DH
for keygen rather than putting more work into speeding up keygen), i.e.,
0.16 seconds at 100 MHz. The 32+32 bytes of traffic add at most 0.0128
seconds.

Figuring out the total costs of X25519 + ML-KEM-768 would be more work.
My experience with small devices is that computation can be overlapped
with communication, but of course one has to work out how much can be
parallelized inside the protocol, and how many cycles ML-KEM-768 needs
on this platform. From a throughput perspective (doing many key
exchanges), presumably the bottleneck would be communication, meaning
that ML-KEM-768 is 3% faster than X25519 + ML-KEM-768.

> Other IETF protocols attempting to support devices constrained on that
> scale have jumped through hoops

Sure, but there's a difference between the following processes: (1)
looking at platform details and trying to engineer something that fits
into the platform; (2) pointing vaguely in the direction of unspecified
embedded devices as a talisman to support a proposal for reducing cost,
without regard to whether the cost difference actually matters or
whether the devices can even run TLS in the first place.

---D. J. Bernstein


===== NOTICES =====

This document may not be modified, and derivative works of it may not be
created, and it may not be published except as an Internet-Draft. (That
sentence is the official language from IETF's "Legend Instructions" for
the situation that "the Contributor does not wish to allow modifications
nor to allow publication as an RFC". I'm fine with redistribution of
copies of this document; the issue is with modification. Legend language
also appears in, e.g., RFC 5831. For further background on the relevant
IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.)