Post-Quantum TLS 1.3 and SSH Performance (preliminary outcomes)
Co-author: Dimitrios Sikeridis.
As raised on multiple occasions, in case a real-world quantum personal computer was built, it might jeopardize public key trade, encryption, and digital signature schemes found in secure tunnel protocols these days such as (D)TLS, SSH, IKEv2/IPsec and much more. To get ready for a post-quantum upcoming, NIST provides embarked on a journey of standardizing post-quantum algorithms, IETF has seen RFC draft submissions for making use of these algorithms and several vendors like Cisco, Microsoft, Cloudflare, Google, AWS have already been considering post-quantum key exchange or even authentication in TLS. These attempts examine important authentication or swap performance separately. Today they have proven some post-quantum algorithms perform slower than classical ones we make use of, while others would decelerate the TLS handshake significantly.
Almost all safe tunnel protocols would require the introduction of post-quantum algorithms within their crucial exchange and authentication mechanisms to become quantum-resistant. The performance of quantum-resistant key exchange and authentication is not extensively investigated yet altogether. Recently we’ve been focusing on tinkering with quantum-secure key trade together with authentication in TLS 1.3 and SSH. The preliminary email address details are promising as we anticipated by extrapolating from the prior studies.
We have been concentrating on efficient lattice algorithms for essential exchange just like the ntruhrss701 parameter of the NTRU NIST submission and Kyber-512 of the Kyber submission. These algorithms possess relatively small community keys and ciphertexts (≈1KB) with quick keygen/encapsulation/decapsulation (<1ms). Remember that our close friends at Cloudflare also examined NTRU-HRSS as an excellent candidate for TLS important exchange.
For authentication we’ve been experimenting with Dilithium that provides several KB signatures and general public keys with quick signing and verification. The Dilithium and Falcon submissions were proven to perform the very best in TLS inside our recent NDSS paper. We’ve also been looking at SPHINCS+-128f and SPHINCS+-192f from the SPHINCS+ NIST submission. SPHINCS+ is really a well-reliable algorithm which though it performed poorly in TLS, it had been expected by us to execute better in SSH.
Below we can start to see the Median and 95th percentile of the TLS 1.3 handshake time for classic crucial swap (P256 curve ECDH) and signature (2048-bit RSA) certificates, hybrid (classical+post-quantum) key trade (P256 curve ECDH and ntruhrss701) and traditional signature (2048-bit RSA) certificates, classic (P256 curve ECDH) and post-quantum signature (Dilithium III) certificates and hybrid essential swap (P256 curve ECDH and ntruhrss701) and post-quantum signature (Dilithium III) certificates.
We can see that post-quantum combinations are simply within 1-2ms slower compared to the classical handshake. That usually will abide by Cloudflare’s CECPQ2 results with NTRU-HRSS and our results with Dilithium III. The functionality of NTRU-HRSS is most likely slightly much better than previously due to AVX2 optimizations. Since both NTRU-HRSS and Dilithium III perform quick (<1ms), the excess overhead is introduced by the a lot more public important, ciphertext, and signature information transferred within the post-quantum handshake. This information amounts to approximately 13KB which does bring in extra round-trips because of TCP Congestion Manage and thus will not introduce much overhead.
Below we can start to see the Median and 95th percentile of the SSH handshake period for classic key trade (P256 curve ECDH) and signing keys (2048-bit RSA), hybrid crucial swap (P256 curve ECDH and ntruhrss701) and classic signing keys (2048-bit RSA), traditional (P256 curve ECDH) and post-quantum signing keys (SPHINCS+-128f) and hybrid key trade (P256 curve ECDH and ntruhrss701) with post-quantum signing (SPHINCS+-128f) keys.
We can easily see that hybrid essential exchange leads to around 1ms SSH handshake slowdown that is based on the TLS results. That may mostly be related to the couple of KB of extra information (public important, ciphertext) presented in the handshake by the post-quantum algorithm. When post-quantum SPHINCS+-128f keys are launched for authentication, the handshake decreases more significantly (approximately 30%). The nice reason may be the slower SPHINCS+-128f signing and much more importantly, both extra round-excursions introduced in each path by the TCP Congestion Manage because the SPHINCS+-128f signature (≈17KB) exceeds the TCP Preliminary Congestion Home window (initcwnd). A 30% SSH handshake slowdown could be appropriate since SPHINCS+ is among the many reliable signature algorithms which uses mature and well-understood tough problem. Otherwise, better executing signature algorithms like Falcon and Dilithium could be preferable if standardized by NIST.
We have been tinkering with various TCP Initial Congestion Screen (initcwnd) values to review the improvement they are able to provide by eliminated round-outings introduced by post-quantum algorithms. Results display that increasing the windowpane by 2-3MSS the SPHINCS+-128f handshakes considerably. SPHINCS+-192f demands over 30MSS congestion window to get a noticeable increase. The figure below displays the increase for a post-quantum SSH handshake when getting rid of one round-trip each path by improving the congestion window. In addition, it includes the flat period of an SSH handshake making use of classical crypto that will not incur any additional round-trips.
We plan to continue our tests to more globally distribute customers and servers to measure the effect on more realistic Web scenarios. We shall test a lot more parameters and algorithm mixtures in classic also, post-quantum and hybrid scenarios. Hopefully we are able to show there are a lot more satisfactory algorithm combos for a quantum-protected TLS and SSH without sacrificing present performance. We will share our outcomes in due time.
The post Post-Quantum TLS 1.3 and SSH Performance (preliminary results) appeared very first on Cisco Blogs.