RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

TLS 1.3 combined with FIPS (#FIPS #TLS13)

For 2018, it's predicted that there will be more than 31 billion connectable IoT devices across the world. To put that number into perspective, imagine if every square mile on the Earth's surface was monitored by more than 150 IoT devices each. If this were square kilometers, there would be more than 60 IoT devices per square kilometer. With 31 billion devices potentially contributing to global internet traffic, this reveals a glaring need for an efficient and powerful way to secure data - and wolfSSL is the perfect solution.

wolfSSL is a lightweight TLS/SSL library that is targeted for embedded devices and systems. It has support for the most recent draft of the TLS 1.3 protocol, which is a secure protocol for transporting data between devices and across the internet. In addition, wolfSSL uses the wolfCrypt encryption library to handle its data encryption. Because there is a FIPS 140-2 validated version of wolfCrypt, this means that wolfSSL not only has support for the most current version of TLS, but it also has the encryption backbone to secure your data. FIPS 140-2 is a government certification that certifies that an encryption module has successfully passed rigorous testing and meets high encryption standards as specified by NIST.

Currently, wolfSSL is the only implementation of the TLS protocol that can support both the most recent version of TLS 1.3 and is FIPS 140-2 validated.

Some key benefits of combining TLS 1.3 with FIPS validated software include:

  1. Software becomes marketable to federal agencies - without FIPS, a federal agency is not able to use cryptographic-based software
  2. Single round trip
  3. 0-RTT (a mode that enable zero round trip time)
  4. After Server Hello, all handshake messages are encrypted.

And much more! For more information regarding the benefits of using TLS 1.3 or using the FIPS validated version of wolfCrypt, check out wolfSSL's TLS 1.3 Protocol Support and our wolfCrypt FIPS page.

For more details about wolfSSL, TLS 1.3, or if you have any other general inquiries please contact facts@wolfssl.com
To find out more about FIPS, check out the NIST FIPS publications or contact fips@wolfssl.com

wolfMQTT IBM Recipe

wolfMQTT is an MQTT client that has the capability to connect to the IBM Watson IoT cloud platform broker. This is useful as IBM's cloud platform allows users to potentially offload large amounts of data and/or computation to the cloud that is provided.

wolfMQTT comes ready with an example application titled "wiot" that shows users one way to communicate with the IBM Watson IoT broker. To use this example, all that needs to be done is to build the wolfMQTT library and then execute the wiot example.

An IBM Recipe that shows the process can be viewed here.

You can download the latest release from our website or clone on GitHub. For more information please email us at facts@wolfssl.com.

wolfSSL Intel SGX (#SGX) + FIPS 140-2 (#FIPS140)!

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

Debian 8.7.0 Intel ® Xeon® E3 Family with SGX support Intel®x64 Server System R1304SP
Windows 10 Pro Intel ® Core TM i5 with SGX support Dell LatitudeTM 7480

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

wolfSSL Performance on Intel x86_64 (Part 6)

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 the last part. In this blog, we will talk about the performance of Elliptic Curve (EC) operations over the P-256 curve.

Elliptic curve cryptography (ECC) is the alternative to finite field (FF) cryptography which has algorithms like RSA, DSA and DH. ECDSA is the elliptic curve variant of RSA and DSA while ECDH is the elliptic curve variant of DH. ECDSA and ECDH can be used anywhere their FF counterparts can be used. ECC requires a pre-defined curve to perform the operations on. The most commonly used curve is P-256 as it has 128-bit strength and is in many standards including TLS, for certificates in IETF, and NIST’s FIPS 186-4. Browsers and web servers are preferring ECDH over DH as it is much faster.

wolfSSL 3.13 and later have completely new implementations of the EC algorithms over the P-256 curve. 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. There is a small code size variant of the assembly code that is about 1/3rd the size (smaller pre-computed tables) yet remains very fast.

The two charts below show the relative performance of the old wolfSSL code, new small wolfSSL assembly code, new fast 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 the ECDH key generation operation. The new C implementation is a lot faster than the old generic C/ASM code for both CPUs. The assembly code is many times better than the C code mostly due to the use of larger pre-computed tables of elliptic curve points. The OpenSSL code is around 10% slower than the new fast wolfSSL assembly code using the generic x86_64 code and between 5% and 35% slower than wolfSSL assembly code for x86_64 with BMI2 and ADX instructions.

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

P-256_x86_64P-256_BMI2_ADX

References:

ECDSA (Elliptic Curve Digital Signature Algorithm)
ECDH (Elliptic-curve Diffie–Hellman)

wolfSSL Embedded SSL for Bare Metal and No OS Environments

Are you looking for an SSL/TLS library which will seamlessly integrate into your bare metal or No-OS environment? If so, continue reading to learn why the wolfSSL lightweight SSL library is a perfect fit for such environments.

wolfSSL has been designed with portability and ease of use in mind, allowing developers to easily integrate it into a bare metal or operating systemless environment. As a large percentage of wolfSSL users are running the library on small, embedded devices, we have added several abstraction layers which make tying wolfSSL into these types of environments an easy task.

Available abstraction layers include:

  • Custom Input/Output
  • Standard C library / Memory
  • File system (Able to use cert/key buffers instead)
  • Threading
  • Operating System

In addition to abstraction layers, we have tried to keep wolfSSL’s memory usage as low as possible. Build sizes for a complete SSL/TLS stack range from 20-100kB depending on build options, with RAM usage between 1-36kB per connection.

To learn more about how to integrate wolfSSL into your environment or get more information about reducing wolfSSL’s memory usage, please see the wolfSSL Manual or contact us directly.

wolfSSL FAQ page

The wolfSSL FAQ page can be useful for information or general questions that need need answers immediately. It covers some of the most common questions that the support team receives, along with the support team's responses. It's a great resource for questions about wolfSSL, embedded TLS, and for solutions to problems getting started with wolfSSL.

To view this page for yourself, please follow this link here.

Here is a sample list of 5 questions that the FAQ page covers:

  1. How do I build wolfSSL on ... (*NIX, Windows, Embedded device) ?
  2. How do I manage the build configuration of wolfSSL?
  3. How much Flash/RAM does wolfSSL use?
  4. How do I extract a public key from a X.509 certificate?
  5. Is it possible to use no dynamic memory with wolfSSL and/or wolfCrypt?

Have a  question that isn't on the FAQ? Feel free to email us at support@wolfssl.com.

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)

Posts navigation

1 2 3 109 110 111 112 113 114 115 184 185 186

Weekly updates

Archives