Category: Uncategorized

wolfSSL recently exhibited at Embedded World in Germany, where we did a quick video interview with ST.  The video highlights the STM32 platform support we have in the wolfSSL embedded TLS library and the demo that we were showing off during the exhibition.  wolfSSL engineer David Garske talks about wolfSSL’s hardware crypto support on the STM32F7 as demonstrated by a wolfCrypt benchmark demo.  Watch our interview on YouTube, here:

The demo mentioned in the video is available on GitHub, here.

If you are interested in securing your STM32-based IoT, RTOS, or embedded project with wolfSSL, contact us at facts@wolfssl.com for some tips!  wolfSSL also supports TLS 1.3!

The wolfSSL blog now has a new feature that allows individuals to subscribe to weekly updates. Users can add their email to the subscription list, and upon verifying their emails, they will receive a weekly update on Mondays at 9am MDT of the latest updates to the wolfSSL blog. This allows users to keep up to speed on the wolfSSL embedded TLS library, TLS 1.3, FIPS, hardware crypto, performance optimization, and more!

To view this feature and try it out for yourself, visit the wolfSSL blog today!

wolfSSL is committed to leveraging Continuous Integration in the design, delivery, and evaluation of our software – where development and testing are an ongoing process. As such, wolfSSL continues to make improvements to the quality of its testing throughout the software life-cycle to meet the needs of embedded IoT devices. Release 3.14.0 adds expanded unit testing for the following algorithms:

• Ed25519,
• Elliptic Curve Cryptography (ECC),
• AES CMAC,
• SHA 3, and
• RSA-PSS.

The addition of roughly fifty unit test functions increases our test coverage in the wolfSSL embedded TLS library. Unit testing along with the wolfCrypt testing functions provide both white and black box testing methodology in an effort to increase the security of the software. wolfSSL strives to be the most thoroughly tested SSL/TLS library available. Our testing process is intended to rigorously examine the execution paths of our software as well as test the correctness of the algorithms implemented.

For a more comprehensive view into our testing process, feel free to read our previous blog post on the different types of testing we do at wolfSSL! And, as always, please contact us at facts@wolfssl.com with any questions.

wolfSSL recently expanded our PKCS#7 support in the wolfSSL embedded TLS library with the addition of:

• Functional parsing of multiple certificates in SignedData types
• Support for parsing SignedData degenerate types
• A getter function for retrieving bundle attributes
• Internal BER to DER translation
• A public API for PKCS#7 type padding

Expanding on the feature list above, our PKCS#7 certificate handling prior to wolfSSL 3.14.0 parsed only the first certificate in the chain when a SignedData bundle contained multiple certificates. As of 3.14.0, wolfSSL is now able to parse multiple certificates.

The pad function, wc_PKCS7_PadData(), adds pad bytes to the input data and operates on a particular block size.

In wolfSSL 3.14.0, we added a translation function for internally converting from BER ASN.1 encoding to DER encoding for interoperability, as well as adding a getter function (wc_PKCS7_GetAttributeValue()) to return data attribute values.

Lastly, support for PKCS#7 degenerate SignedData types, where there are no signers on the content was added. The degenerate case provides means for disseminating certificates and certificate-revocation lists, as defined in RFC 2315. These additions to wolfSSL’s PKCS#7 support further strengthen the security for IoT devices requiring TLS functionality.

We are proud to announce that wolfSSL’s static memory feature with FreeRTOS received an update in our latest 3.14.0 release. This feature allows for memory allocation to stack memory instead of using the heap. In previous versions of the wolfSSL embedded TLS library, the library would not compile when trying to use FreeRTOS and static memory. With this update, when FREERTOS is defined, the static memory feature uses pvPortMalloc() instead of malloc() when WOLFSSL_NO_MALLOC is not defined and a heap hint is not used.

With this new behavior when handling memory allocation in an RTOS environment wolfSSL now supports using only stack where supported.

For more information about building wolfSSL on embedded, IoT, and/or RTOS environments with static memory enabled please visit our static buffer allocation documentation page.

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.

References:

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

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!

References:

RSA (Wikipedia)
Diffie-Hellman (Wikipedia)

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.

References:

Curve25519: high-speed elliptic-curve cryptography
Ed25519

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.

References:

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