RECENT BLOG NEWS
TLS 1.3 Performance Analysis – Server Pre-Generation
TLS 1.3 has some significant changes from TLS 1.2 that are targeted at performance. This is the fourth 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 the server generating a key pair before the handshake starts.
As mentioned in the first blog in this series there is a way to mitigate some of the key exchange cost in TLS 1.3. If the server knows which key exchange algorithm will be used, it can preemptively generate a key pair after accepting a TCP/IP connection by calling wolfSSL_UseKeyShare(). In an architecture where both end-points are controlled by the same entity, a choice of security parameters, like the key exchange algorithm, is made upfront and can be relied on.
When directly connecting to a server, typically, a client only starts creating the ClientHello once a TCP/IP connection has been made. The server accepts the connection and waits for the client to generate a key share and send a ClientHello message. In this time, the server can also generate a key pair.
When using DH for key exchange this provides a significant saving as key generation is expensive. For example when using RSA for server authentication and running both client and server on the same computer, the connection is about 20% faster and with session reuse or PSK for server authentication, the connection is about 30% faster. For connections using ECDH with ECDSA for server authentication, the connection is only about 4% faster and with session reuse or PSK for server authentication, the connection is about 7% faster. EC key generation is very fast in optimised implementations and the impact of hiding its cost is therefore less.
Servers currently reuse the ephemeral key pair across multiple connections. It is common to regenerate the key pair once an hour up to once a day. This mechanism can be used instead of server pre-generation but at the cost of perfect forward security for the server.
If your architecture allows for it, the server should be implemented to generate the key pair after accepting a connection. For DH, it is well worth it. But even for ECDH the small performance improvement will result in more connections per second.
The next blog will discuss the performance issues with handshakes performing client-server authentication.
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))
TLS 1.3 Performance Analysis – Pre-Shared Key (PSK)
TLS 1.3 has a different handshake flow when using pre-shared keys and this impacts performance. This is the third 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 and why PSK handshakes are only similar in speed generally but faster when using DH style key exchange.
For TLS 1.2, handshakes using PSK are defined in a separate document (RFC 4279). In order to fit in with the existing flow, a full handshake is performed. In TLS 1.3, PSK handshakes are the same as resumption handshakes. Therefore there is one less round-trip required for TLS 1.3.
This change in flow has a significant impact on the performance of TLS 1.3. The amount of hashing and encryption/decryption has increased but losing a round-trip means that using PSK without a DH style key exchange is only slightly slower. On higher latency networks, the difference is trivial and the savings great.
In TLS 1.3 using DH or ECDH with PSK results in the following handshake operations.
So, the secret is calculated on the server after the ServerHello is sent. This means that the processing of the ServerHello and secret calculation on the client is happening at the same time relative to the server calculating the secret. The parallel secret generation resulted in, with client and server running on the same computer, TLS 1.3 being about 25% faster than TLS 1.2 when using DH. Using ECDH with P-256, TLS 1.3 is about 15% faster.
It is clear that using pre-shared keys in a secure way, with DH style key exchange, is faster with TLS 1.3 in wolfSSL. The next blog will discuss use cases that result in the removal of a key generation from the list of expensive cryptographic operations in TLS 1.3.
Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)
For more information regarding wolfSSL performance or usage of PSK, please contact facts@wolfssl.com.
Differences between TLS 1.2 and TLS 1.3 (#TLS13)
wolfSSL's embedded SSL/TLS library has included support for TLS 1.3 since early releases of the TLS 1.3 draft. Since then, wolfSSL has remained up-to-date with the TLS 1.3 specification. In this post, the major upgrades of TLS 1.3 from TLS 1.2 are outlined below:
TLS 1.3
This protocol is defined in RFC 8446. TLS 1.3 contains improved security and speed. The major differences include:
- The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
- A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
- Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
- All handshake messages after the ServerHello are now encrypted.
- Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
- The handshake state machine has been restructured to be more consistent and remove superfluous messages.
- ECC is now in the base spec and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
- Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
- TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
- Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.
More information about the TLS 1.3 protocol can be found here: https://www.wolfssl.com/docs/tls13/. Additionally, please contact facts@wolfssl.com for any questions.
OpenSSL Compatibility Layer Expansion
Recently, wolfSSL released version 4.0.0 of the wolfSSL embedded SSL/TLS library. This new version includes many new port/feature additions, maintenance updates, and a couple bug fixes. Among those new feature additions includes multiple new API added to wolfSSL's OpenSSL compatibility layer! The compatibility layer is a series of commonly used and essential API that users can utilize to transition from OpenSSL to wolfSSL. The function names are redefined as their wolfSSL counterparts, which have similar signatures and output to their OpenSSL counterparts.
The list of new compatibility API included with the most recent release include the following:
- BN_Init
- EVP_Digest
- EVP_MD_CTX_block_size
- EVP_MD_CTX_size
- EVP_PKEY_assign_EC_KEY
- EVP_PKEY_assign_RSA
The list of OpenSSL compatibility API that were added in the release prior can be found here: https://www.wolfssl.com/openssl-compatibility-layer-expansion-2/
wolfSSL also provides support for TLS 1.3! More information can be found here: https://www.wolfssl.com/docs/tls13/.
wolfSSL is available for download at the wolfSSL download page here (https://www.wolfssl.com/download/), or through a git-clone of the wolfSSL repository here (https://github.com/wolfssl/wolfssl.git).
For more information about wolfSSL or porting from OpenSSL, please contact facts@wolfssl.com.
wolfSSL Adds Support for the Deos Safety Critical RTOS
Are you a user of Deos? If so, you will be happy to know that wolfSSL recently added support for Deos RTOS and added TLS client/server examples to the wolfSSL embedded SSL/TLS library for Deos!
Deos is an embedded RTOS used for safety-critical avionics applications on commercial and military aircraft. Certified to DO-178C DAL A, the time and space partitioned RTOS features deterministic real-time response and employs patented “slack scheduling” to deliver higher CPU utilization.
The Deos port in wolfSSL is activated by using the "WOLFSSL_DEOS" macro. For instructions on how to build and run the examples on your projects, please see the “<wolfssl-root>/IDE/ECLIPSE/DEOS/README” file. This support is currently located in our GitHub master branch, and will roll into the next stable release of wolfSSL as well.
wolfSSL provides support for the latest and greatest version of the TLS protocol, TLS 1.3! Using the wolfSSL port with your device running Deos will allow your device to connect to the internet in one of the most secure ways possible.
For more information, please contact facts@wolfssl.com.
Resources
The most recent version of wolfSSL can be downloaded from our download page, here: https://www.wolfssl.com/download/
wolfSSL GitHub repository: https://github.com/wolfssl/wolfssl.git
wolfSSL support for TLS 1.3: https://www.wolfssl.com/docs/tls13/
Deos RTOS homepage: https://www.ddci.com/category/deos/
wolfSSH Port for µC/OS-III
At wolfSSL, we currently have a wolfSSH port to µC/OS-III in the works! µC/OS-III is a highly portable and scalable real-time kernel. Designed for ease of use on a huge number of CPU architectures, these kernels are a key component of the µC/OS real-time operating system. The features of this kernel allow it to pair nicely with the wolfSSH SSHv2 library, resulting in the maximization of the best possible encryption, speed, and strength while simultaneously allowing for minimal resource usage.
Other features that are readily available and currently supported by wolfSSH include SCP, SFTP, client authentication via RSA keys or passwords, and more!
More information about the wolfSSH library: https://www.wolfssl.com/products/wolfssh/
For more information not included, please contact facts@wolfssl.com.
wolfSSL’s Effective Timing Resistance
In cryptography and encryption, timing can be an unconsidered element of the security for various operations. However, if an encryption library is built without considering timing or the possible attacks that a malicious agent could execute with timing attacks, then that encryption library could be vulnerable to multiple different attacks that have occurred or can occur. An actual timing attack requires the agent to precisely time the logical operations performed by a CPU or other device, and by measuring these times is able to construct the sensitive data that was used to perform these operations. These kinds of attacks are even practical against well known, generally secure algorithms including RSA, DSA, and other signature algorithms.
When it comes to the wolfCrypt crypto engine, there are features in place by default to protect against timing attacks. Although these features are enabled by default, to ensure that wolfSSL's timing resistance is enabled, users can either enable it through wolfSSL's configure script or manually define the relevant preprocessor defines. The option "--enable-harden" can be passed to configure to enable both timing resistance and RSA blinding. Macros that can be manually defined are listed below:
ECC_TIMING_RESISTANT /* define to enable timing resistance in ECC */ TFM_TIMING_RESISTANT /* define to enable timing resistance in underlying fastmath math library */
More information on timing attacks can be found here: https://en.wikipedia.org/wiki/Timing_attack
For more information about the wolfSSL embedded SSL/TLS library or other security features offered, please contact facts@wolfssl.com. wolfSSL also supports TLS 1.3!
TLS 1.3 Performance Analysis – Full Handshake
Significant changes from TLS 1.2 have been made in TLS 1.3 that are targeted at performance. This is the second 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 the performance differences with regard to full handshake with server authentication using certificates.
Let’s start with a look at the TLS 1.2 full handshake performing server-only authentication with certificates below.
A TLS 1.3 full handshake (without HelloRetryRequest) performing server-only authentication with certificates is 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 significantly improves performance especially on high latency networks. But, there is another source of performance improvement arising from the ordering of the handshake messages and when lengthy cryptographic operations are performed.
In the TLS handshake, the server waits on the ClientHello and then sends handshake messages as it produces them in separate packets. When packets are sent is dependent on the amount of processing required to produce the data. For example, to copy a chain of certificates into the Certificate messages is quick, while generating a TLS 1.2 ServerKeyExchange message is slow as it requires multiple public key operations.
The client receives the messages at various time deltas and also requires differing amounts of processing. For example, the Certificate message is likely to require at least one signature verification operation on the leaf certificate. This asymmetric processing of messages means that some handshake messages will be processed on arrival and some will have to wait for processing of previous messages to be completed.
The table below restates the TLS 1.2 handshake but includes processing of messages and the major cryptographic operations that are performed. Operations are on the same line if the they are performed at the same time relative to network latency.
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 1 x Verify. For ECDSA, where Verify is slower than Key Gen plus Sign: 1 x Key Gen, 2 x Secret Gen and 2 x Verify.
The table below is a restating of 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 with RSA, where Verify is a lot faster than Sign, is dependent on: 2 x Key Gen, 1 x Secret Gen, 1 x Sign. Therefore, a Secret Gen and Verify in TLS 1.2 are saved. For ECDSA, where Verify is a lot slower than Sign, the TLS 1.3 handshake is dependent on: 2 x Key Gen, 1 x Secret Gen, 2 x Verify. Therefore, a Secret Gen in TLS 1.2 is traded for a faster Key Gen.
Running both the client and server on the same computer results in about a 15% improvement in the performance of ephemeral DH with RSA handshakes – mostly due to the parallel operations. With ephemeral ECDH and RSA there is about a 6% improvement, and with ECDHE and ECDSA there is about a 7% improvement – mostly due to the saving in round-trips.
These improvements come for free when using TLS 1.3 without the HelloRetryRequest. The next blog will discuss handshakes using pre-shared keys.
For more information regarding wolfSSL and the TLS 1.3 full handshake, please contact facts@wolfssl.com.
wolfSSL at NXP Tech Days Minneapolis
wolfSSL is at wolfSSL at NXP Tech Days Minneapolis this year! NXP Technology Days is a deep-dive, technical training program for engineers designing solutions with embedded technology. This one-day event offers hands-on workshops and technical lectures over multiple markets enabling attendees to customize a schedule that is most relevant to their training needs.
Where wolfSSL will be located for this Tech Days:
Venue: Doubletree by Hilton Minneapolis Park Place
When: April 16, 2019
Directions: https://doubletree3.hilton.com/en/hotels/minnesota/doubletree-by-hilton-hotel-minneapolis-park-place-MSPPHDT/maps-directions/index.html
Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, to meet the wolfSSL team, or to get some free stickers and swag!
For more information about wolfSSL, its products, or future events, please contact facts@wolfssl.com.
More information about NXP Tech Days can be found here: https://www.nxp.com/support/training-events/nxp-technology-days:NXP-TECH-DAYS
TLS 1.3 Performance Analysis – Resumption
TLS 1.3 is the latest version of the SSL/TLS specification. There are significant changes to messages and the message flow. These changes are targeted at security and performance.
The first performance difference to note is a degradation. In TLS 1.2 performing a resumption handshake is very quick. This comes at a security cost though. Each time a client resumes a session, the same session ID is used and the same master secret is used. Therefore, if the master secret is compromised then all resumed sessions are revealed. Also, TLS 1.2 resumption is stateful and can have performance issues in a multi-server architecture.
TLS 1.3 only uses session tickets to resume a session. This mechanism has the client send an opaque session ticket to the server that contains a server encrypted version of all the information required to resume the session. Once again the same master secret is used across handshakes but the default behavior is to perform a key exchange. A unique, shared secret is generated and combined with the master secret when calculating keys and IVs. This mechanism then provides forward secrecy.
The performance trade-off here is that using a session ticket requires decryption of the session ticket. Also, TLS 1.3 performs more encryption/decryption and hashing operations in the handshake anyway. Therefore, when running a client and server on the same computer, a TLS 1.3 handshake is more than 20% slower. On a high latency network, these will not be noticeable as symmetric cipher and digest algorithms are the fastest of operations.
But also consider the default behaviour that results in a key exchange. DH key and secret generation are some of the most expensive operations and the handshake, again running both client and server on the same computer, using 2048-bit DH parameters can take 13 times as long as TLS 1.2 resumption. ECDH can be used instead and is at least twice as slow when using a highly optimised implementation.
There is no way in TLS 1.3 to avoid this performance degradation and resumption has the fastest handshake performance. Using optimised ECDH will give you the best performance and better security. There is a way to improve the resumption performance, in some cases, which will be discussed in a future blog in this series.
For more information about wolfSSL and TLS 1.3 session ticket resumption, please contact facts@wolfssl.com.
Weekly updates
Archives
- November 2024 (26)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)