RECENT BLOG NEWS

wolfSSL will be releasing wolfCrypt v4.0 FIPS with an expanded security boundary. We have added many algorithms to the boundary. We have also tested the code using AES-NI with Linux and Windows 10.

Intel added a set of instructions for accelerating AES processing including performing AES-GCM’s GHASH. Also available are accelerations to SHA-1, SHA-2, and SHA-3 hashing using the AVX instruction sets. Our implementations use algorithmically generated accelerated assembly code to get the job done fast.

For more information about wolfCrypt v4.0 FIPS, please send a message to fips@wolfssl.com. For more information about wolfSSL in general, including TLSv1.3 support, send a message to facts@wolfssl.com.

wolfSSL will be releasing wolfCrypt v4.0 FIPS with an expanded security boundary. We have added many algorithms to the boundary, including Key Generation.

wolfCrypt v4.0 FIPS can generate keys for use with RSA and ECDSA signing. It can also do the perform the ECDHE and DHE key agreement schemes. We have also self-affirmed wolfCrypt for HKDF as a key-derivation function.

To use wolfCrypt key generation in a FIPS approved manner, you must build wolfCrypt with the Intel RDSEED feature enabled. If you do not have RDSEED available, you may use your own seeding method but it must meet the NIST SP 800-90B requirements.

For more information about wolfCrypt v4.0 FIPS, please send a message to fips@wolfssl.com. For more information about wolfSSL in general, including TLSv1.3 support, send a message to facts@wolfssl.com.

We have been hard at work adding server support for SCP to wolfSSH and it will be available in the next release of wolfSSH, version 1.3.0.

If you have an embedded device and want to securely upload a new firmware image to it or download a log file with the convenience of a copy command, wolfSSH has you covered. Our server API keeps it simple to receive or send files when a client connects using ciphers found in our lightweight crypto library, wolfCrypt.

If you are interested in FIPS, wolfSSH compiles against wolfCrypt and can use the wolfCrypt FIPS library. For more information about FIPS, contact fips@wolfssl.com and we can discuss your requirements and FIPS testing.

For more information about wolfSSH please contact facts@wolfssl.com.

wolfSSL is proud to announce release v3.15.0 of our wolfSSL embedded TLS library. Among the many additions are:

• Support for wolfCrypt FIPS on SGX
• Support for TLS 1.3 Draft versions
• Single Precision assembly code added for ARM and 64-bit ARM to enhance performance
• Improved performance for Single Precision maths on 32-bit
• Expanded OpenSSL compatibility layer

We have added Intel SGX as an operating environment for our wolfCrypt FIPS library. You can take advantage of running the wolfCrypt code in a secure enclave. For more information, contact fips@wolfssl.com.

With the finalization of TLS 1.3 on the horizon, we add incremental support for the drafts of the protocol. wolfSSL is current through draft 28 of the specification.

We are committed to supporting TLS 1.3 on embedded platforms, and we want to squeeze the most performance out of the chips for public key algorithms. After great success with the Intel assembly performance increases, we have added ARM assembly single-precision math support for RSA, ECC, and DHE.

To make porting existing projects over to wolfSSL, we have our OpenSSL compatibility layer. We are always expanding it. This release includes a large set of APIs to our support.

For more information, please contact facts@wolfssl.com. You can see the full change log in the source archive from our website at www.wolfssl.com or at our GitHub repository.

wolfSSL is pleased to announce the following addition to the wolfSSL FIPS certificate!

The wolfCrypt FIPS validated cryptographic module has been validated while running inside an Intel SGX enclave and examples have been setup for both Linux and Windows environments.

Intel ® SGX (Software Guard Extensions) can be thought of as a black-box where no other application running on the same device can see inside regardless of privilege. From a security standpoint this means that even if a malicious actor were to gain complete control of a system including root privileges, that actor, no matter what they tried, would not be able to access data inside of this “black-box”.

An Intel enclave is a form of user-level Trusted Execution Environment (TEE) which can provide both storage and execution. Meaning one can store sensitive information inside and also move sensitive portions of a program or an entire application inside.

While testing, wolfSSL has placed both individual functions and entire applications inside the enclave. One of the wolfSSL examples shows a client inside the enclave with the only entry/exit points being “start_client”, “read”, and “write”. The client is pre-programmed with a peer to connect with and specific functionality. When “start_client” is invoked it connects to the peer using SSL/TLS and executes the pre-programmed tasks where the only data entering and leaving the enclave is the info being sent to and received from the peer. Other examples show placing a single cryptographic operation inside the enclave, passing in plain-text data and receiving back encrypted data masking execution of the cryptographic operations.

If you are working with SGX and need FIPS validated crypto running in an enclave contact us at fips@wolfssl.com or support@wolfssl.com with any questions. We would love the opportunity to field your questions and hear about your project!

Resources:
https://software.intel.com/en-us/blogs/2016/12/20/overview-of-an-intel-software-guard-extensions-enclave-life-cycle

The performance of TLS 1.3 using wolfSSL has recently been discussed here in the blogs. While checking our performance a comparison was made with OpenSSL. An OpenSSL server using the latest TLS 1.3 implementation at the time was used with the wolfSSL client. The numbers showed that the recent Intel x86 64-bit assembly optimizations have been worth it.

Firstly, the performance of PSK without key exchange is mostly dependent on the speed of the hash algorithm. The results showed that the small block performance of SHA-256 in wolfSSL was the difference. On the platform tested, wolfSSL is about 22% faster than OpenSSL at hashing 256 bytes. The performance of wolfSSL in PSK non-KE handshakes was about 19% better than that of OpenSSL. The improved hashing performance partially helped other results.

The performance of other TLS 1.3 handshakes is dominated by the public key operations. Note that OpenSSL did not negotiate DH with TLS 1.3 in the version tested. When using PSK with a key exchange the public key operations the server performs are: ECDH key generation and secret calculation. While these operations in wolfSSL are only around 7% faster than OpenSSL on the platform the overall handshake performance was about 36% better. The overheads around performing the cryptographic operations in OpenSSL and slower hashing during the handshake made up the difference.

When using RSA certificates for server authentication, the cost of signing outweighs any other operation. On the platform RSA signing is about the same speed in wolfSSL as OpenSSL. The overall handshake speed was 10-15% better than OpenSSL due to overheads and hashing.

P-256 operations are faster in wolfSSL than OpenSSL and the overheads and hashing difference once again impacted the results. The server is performing key generation, secret generation, and signing operations. wolfSSL is 7-13% faster at performing these operations with P-256 on the platform and about 3% faster performing X25519 operations. wolfSSL was seen to be 35-40% faster than OpenSSL when using P-256 and 20-30% faster when Curve25519 is used for key exchange. When client authentication was also performed, similar improvements were seen.

Performance increases like 35-40% are real reasons to use wolfSSL rather than OpenSSL for TLS 1.3 and especially on Intel x86 64-bit.

If you would like more information about using wolfSSL in your project, email us at facts@wolfssl.com.

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)

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)