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.

wolfSSL and the Selfie Attack

People have been asking if wolfSSL is vulnerable to the ’Selfie’ attack (https://eprint.iacr.org/2019/347).  We are glad to say that we follow all the recommendations made by the authors.  First, though, an explanation of the attack.


The attack targets the use of Pre-Shared Keys (PSKs) with TLS 1.3 though TLS 1.2 is also vulnerable.  There are very specific use cases that are affected. When a group of computers want to connect to each other then sharing a PSK is a simple way to set things up. Membership of the group is based on the knowledge of the PSK.  This means that certificate authentication is not used.


The attack scenario is when a new computer comes into the network that can intercept or Man-in-the-Middle (MitM) the communications between computers.  When a computer, let’s call it Alice, acting as a client sends a TLS ClientHello, the MitM, which we’ll call Eve, reflects the message back in a new connection to Alice.  Alice acting as a server sees a new TLS ClientHello and in parallel responds with the first round of messages. These messages are sent back by Eve to the client on Alice. Alice as a client uses the messages to establish a connection and sends a response.  Eve uses the response to respond to Alice the server and so on and a secure connection is established.

Because everyone is using the same PSK for client and server connections, Alice does not notice anything wrong!  Now that a secure connection has been established, which Eve cannot decrypt, it can be hard to see what the issue would be.  The attack comes when a message like ‘Delete your copy of this file, I have a copy’ is sent. Eve reflects the message back and Alice decides that the she doesn’t have to keep a copy after all and deletes it.

The paper lists a number of scenarios that may be vulnerable:

  • Content Delivery Networks (CDNs) - poisoning caches.
  • P2P Networks.
  • WiFi networks that rely on PSKs for the entire network.
  • Leader-election and consensus protocols.

Mitigations and Recommendations

One way to prevent this attack is to use the Server Name indicator (SNI) extension. This way Alice recognises she didn’t connect to the computer she wanted to but to herself.

The recommendations of the paper are:

  • Don’t share PSKs amongst a group of computers unless certificates are used initially to establish identity. This goes against the PSK use case!
  • If you must use a shared PSK without certificates, then use the SNI extension.
  • TLS toolkits should either not implement PSK or not have it configured by default.

By default in wolfSSL, PSKs are not enabled but are available for use when you need it.  wolfSSL also implements the SNI extension and we encourage you to use it.

For more information about the wolfSSL library, please contact facts@wolfssl.com.

wolfSSL FIPS-Ready

With the recent release of wolfSSL 4.0.0, the wolfSSL team has also released a new product: the wolfSSL FIPS Ready library. This product features new, state of the art concepts and technology. In a single sentence, wolfSSL FIPS Ready is a testable and free to download open source embedded SSL/TLS library with support for FIPS validation, with FIPS enabled cryptography layer code included in the wolfSSL source tree. To further elaborate on what FIPS Ready really means, you do not get a FIPS certificate and you are not FIPS approved. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and Power On Self Test (POST).

FIPS validation is a government certification for cryptographic modules that states that the module in question has undergone thorough and rigorous testing to be certified. FIPS validation specifies that a software/encryption module is able to be used within or alongside government systems. The most recent FIPS specification is 140-2, with various levels of security offered (1-5). Currently, wolfCrypt has FIPS 140-2 validation with certificates #2425 and #3389. When trying to get software modules FIPS validated, this is often a costly and time-consuming effort and as such causes the FIPS validated modules to have high price tags.

Since the majority of wolfSSL products use the wolfCrypt encryption engine, this also means that if wolfSSH, wolfMQTT (with TLS support), wolfBoot, and other wolfSSL products in place can be tested FIPS validated code with their software before committing.

wolfSSL FIPS Ready can be downloaded from the wolfSSL download page, here: https://www.wolfssl.com/download/

For more information about wolfSSL and its FIPS Ready initiative, please contact facts@wolfssl.com.

wolfSSL JSSE Support Coming Soon!

Recently, we announced that there was support for JSSE in the works at wolfSSL. That project is currently nearing completion, and wolfSSL will soon be happy to announce its support for providing JSSE included with the wolfSSL-JNI library!

Java Secure Sockets Extension (JSSE) is a way for Java applications to utilize the SSL and TLS protocols through a standardized Java API using pluggable “providers” underneath - which is where wolfSSL will come in to place. wolfSSL provides SSL and TLS support up to the most recent versions of these protocols, and also provides high speed and strength encryption as well. Other beneficial features include potential use of wolfCrypt FIPS, low footprint, high portability, and more!

Stay tuned for the release of wolfSSL's support for providing JSSE! For more information, please contact facts@wolfssl.com.

wolfSSL Zephyr Port

With the recent release of wolfSSL 4.0.0, the wolfSSL embedded SSL/TLS library comes with many new features and improved functionality. Among these features is the addition of a port to the Zephyr Project - a scalable real-time operating system (RTOS) supporting multiple hardware architectures, optimized for resource constrained devices, and built with safety and security in mind.

wolfSSL's Zephyr port comes with multiple test and example applications, such as the wolfCrypt unit tests, wolfSSL TLS with sockets, and wolfSSL TLS with threads example applications. This Zephyr port allows for its users to easily implement lightweight, high-speed and strong encryption for secure data transfer on their devices. As both Zephyr and wolfSSL are targeted for resource-constrained and embedded devices, this combination only makes sense.

More information about the 4.0.0 release of wolfSSL can be found in our blog post here: https://www.wolfssl.com/wolfssl-4-0-0-now-available/

For other information or queries, please contact facts@wolfssl.com.

wolfSSL Support for ESP-IDF and ESP32-WROOM-32

Are you a user of the ESP-IDF(Espressif IoT Development Framework)? If so, you will be happy to know that wolfSSL recently added support and example projects to the wolfSSL embedded SSL/TLS library for ESP-IDF.

ESP-IDF is intended for rapidly developing Internet-of-Things (IoT) applications, with Wi-Fi, Bluetooth, power management and several other system features.

The ESP-IDF “Get Started” document can be found here:


In order to use wolfSSL under ESP-IDF, you need to deploy wolfSSL source files into the IDE. Please see the README.md placed in the “IDE/Espressif/ESP-IDF/” directory of wolfSSL source tree. In addition to that, example projects including TLS server/client, wolfCrypt test and benchmark are also provided. For building these examples, please see each README.md in example projects directories. When working with ESP-IDF, wolfSSL worked with the ESP32-WROOM-32 device.

wolfSSL also has a page that elaborates upon the use of Espressif with wolfSSL and the Espressif hardware devices, located here: https://www.wolfssl.com/docs/espressif/

Our wolfSSL master branch can be cloned here:

The README.md can be found here:

Additional examples for wolfSSL TLS Client/Server and wolfCrypt test/benchmark applications can be found here:

This support is currently located in our GitHub master branch, and will roll into the next stable release of wolfSSL as well. For any questions or help getting wolfSSL up and running on your ESP-IDF environment, please contact us at support@wolfssl.com.

wolfSSL Support for SSL/TLS with Alternative I/O

wolfSSL's embedded SSL/TLS library provides support for many different features, such as TLS 1.3, a FIPS 140-2 validation, and even support for SSL/TLS using less traditional I/O.  In this context, “less traditional I/O” means running SSL/TLS over something besides TCP/IP or UDP - for example Bluetooth, a serial connection, memory buffers, or a proprietary transfer protocol.  In embedded projects, we know it can be common.

The wolfSSL embedded SSL/TLS library provides a mechanism to plug in your own application-specific I/O routines. By default, the library calls a BSD socket API, with functions that call the system’s recv() and send() using a file descriptor that has been cached with wolfSSL_set_fd().

The prototypes for the I/O callback functions are:

    typedef int (*CallbackIORecv)(WOLFSSL *ssl, char *buf, int sz, void *ctx);
    typedef int (*CallbackIOSend)(WOLFSSL *ssl, char *buf, int sz, void *ctx);

In the default case, the network socket file descriptor is passed to the I/O callback through the “ctx” parameter. The “ssl” parameter is a pointer to the current wolfSSL session, giving callbacks access to session-level details if needed.

In the receive case, “buf” points to the buffer where incoming ciphertext should be copied for wolfSSL to decrypt and “sz” is the size of the buffer. Callbacks should copy “sz” bytes into “buf”, or the number of bytes available.  In the send case, “buf” points to the buffer where wolfSSL has written ciphertext to be sent and “sz” is the size of that buffer. Callbacks should send “sz” bytes from “buf” across their transport medium. In either case the number of bytes written or read should be returned, or alternatively an applicable error code.

To register your own I/O callbacks with the wolfSSL Context (WOLFSSL_CTX) for your application, use the functions wolfSSL_SetIORecv() and wolfSSL_SetIOSend().

    wolfSSL_SetIORecv(ctx, myCBIORecv);
    wolfSSL_SetIOSend(ctx, myCBIOSend);

An example use case for alternative I/O would be to have a server with a datagram socket which receives data from multiple clients or processes TLS through STDIN and STDOUT. In this case you would have four buffers:

    cipher-receive     encrypted data received from peer
    cipher-send        encrypted data to send to peer
    clear-receive      clear data received from wolfSSL
    clear-send         clear data passed to wolfSSL

Pointers to these buffers, values for their sizes, and read and write positions might be placed into a user-defined structure. A pointer to this structure could then be cached in the wolfSSL session with the functions wolfSSL_SetIOReadCtx() and wolfSSL_SetIOWriteCtx().

    wolfSSL_SetIOReadCtx(ssl, buffer_data);
    wolfSSL_SetIOWriteCtx(ssl, buffer_data);

The application would receive a block of ciphertext into the buffer “cipher-receive”. Next the application would call wolfSSL_read(ssl, buffer_data->clear_receive), causing wolfSSL to call the registered receive callback. That receive callback will be given a buffer, the size of the buffer, and the ctx, which has the “cipher-receive” buffer. The callback may be called many times internally for one call to wolfSSL_read(). If the “cipher-receive” buffer is empty, the callback should return WOLFSSL_CBIO_ERR_WANT_READ, otherwise it should return the number of bytes copied into “buf”.

When the library wants to send data, during handshaking or when wolfSSL_send() is called with plaintext, the library will call the registered send callback. The callback is given a buffer full of encrypted data, and the length of the encrypted data. In this example, the callback would copy this cipher text into “cipher-send” and return the number of bytes copied. If the “cipher-send” buffer isn’t big enough, the callback should return WOLFSSL_CBIO_ERR_WANT_WRITE.

If you are interested in looking over an example of using the wolfSSL I/O abstraction layer, we have an example client/server application at the following link that does TLS using files as the transport medium: https://github.com/wolfSSL/wolfssl-examples/tree/master/custom-io-callbacks

If you have questions about using wolfSSL’s custom I/O callback layer, please contact us at facts@wolfssl.com.

Posts navigation

1 2 3 4