Category: Uncategorized

We have released an update to our asynchronous version of wolfSSL v3.14.4.

Using our wolfSSL asynchronous library with hardware acceleration increases performance on server platforms requiring high connection rates and throughput. We support hardware acceleration using the Intel QuickAssist and Cavium Nitrox III/V adapters. We also support crypto offloading to dedicated asynchronous worker threads using our simulator.

This release includes fixes and features including:

Cavium Nitrox III/V:
* Added Nitrox V ECC.
* Added Nitrox V SHA-224 and SHA-3
* Added Nitrox V AES-GCM
* Added Nitrox III SHA2 384/512 support for HMAC.
* Added error code handling for signature check failure.
* Added error translate for `ERR_PKCS_DECRYPT_INCORRECT`
* Added useful `WOLFSSL_NITROX_DEBUG` and show count for pending checks.
* Cleanup of Nitrox symmetric processing to use single while loops.
* Cleanup to only include some headers in cavium_nitrox.c port.
* Fixes for building against Nitrox III and V SDK.
* Updates to README.md with required CFLAGS/LDFLAGS when building without ./configure.

Intel QuickAssist:
* Fix for Intel QuickAssist HMAC to use software for unsupported hash algorithms.

If interested in evaluating our asynchronous versions of wolfSSL or wolfCrypt please email us at facts@wolfssl.com.  wolfSSL also now includes support for TLS 1.3!  Learn more here!

Download wolfSSL’s Asynchronous Flyer

wolfSSL is a growing company looking to add a top notch embedded systems software engineer to our organization. wolfSSL develops, markets and sells the leading Open Source embedded SSL/TLS protocol implementation, wolfSSL. Our users are primarily building devices or applications that need security. Other products include wolfCrypt embedded cryptography engine, wolfMQTT client library, and wolfSSH.

Job Description:

Currently, we are seeking to add a senior level C software engineer with 5-10 years experience interested in a fun company with tremendous upside. Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.  Experience with hardware-based cryptography is a plus.

Operating environments of particular interest to us include Linux, Windows, Embedded Linux and RTOS varieties (VxWorks, QNX, ThreadX, uC/OS, MQX, FreeRTOS, etc). Experience with mobile environments such as Android and iOS is also a plus, but not required.

Location is flexible. For the right candidate, we’re open to this individual working from virtually any location.

How To Apply

To apply or discuss, please send your resume and cover letter to facts@wolfssl.com.

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)