Month: June 2018

Case Study: wolfSSL Enables Sensolus to Easily Secure Communications Between Embedded Systems and the Cloud

Based out of Belgium, Sensolus enables companies to more effectively secure and manage their non-powered assets by providing internet-based tracking solutions over a low-powered, wide-area network. STICKNTRACK, Sensolus's flagship product, lets users easily view an asset's statistics such as current location, temperature, and recent activity in a user friendly way on a map or in dashboards.

In order to ensure the encryption of data from the STICKNTRACK devices to the platform, Sensolus found wolfSSL's wolfCrypt crypto library to be the optimal solution. With it's lightweight design and the inclusion of some of the latest ciphers, wolfCrypt was seamlessly integtrated into Sensolus's products to provide users with a safe and secure communication channel to manage all of their assets.

The wolfSSL/Sensolus case study can be viewed on our case studies page along with various other case studies that we have also conducted.

To learn more about Sensolus and their products, feel free to visit their website or contact them at info@sensolus.com.
For questions regarding the use of wolfSSL products in your embedded or IoT devices, please contact us at facts@wolfssl.com.

TLS 1.3 is now available in wolfSSL's embedded SSL/TLS library! Learn more here and don't forget to check out our product page.

wolfSSL Performance on Intel x86_64 (Part 5)

Recent releases of wolfSSL have included new assembly code targeted at the Intel x86_64 platform. Large performance gains have been made and are being discussed over six blog posts of which this is part 5. In this blog, we will talk about the performance of RSA and Diffie-Hellman (DH).

RSA is the most commonly used public key algorithm for certificates. When performing a TLS handshake, the server will sign a hash of the messages seen so far and the client will verify the signature of certificates in the certificate chain and verify the hash of messages with the public key in the certificate. Signing and verifying are the most time-consuming operations in a handshake.

DH has been the key exchange algorithm of choice in handshakes but is falling out of favor as the Elliptic Curve variants are considerably faster at the same security level. Performing the key exchange is the second most time-consuming operation in a TLS handshake.

wolfSSL 3.13 and later have completely new implementations of RSA and DH targeted at specific key sizes: 2048 and 3072 bits. The implementation is constant-time with respect to private key operations. The implementations include variants in C and assembly code targeted at Intel x86_64 and x86_64 with BMI2 and ADX. The new code is significantly better than the old generic code and is about the same speed as OpenSSL on older CPUs and a little faster on newer CPUs.

The two charts below show the relative performance of the old wolfSSL code, new wolfSSL assembly code and OpenSSL as compared to the new wolfSSL C implementation on Ivy Bridge and Skylake CPUs. Note that the OpenSSL super-app does not measure the speed of DH operations. The new C implementation is a lot faster than the old generic C/ASM code for both CPUs. The assembly code for x86_64 is better than the C code by between 23% and 46% on x86_64 and 92% and 144% using BMI2 and ADX instructions. The OpenSSL code is about the same speed as the wolfSSL assembly code.

Contact us at support@wolfssl.com for questions about the performance of the wolfSSL embedded TLS library, using it on your platform, our about our TLS 1.3 support!

RSA_DH_x86_64RSA_DH_BMI2_ADX

References:

RSA (Wikipedia)
Diffie-Hellman (Wikipedia)

wolfSSL Performance on Intel x86_64 (Part 4)

Recent releases of wolfSSL have included new assembly code targeted at the Intel x86_64 platform. Large performance gains have been made and are being discussed over six blog posts of which this is part 4. In this blog, we will talk about the performance of Curve25519 and Ed25519.

Curve25519 is set of parameters for a Montgomery elliptic curve and has ~128-bit security. It is used in key exchange and has become popular due to its speed and inclusion in standards. The algorithm is included as part of TLS v1.3 and NIST is considering it as part of SP 800-186. Ed25519 is set of parameters for a Twisted Edwards curve and is mathematically related to Curve25519 and has the same security properties. A new signature scheme has been designed over Twisted Edwards curves that is fast and included as part of TLS v1.3. A draft specification has been written describing digital certificates using EdDSA with Ed25519.

In a TLS handshake, a key exchange operation should always be performed to ensure forward-secrecy. When used, it will be a significant amount of the processing time during the handshake. Improving the performance of Curve25519, therefore, increases the number of TLS connections that can be made per second.

Older releases of wolfSSL have a C implementation of the algorithms. While the C code was quite fast, the new assembly code is significantly better. There is assembly code for generic Intel x86_64 CPUs, and for CPUs with BMI2 and ADX (Broadwell and newer CPUs).

The two charts below show the relative performance of wolfSSL and OpenSSL compared to the C implementation on Ivy Bridge and Skylake CPUs. On the Ivy Bridge CPU, the new assembly code is between 20% and 60% better than the C code and is better than OpenSSL in the one operation that can be measured. On the Skylake CPU, the assembly code is between 60% and 86% faster. The OpenSSL code has not been optimized for this CPU and is significantly slower.

Contact us at support@wolfssl.com with questions about the performance of the wolfSSL embedded TLS library.

