Algorithm Role
Public Key Size Signature / Ciphertext Size
ECDSA P-256 (Identity / Signing)
~64 bytes ~64 bytes
X25519 (Key Exchange)
32 bytes 32 bytes
ML-DSA-44 (PQ; Identity / Signing)
1,312 bytes 2,420 bytes
ML-KEM-768 (PQ; Key Exchange)
1,184 bytes 1,088 bytes
> If you tried to make "ML-KEM Certificates" (using a newer mechanism called AuthKEM where you authenticate by proving you can decrypt a challenge rather than signing), you would replace the ~2.4 KB ML-DSA signature with a ~1 KB ML-KEM ciphertext. This saves about 50% of the bandwidth compared to ML-DSA, but it is still roughly 35x larger than a traditional ECC certificate chain./? AuthKEM:
kemtls/draft-celi-wiggers-tls-authkem: https://github.com/kemtls/draft-celi-wiggers-tls-authkem
"KEM-based Authentication for TLS 1.3" https://kemtls.org/draft-celi-wiggers-tls-authkem/draft-celi... :
> Table 1. Size comparison of public-key cryptography in TLS 1.3 and AuthKEM handshakes.
Handshake HS auth algorithm HS Auth bytes Certificate chain bytes Sum
...
AuthKEM Kyber-768 2272 6152 (Dilithium-2) 8424
AuthKEM Kyber-768 2272 2229 (Falcon-512) 4564
"KEM-based pre-shared-key handshakes for TLS 1.3" > "2.2. Key Encapsulation Mechanisms", "3. Abbreviated AuthKEM with pre-shared public KEM keys": https://kemtls.org/draft-celi-wiggers-tls-authkem/draft-wigg...> [With AuthKEM,] you would replace the ~2.4 KB ML-DSA signature with a ~1 KB ML-KEM ciphertext.
(Everyone dnvoted this like -6/-7. I guess they didn't understand the relevance.)
IDK a terse analogy then:
MerkleCerts + ML-DSA : ML-DSA :: Challenge (ML-KEM,) : ____ (ML-DSA)
Merkle-signing cert trust roots is a security/bytes-transferred efficiency tradeoff.
What is the difference in number of bytes seemed usefully relevant to me at least.