> That’s easy to answer: “many of our members have very hardware-constrained > PoS devices.” Is that okay?
Some context: Kyber requires several KB of RAM space according to [1], figure 1: KG = KeyGen, E=Encaps, D=Decaps, H=Heap, S=Stack Alg | KG(H) | KG(S) | E(H) | E(S) | D(H) | D(S) ----------+-------+-------+-------+-------+-------+------ Kyber1024 |13,480 |16,488 |10,736 |19,024 |10,768 |20,304 Kyber512 |11,176 | 7,208 | 7,632 | 9,072 | 7,664 | 9,856 Kyber768 |12,328 |11,304 | 9,104 |13,680 | 9,136 |14,784 For comparison, [2] is an implementation of Curve25519 using no heap space. On an ATmega128, it uses 462 bytes of stack space for a curve multiplication. While these numbers are not comparable as is (C25519 does not include the KEM-Hash, Architectures are different, I am unconvinced that Kyber was fully optimized for this in [1]), the difference is striking enough to ask a follow up: Are there concrete devices/scenarios supporting ML-KEM + an application, but not ML-KEM + X25519 + an application, especially since the memory necessary to store two X25519 keys and a DH-KEM session key during the ML-KEM computations is 3*32 bytes? -- TBB [1] https://link.springer.com/article/10.1007/s43926-024-00069-2 [2] https://www.dlbeer.co.nz/oss/c25519.html
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