Curve25519_Ed25519_Intel_x86_64Curve25519_Ed25519_Intel_BMI2_ADX

References:

Curve25519: high-speed elliptic-curve cryptography
Ed25519

wolfSSL Performance on Intel x86_64 (Part 3)

Recent releases of wolfSSL have included new assembly code targeted at the Intel x86_64 platform. Large performance gains have been made and are being discussed over six blog posts of which this is part 3. In this blog, we will talk about the performance of SHA-256 and SHA-512.

The most commonly used digest algorithms are SHA-256 and SHA-384. With the introduction of AES-GCM in TLS, SHA-256 and SHA-384 are less commonly used for application data authentication. But, they are still used for handshake message authentication, as a one-way function (as required in a pseudo-random number generator) and digital signatures.

The assembly code has been rewritten to take best advantage of the AVX1 and AVX2 instructions. The performance of SHA-256 and SHA-512 is now as good or better than OpenSSL. The four charts below show the performance of wolfSSL has significantly improved from small up to big block sizes. On AVX1, the performance has increased by between 19% and 60% for SHA-256 and between 25% and 53%. Similarly, on AVX2, the improvement has increased by between 22% and 40% for SHA-256 and between 23% and 37% for SHA-512. The new wolfSSL assembly code is also significantly better than OpenSSL for small blocks and is about the same at the largest block size. SHA-384 uses the same algorithm as SHA-512 and therefore has the same underlying implementation and thus the same performance improvements.

Please contact us at support@wolfssl.com with any questions about the performance of the wolfSSL embedded TLS library.

SHA-256-AVX1 SHA-256-AVX2-BMI2 SHA-512-AVX1 SHA-512-AVX2-BMI2

References:

Introduction to Intel® Advanced Vector Extensions
Advanced Vector Extensions (Wikipedia)

How do I manage the build configuration of wolfSSL?

The MOST common support issue we see is a mis-configuration between APP and Library. If you compile the wolfSSL library independant of your application using you MUST include the same configure options in the application as were used in the library.

If building with “./configure” the build system will generate the file <wolf-root>/wolfssl/options.h with all the settings needed for your application. Simply add the lines:

#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/settings.h>
#include <wolfssl/ssl.h>
/* other wolf headers below */

If building the wolfSSL sources directly the options.h will not contain any generated configuration. In that case our recommended option is to define the preprocessor macro “WOLFSSL_USER_SETTINGS” in your project and create your own “user_settings.h” file. Make sure the file is somewhere in your include path. You can use the same include pattern above, but exclude the options.h.

Here are some example “user_settings.h” you can use for reference:

  • Windows: /IDE/WIN/user_settings.h
  • GCC ARM: /IDE/GCC-ARM/Header/user_settings.h
  • NXP ARM: /IDE/ROWLEY-CROSSWORKS-ARM/user_settings.h
  • Xcode: /IDE/XCODE/user_settings.h

More information on managing the build configuration of wolfSSL can be found in Chapter 2 of the wolfSSL User Manual. For other questions that may not have been answered by this post, please check out our Frequently Asked Questions (FAQ) page or contact us.

wolfSSL Contributor Stickers!

wolfSSL Contributor Stickers

Are you a code contributor to the wolfSSL embedded SSL/TLS library, or one of wolfSSL’s other projects?  If so, and you are interested in receiving some wolfSSL Contributor stickers, email us at facts@wolfssl.com with a quick mention of your contribution and we will mail you some free stickers!

wolfSSL products are Open Source and dual licensed under both GPLv2 and commercial licenses.  We are big fans of Open Source software and enjoy seeing the fun things people have used wolfSSL projects in.  We give free support to Open Source projects, and maintain a Community page with links to some of the projects that currently use wolfSSL.

If you have done something cool with wolfSSL, or ported us into your favorite project, we’ll be happy to add you to our Community page.  Just let us know about your project and send us a link!  Using wolfSSL you can easily add in secure, well-tested, and progressive SSL/TLS and crypto to your project.  If you are currently using OpenSSL, we even have an OpenSSL compatibility layer to make the transition easier!

wolfSSL Performance on Intel x86_64 (Part 2)

Recent releases of wolfSSL have included new assembly code targeted at the Intel x86_64 platform. Large performance gains have been made and are being discussed over six blog posts of which this is part 2. In this blog, we will talk about the performance of ChaCha20-Poly1305.

ChaCha20-Poly1305 is a relatively new authenticated encryption algorithm. It was designed as an alternative to AES-GCM. The algorithm is simple and fast on CPUs that do not have hardware acceleration for AES and GCM.

Older releases of wolfSSL did not have assembly code implementations of ChaCh20 or Poly1305. So, adding assembly code that uses AVX1 and AVX2 instructions has made a significant difference. The two charts below show the performance of wolfSSL with respect to OpenSSL on AVX1 and AVX2 chipsets. In both charts, the new assembly code is a clear improvement over the C code. Compared to OpenSSL, wolfSSL is between 2.5% and 23% faster on AVX1 and on AVX2 they are the same speed to wolfSSL being 16% faster!

