wolfSSL Adds Support for the Deos Safety Critical RTOS
wolfBoot – wolfSSL’s Secure Bootloader
wolfSSH Version 1.4.0 Now Available
wolfSSL FIPS-Ready
Building WebSocket++ with wolfSSL Support
wolfCrypt FIPS Certificate #3389
TLS 1.3 Performance Analysis – Throughput
Some interesting results were found when comparing the throughput of TLS 1.2 and TLS 1.3 using an assembly optimized wolfSSL – some good, some bad. This is the last of the blogs discussing the performance differences observed between TLS 1.2 and TLS 1.3 in wolfSSL and how to make the most of them in your applications. There are differences in the way the data is encrypted in TLS 1.2 and 1.3. For some algorithms this makes a noticeable difference.
TLS 1.2 encrypts the plaintext of the message and generates an authentication code on the encrypted data plus additional_data which includes: a 64-bit sequence number, 1 byte content type, 2 byte version and 2 byte length. This is a total of 13 extra bytes in additional_data.
TLS 1.3 encrypts the plaintext of the message plus one byte for the real record type and generates an authentication code on the encrypted data plus the record header of 5 bytes.
For AES-GCM cipher suites the throughput was observed to be slightly increased with the Intel x86 64-bit optimized assembly code. This is due to the number of bytes passed in as additional authentication data (AAD). The AAD bytes are processed separately before encryption and decryption and it turned out processing 5 bytes was faster than 13. The extra byte on the end of the encrypted data did not have a significant impact.
For Chacha20-Poly1305 the different size of data passed in as AAD has no significant impact as the data is placed into a 16 byte block and padded before being processed. But, the extra byte at the end of the plaintext did impact the Chacha20 and Poly1305 performance. For Poly1305, the extra byte resulted in an extra 16 byte block being processed. In total this had about a 3-5% impact on throughput with the Intel x86 64-bit optimized assembly code.
TLS 1.3 has better throughput when using AES-GCM and is another reason to change. For maximum throughput consider sending one less than the maximum plaintext size, by default 16384 bytes, in an application data message. This will have a positive impact for both AES-GCM and Chacha20-Poly1305 cipher suites.
Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)
Part 3 (TLS 1.3 Performance – Pre-Shared Key (PSK))
Part 4 (TLS 1.3 Performance – Server Pre-Generation)
Part 5 (TLS 1.3 Performance – Client-Server Authentication)
wolfSSL Renesas Support
TLS 1.3 Performance Analysis – Client-Server Authentication
TLS 1.3 has some significant changes from TLS 1.2 in the ordering of handshake messages and this impacts performance. This is the fifth part of six blogs discussing the performance differences observed between TLS 1.2 and TLS 1.3 in wolfSSL and how to make the most of them in your applications. This blog discusses how the changes to certificate based client-server authentication in TLS 1.3 adversely affects performance.
Let’s start with a look at the TLS 1.2 full handshake performing client-server authentication with certificates below.
A TLS 1.3 full handshake (without HelloRetryRequest) performing client and server authentication with certificates is given below.
Notice that there is one less round trip until Application Data can be sent in TLS 1.3 as compared to TLS 1.2. This improves performance on high latency networks but there is a downside. What is clear in the diagram is when messages are sent but not how and when handshake messages are processed.
The table below restates the TLS 1.2 handshake, but includes the processing of messages and the major cryptographic operations that are performed. Operations are on the same line if the operations are performed at the same time relative to network latency.
The server produces a KeyShare, sends the ServerHello, and then quickly sends the EncryptedExtensions, CertificateRequest and Certificate messages. The CertificateVerify takes a while to produce and the Finished message is quick. The client takes a while to process the KeyShare, quickly process the EncryptedExtensions and CertificateRequest messages, and spends a long time performing certificate chain verification. The CertificateVerify will typically arrive during the chain verification and then the client processes the rest of the messages synchronously. As a result, there is little overlap.
From this we can see that for RSA where Verify is very fast relative to Sign, a TLS 1.2 handshake is dependent on: 2 x Key Gen, 2 x Secret Gen, 1 x Sign and 2 x Verify. For ECDSA, where Verify is slower than Key Gen plus Sign: 1 x Secret Gen and 3 x Verify.
The table below restates the TLS 1.3 handshake, including processing of message and the major cryptographic operations.
From this we can see that a TLS 1.3 handshake using RSA certificates is dependent on: 2 x Key Gen, 1 x Sercret Gen, 2 x Sign. Therefore a Secret Gen and 2 x Verify in TLS 1.2 are replaced with a Sign. Using ECDSA a handshake is dependent on: 2 x Key Gen, 1 x Sercret Gen and 4 x Verify. Therefore, a Secret Gen and Sign in TLS 1.2 is replaced by 2 x Verify.
This means that for low latency networks TLS 1.3 can be slightly slower or about as fast as TLS 1.2. The only practical mitigation for ECC certificates is to minimize the amount of work performed in chain verification. Having the server certificate stored on the client and/or the client certificate stored on the server will improve TLS 1.3 performance but at the risk of lower security.
The next blog will be the final one in this series and will discuss difference in throughput between TLS 1.2 and 1.3.
Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)
Part 3 (TLS 1.3 Performance – Pre-Shared Key (PSK))
Part 4 (TLS 1.3 Performance – Server Pre-Generation)