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.) _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