If you have questions about the performance of the wolfSSL embedded TLS library, please contact us at support@wolfssl.com!

ChaCha-Poly1305 - AVX1

ChaCha-Poly1305 - AVX2

References:

ChaCha Stream Cipher
Poly1305 (Wikipedia)

wolfSSL Performance on Intel x86_64 (Part 1)

Recent releases of wolfSSL have included new assembly code targeted at the Intel x86_64 platform. Large performance gains have been made which are being discussed over a six blog post series. In this first blog, we will talk about the performance of AES-GCM.

The assembly code for AES-GCM has been rewritten to take best advantage of the AVX1 and AVX2 instructions. The performance of AES-GCM is now as good or better than OpenSSL.

The two charts below show the relative performance of AES-128-GCM encryption on an Intel AVX1 and AVX2 chipsets. They compare the performance of wolfSSL and OpenSSL with an older version of wolfSSL (before the assembly code changes).

Small block size performance is important when dealing with locally stored data like keys or data in a database. Meanwhile, large block size performance is important for large data transfers in TLS.

The performance of wolfSSL has significantly improved from small up to big block sizes. On AVX1, the smallest block size performance has increased by over 130% and at the top end, there is a 42% improvement. Similarly, on AVX2, the improvement is over 150% for small block sizes to 11% for large block sizes. The new wolfSSL assembly code is also significantly better than OpenSSL for small blocks and is about the same at the largest block size. Similar performance improvements have been achieved for AES-256-GCM as well.

AES-128-GCM Enc - AVX1 AES-128-GCM Enc - AVX2 (with RORX)

If you have questions about using the wolfSSL embedded TLS library on your platform, or about performance optimization of the library, contact us at support@wolfssl.com.

References:

Introduction to Intel® Advanced Vector Extensions
Advanced Vector Extensions (Wikipedia)

wolfSSL 3.15.3 Now Available

wolfSSL is proud to announce release version 3.15.3 of the wolfSSL embedded TLS library.  This release contains bug fixes and new features, which include:

  • ECDSA blinding added for hardening against side channel attacks
  • Fix for OpenSSL compatibility layer build with no server (NO_WOLFSSL_SERVER) and no client (NO_WOLFSSL_CLIENT) defined
  • Intel assembly instructions support for compatible AMD processors
  • wolfCrypt port for Mentor Graphics Nucleus RTOS
  • Fix added for MatchDomainName() with additional tests added
  • Fixes for building with ‘WOLFSSL_ATECC508A’ defined
  • Fix for verifying a PKCS7 files in BER format with indefinite size

This release of wolfSSL fixes 2 security vulnerability fixes:

Medium level fix for PRIME + PROBE attack combined with a variant of Lucky 13.  Constant time hardening was done to avoid potential cache-based side channel attacks when verifying the MAC on a TLS packet. CBC cipher suites are susceptible on systems where an attacker could gain access and run a parallel program for inspecting caching. Only wolfSSL users that are using TLS/DTLS CBC cipher suites need to update. Users that have only AEAD and stream cipher suites set, or have built with WOLFSSL_MAX_STRENGTH (--enable-maxstrength), are not vulnerable. Thanks to Eyal Ronen, Kenny Paterson, and Adi Shamir for the report.

Medium level fix for a ECDSA side channel attack. wolfSSL is one of over a dozen vendors mentioned in the recent Technical Advisory “ROHNP” by author Ryan Keegan. Only wolfSSL users with long term ECDSA private keys using our fastmath or normal math libraries on systems where attackers can get access to the machine using the ECDSA key need to update. An attacker gaining access to the system could mount a memory cache side channel attack that could recover the key within a few thousand signatures. wolfSSL users that are not using ECDSA private keys, that are using the single precision math library, or that are using ECDSA offloading do not need to update. (blog with more information: https://www.wolfssl.com/wolfssl-and-rohnp/)

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 in stunnel TLS Proxy

Since version 3.6.6, wolfSSL has had continually improving support for stunnel, a lightweight TLS proxy, designed to add SSL/TLS encryption to unsecured applications without changes to the program`s source code. Licensed under GNU GPLv2 and with an alternative commercial option, stunnel can be utilized to secure a host of different applications, including: mail exchange (SMTP, IMAP, POP3), web hosting (HTTP), remote shell, and virtually any other unprotected protocol desired.

Porting stunnel to use wolfSSL`s embedded SSL/TLS library means taking advantage of wolfSSL`s minimal footprint and high speed crypto implementation to increase performance and decrease required resources when compared to the previous SSL library. Not only that, but using wolfSSL with stunnel combines these benefits with the peace of mind that your application is secured by a progressive, transparent and stable SSL/TLS library, known for its quality, integrity and efficiency.

To build wolfSSL for use with stunnel, simply configure wolfSSL with: 

$ ./configure --enable-stunnel

from wolfSSL`s main directory, then make and make install.

For a version of stunnel that links to the wolfSSL library, or for more information, contact us at facts@wolfssl.com.

Posts navigation

1 2 3