Nice! If that wasn't brought up as something to document in the draft so far in the mailing list discussion with those two references, please do so!
+1 I would recommend citing "Daniel J. Bernstein and Tanja Lange (editors). eBACS: ECRYPT Benchmarking of Cryptographic Systems". eBACS is well-respected, long-lived, relatively up to date, covers many algorithms and architectures, specifies the exact platforms, and is reproducible. https://bench.cr.yp.to/results-kem.html https://bench.cr.yp.to/results-dh.html Below are numbers I recently calculated from eBACS Intel Core 5 210H 2.2 GHz +------------------+------------------------+------------------+ | | Sec | Sizes (bytes) | Ops per second | | Algorithm | Lvl | Client | Server | Client | Server | +------------------+-----+---------+--------+--------+---------+ | X25519 | 0 | 32 | 32 | 22,000 | 22,000 | | ML-KEM-512 | 1 | 800 | 768 | 53,000 | 106,000 | | ML-KEM-768 | 3 | 1,184 | 1,088 | 32,000 | 67,000 | | ML-KEM-1024 | 5 | 1,568 | 1,568 | 23,000 | 47,000 | | HQC-KEM-128 | 1 | 2,249 | 4,497 | 6,000 | 13,000 | | mceliece348864 | 1 | 261,120 | 96 | 60 | 77,000 | | FrodoKEM-640 | 1 | 9,616 | 9,729 | 1,200 | 2,000 | +------------------+-----+---------+--------+--------+---------+ Cheers, John From: Toerless Eckert <[email protected]> Date: Monday, 23 February 2026 at 03:45 To: Jack Grigg <[email protected]> Cc: <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27) Nice! If that wasn't brought up as something to document in the draft so far in the mailing list discussion with those two references, please do so! (for something like the cloudflare URL i would always recommend to first cache the URL on archive.org and put that archive.org URL also into the reference. I think there might even be an RFC talking about the problem of persistent references). Cheers Toerless On Mon, Feb 23, 2026 at 03:38:04PM +1300, Jack Grigg wrote: > Hi Toerless, > > On Mon, 23 Feb 2026, 1:49 pm Toerless Eckert, <[email protected]> wrote: > > > > > At minimum, it would be lovely to have at least ONE example in the RFC, > > how the > > added amount of storage and compute for ECDHE in the hybrid solution is > > significant, given how (in my laymen understanding), both storage and > > compute > > would predominatly be determined by MLKEM. Else the intro claim "targeting > > smaller key > > sizes or less computation" is just marketing that should be removed. > > > Compute in the hybrid solution would predominantly be determined by ECDHE, > not ML-KEM. See e.g. [0] [1] for numbers. > > Cheers, > Jack > > [0] > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fhtml%2F2508.01694v3&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e4cb070be24414966508de72859052%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639074115136236022%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6FQ8%2BJEQ27BwJwnE6L%2FArOLMQJgcmiaTkqk3yypzih8%3D&reserved=0<https://arxiv.org/html/2508.01694v3> > [1] > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.cloudflare.com%2Fpq-2024%2F%23ml-kem-versus-x25519&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e4cb070be24414966508de72859052%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639074115136255077%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SXqUjF3DjW4uzfKUp9mDhM6MI1y4FDyLc0c2HwYps3o%3D&reserved=0<https://blog.cloudflare.com/pq-2024/#ml-kem-versus-x25519> > > > > > > Or to paraphrase Uncle Ben: > > > > With great power over crypto comes great responsibility to explain better. > > > > Cheers > > Toerless > > > > On Thu, Feb 12, 2026 at 11:05:22AM -0800, Joseph Salowey wrote: > > > This message starts the second Working Group Last Call for the pure > > ML-KEM > > > document (draft-ietf-tls-mlkem-07). > > > > > > > > > The file can be retrieved from: > > > > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tls-mlkem%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e4cb070be24414966508de72859052%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639074115136266938%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AuKJT0XpX6UhzX%2FDfLOecRIQQ8vWlbuixJD3f6dvJoo%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/> > > > > > > The diff with the previous WGLC draft (-05) is here: > > > > > > > > > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-tls-mlkem-05%26url2%3Ddraft-ietf-tls-mlkem-07%26difftype%3D--html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e4cb070be24414966508de72859052%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639074115136276917%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=U%2FliRim31ZLh4db5JOQWD0WYdQnv%2FAxDOP6%2BnaWwqgw%3D&reserved=0<https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html> > > > < > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-tls-mlkem-05%26url2%3Ddraft-ietf-tls-mlkem-06%26difftype%3D--html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e4cb070be24414966508de72859052%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639074115136286571%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0L178Xa0Hkk2EioMfD8AJV5g6es9Y9Er42mGuAN7D1o%3D&reserved=0<https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-06&difftype=--html> > > > > > > > > > > > > The main focus of this WGLC is to review new text providing more context > > > around the use of pure ML-KEM. For those who indicated they wanted this > > > text, please let us know if the new text satisfies you and if you support > > > publication. This working group last call will end on February 27, 2026. > > > > > > > > > Thank You. > > > > -- > > --- > > [email protected] > > > > _______________________________________________ > > TLS mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > -- --- [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
