On Tue, Jul 26, 2022 at 02:15:34PM +0200, Thom Wiggers wrote: > > In yesterday’s working group meeting we had a bit of a discussion of the > impact of the sizes of post-quantum key exchange on TLS and related > protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide > deck (unlike the signature schemes), I thought it would be a good idea to > get the actual numbers of Kyber onto the mailing list. > > Note that in the context of TLS’s key exchange, the public key would be > what goes into the ClientHello key_shares extension, and the ciphertext > would go into the Server’s ServerHello key_shares extension. > > Kyber512: NIST level I, "strength ~AES128" > public key: 800 bytes > ciphertext: 768 bytes > secret key: 1632 bytes > Kyber768: NIST level III, "~AES192" > public key: 1184 > ciphertext: 1088 > secret key: 2400 bytes > Kyber1024: NIST level V, "~AES256" > public key: 1568 > ciphertext: 1568 > secret key: 3168 > > So for the key exchange at least, it seems to me Kyber512 should work for > TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if you want to > stay in QUIC’s default 1300 byte initial packet? Also, I don't really know > how the D of DTLS might change the story.
The initial packet size is 1200, so Kyber768 public key does not fit into a packet. However, the initial packets can be split, so even Kyber1024 key does fit into two initial packets (this also doubles the server initial window from 3600 to 7200 due to the way amplification limit works) DTLS is a bit more problematic. There are two ways to deal with the key being too big to fit in a single IP packet. - IP-level fragmentation. REALLY SHOULD NOT be used. - DTLS-level fragmentation. There are buggy implementations that break if one tries this. And in both case, the failure modes are not easy to recover from. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
