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.

wolfSSL 5.5.4 Release!

Merry Christmas! The Christmas release of wolfSSL is here, version 5.5.4! This includes some minor feature additions, QUIC related changes for HAProxy use, port to the MAXQ hardware, improvements in performance, as well as additional enhancements and fixes. In this development cycle we also did testing of using wolfSSL with NuttX, and wolfSSL is ready to go for any projects looking for TLS / cryptography with NuttX.

Here are some of the key new features  we added to this new version.

New Feature Additions

  •  QUIC related changes for HAProxy integration and config option
  •  Support for Analog Devices MAXQ1080 and MAXQ1065
  •  Testing and build of wolfSSL with NuttX
  •  New software based entropy gatherer with configure option --enable-entropy-memuse
  •  NXP SE050 feature expansion and fixes, adding in RSA support and conditional compile of AES and CMAC
  •  Support for multi-threaded sniffer

The full list of changes can be found in the bundled with wolfSSL or on the website

Visit our download page or for downloading the bundle. Email us at with any questions.

SSL/TLS Support for NXP SE050 with wolfSSL

The wolfSSL lightweight SSL/TLS library and underlying wolfCrypt cryptography library have included support for the NXP SE050 secure element as of November 2021. Since that time we have been increasing compatibility with SE050 along with usage of SCP03 (Secure Channel Protocol 03) authentication. We recently made a few fixes for usage of the NXP SE050 underneath SSL/TLS within wolfSSL. To help users see how to get started with TLS usage, we have also created two example client applications.

Fixes for SSL/TLS usage of the NXP SE050 have been merged into the wolfSSL master branch as of February 2023, and will be included in the next stable release of wolfSSL.

wolfSSL TLS users can now use the wolfSSL_CTX_use_PrivateKey_Id() API to instruct wolfSSL to use a private key located in the SE050 at a specific key ID. This would replace calls to wolfSSL_CTX_use_PrivateKey_file() or wolfSSL_CTX_use_PrivateKey_buffer(), giving applications enhanced security by allowing the private key to be stored (and optionally generated) inside the SE050.

#include <wolfssl/ssl.h>
int wolfSSL_CTX_use_PrivateKey_Id(WOLFSSL_CTX* ctx, const unsigned char* id, long sz, int devId);

For access to wolfSSL_CTX_use_PrivateKey_Id(), wolfSSL needs to be compiled with WOLF_PRIVATE_KEY_ID defined. This can be passed through configure via CFLAGS, for example:

sudo make install

TLS Client Demos Using SE050

wolfSSL has two new example SSL/TLS client applications that demonstrate how users can leverage SE050 underneath wolfSSL’s SSL/TLS implementation. These examples are set up to be easily run on a Raspberry Pi with attached NXP EdgeLock SE050 Development Kit.

Available examples are included in the “wolfssl-examples” GitHub repository under the SE050 subdirectory and include:

1. wolfSSL SSL/TLS Client Example

This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers. For a more advanced demo which uses the private key directly from the SE050, see the following example. For details, see the example, or wolfssl_client.c.

2. wolfSSL SSL/TLS Client Example with Cert and Private Key in SE050

This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers into the SE050, then does all private key operations inside the SE050 for the TLS private key, based on a key ID. For details, see the example or wolfssl_client_cert_key.c.

Further Resources

For more details on using wolfSSL or wolfCrypt with the NXP SE050, see one of the following links or email us at The wolfSSL embedded SSL/TLS library supports up to the most current TLS 1.3 and DTLS 1.3 protocol standards, has been optimized for performance and footprint size, and also provides easy paths forward for validation and certification requirements (FIPS 140-3, FIPS 140-3 (in progress), CAVP, DO-178C).

Blog: wolfSSL NXP SE050 Support and Benchmarks
Blog: wolfSSL Support for NXP SE050 with SCP03
Documentation: wolfSSL NXP SE050 Support (
Examples: wolfSSL NXP SE050 Examples (
Dev Kits: NXP EdgeLock SE050 Development Kits
SE050 Product Page: EdgeLock SE050: Plug & Trust Secure Element Family

Join us at Fosdem 2023

In a matter of days, hundreds of Open Source developers will gather in Brussels, Belgium for FOSDEM 2023. FOSDEM is a two day event organized by volunteers to promote the widespread use of Open Source software, and is considered by many to be the best open source conference in Europe [1].

wolfSSL will be attending FOSDEM this year, will have a stand in the “H” building, and will  have information about several of wolfSSL’s open source projects including the wolfSSL lightweight SSL/TLS library, wolfCrypt cryptography engine, wolfBoot Secure Boot, and cURL. We’ll have done a lot of exciting work these past few years that we would love to talk about. cURL founder and maintainer Daniel Stenberg as well as members of the wolfSSL team will be on hand to answer developers’ questions first hand. 

If you or your team is considering integrating wolfSSL or cURL with a project you can take a look at our stand schedule and talk to us. Please stop by to talk to these top experts in their field. 

Daniel Stenberg will be available to talk all things cURL. Ask Daniel about cURL security, new protocol support, Post Quantum cURL, Tiny cURL.

Daniele Lacmera, wolfSSL Senior Engineer, is on hand to talk about Secure Bootloaders, Post Quantum ciphers, and everything wolfSSL.  Ask Daniele about his newest book!

February 4th          February 5th

Hours Engineer Hours Engineer
9:00 Daniele 9:00 Daniel S
9:30 Daniele 9:30 Daniel S
10:00 Daniele 10:00 Daniel S
10:30 Daniele 10:30 Daniel S
11:00 Daniele 11:00 Daniel S
11:30 Daniele 11:30 Daniel S
12:00 Daniele 12:00 Daniel S
12:30 Daniele 12:30 Daniel S
13:00 Daniele 13:00 Daniel S
13:30 Daniele 13:30 Daniele
14:00 Daniele 14:00 Daniele
14:30 Daniel S 14:30 Daniele
15:00 Daniel S 15:00 Daniele
15:30 Daniel S 15:30 Daniele
16:00 Daniel S 16:00 Daniele
16:30 Daniel S 16:30 Daniele
17:00 Daniel S 17:00 Daniele
17:30 Daniel S 17:30 Daniele
18:00 Daniel S
18:30 Daniel S
19:00 Daniel S

You can also set up a time to sit down and talk at FOSDEM, let us know at and we can pencil you into our schedule while in Brussels. We enjoy working with Open Source projects, and offer them free support from our technical staff when working with wolfSSL or cURL.


wolfBoot support for the STM32C0

We are adding wolfBoot support for the new STM32C0. This is a low cost MCU similar to the STM32G0 based on a Cortex-M0 (48MHz). It is a very low cost general purpose 32-bit MCU with up to 32KB flash and 12KB RAM.

Our wolfBoot secure bootloader is the only solution available for this platform thanks to our small code size. Most STM32 parts are supported with wolfBoot out of the box. See our video series with ST for a tutorial on using wolfBoot:

See the STM32C0 announcement from ST:

We will be demonstrating this at our booth during Embedded World 2023 in Nuremberg, Germany March 14-16.


  • Written in C for bare-metal use
  • Small footprint to run on small embedded devices
  • Memory safety (no malloc/free)
  • Support for on-board or external SPI flash
  • Simple partitioning and header scheme
  • Abstracted HAL design for CPU speed and flash
  • Bootloader handles swapping and loading of partitions
  • Key tools for key generation/import and signing
  • Encrypted updates
  • Delta updates (only differences)

Signature algorithms supported:

  • ECC (SECP256R1,SECP384R1)
  • RSA (2048/3072/4096)
  • ED25519
  • ED448

Firmware image integrity using hash digest:

  • SHA2-256
  • SHA2-384
  • SHA3-384

Flexible partition scheme determined at build-time:

  • Bootloader (10-30KB)
  • Application
  • Update
  • Swap (1 sector)
  • And custom partition ID's

Reliable Firmware update mechanism:

  • Independent from the update transport mechanism
  • Fallback to a previous version when the update fails
  • Resume interrupted swap operations during update, in case of power failure

Support for STM hardware crypto acceleration:

  • ST33TP* TPM 2.0 using wolfTPM

    If interested in trying our wolfBoot on the STM32C0 or curious about post-quantum signature support in wolfBoot please contact

KEMTLS Experimentation Via wolfSSL

A new, exciting paper has been released by Ruben Gonzalez from Neodyme AG and Thom Wiggers from Radboud University. They compare post-quantum algorithms in TLS 1.3 and KEMTLS.  KEMTLS is a newly proposed modification to the TLS 1.3 protocol that would eliminate the need for signing operations during a handshake protocol.  Note that a long term KEM public key would be embedded into a leaf certificate so the certificate chain would still need to be verified with a signature scheme.  The team did the work of modifying wolfSSL to support KEMTLS in their own fork of wolfSSL. Their paper can be found at .

The paper concludes that KEMTLS would allow for lower memory consumption.  However, there was no clear winner with regards to handshake times.  In some situations, post-quantum TLS 1.3 was faster, while in other cases KEMTLS did better.  If you are curious about it, please do download the paper.

We would like to thank the authors for the following words:

"WolfSSL is designed to be memory efficient and fast on embedded systems. On top, it already supports TLS 1.3 and has a clean implementation of TLS’s state machine. ...WolfSSL’s crypto provider, called WolfCrypt, has a clean API that can be extended easily."

Here at wolfSSL, we appreciate it when our code quality is noticed.

Are you curious about any other protocols? Our wolfSSL library also supports DTLS 1.2 and recently support for DTLS 1.3 was added.  We support SSH, MQTT and SCEP via our wolfSSH, wolfMQTT and wolfSCEP products. If you are curious, don't be shy! The full source code for all of these products are available for download under open source licenses at You can also reach out to us for more details at

wolfEngine 1.3.0 Released

We’re happy to announce that wolfEngine 1.3.0 has been released! wolfEngine is an OpenSSL engine implementation that helps users migrate to a FIPS-validated cryptography library (wolfCrypt) all while continuing to use OpenSSL.

Version 1.3.0 includes support for RPM packaging, support and tests for OpenSSL HMAC operations to be called with a -1 key length, and updated examples which are compatible with OpenSSL 1.0.2. You can read the full list of changes in the on GitHub. For documentation and usage instructions for wolfEngine, visit the wolfEngine User Manual.

If you are interested in a commercial version of wolfEngine or using the wolfCrypt FIPS 140-2 or upcoming 140-3 module in your project, please contact wolfSSL at with any questions or for more details!

Rust Crate for Post-Quantum TLS 1.3 and wolfSSL

Are you on the bleeding edge of software development and cryptographic protocols? Then you'll appreciate the work that our friends at ExpressVPN have done by creating a rust crate for wolfSSL with bindings into our API.  They have even created a special feature flag called "postquantum" which enables our integration with liboqs. In fact, this feature will automatically bring in the oqs-sys rust crate making the whole setup as simple as could be!

For more details and instructions on how to proceed, please see .

Are you interested in more rust bindings?  Are you thinking of using wolfSSL in your rust application? Then we would love to have a conversation with you! Please reach out to us by sending a message to or your local wolfSSL business director.


DTLS 1.3 support for Post-Quantum Cryptography

Do you want to start using wolfSSL’s DTLS 1.3 implementation?   Want to go even further? 

A great reason to start using our DTLS 1.3 stack is that it also supports post-quantum KEMs, Hybrid KEMs and post-quantum signature schemes.  When it comes time to move to post-quantum standards, support for them will likely come in the newest protocol standards only, so you might as well go to DTLS 1.3 as soon as you can and make sure that post-quantum algorithms and artifacts won’t be a challenge for your system. 

Got questions about the DTLS 1.3 or post-quantum cryptography? Don’t be shy! Send a message to or reach out to your local wolfSSL business director. 

wolfSSL: Hardened By Default

In cryptography when we talk about hardening a library, we mean enabling resistance to timing attacks and cache attacks, using RSA blinding and protecting against glitching.

Enabling and Disabling

Our code has many related macros which can be controlled via configure script flags such as the harden flag and maxstrength flag. When hardening is enabled, the following flags are defined:




When it is disabled, the following flags are defined:



NOTE: hardening is enabled by default and in most cases should NOT be disabled. Later in this post, we will discuss some guidance on this matter.

The “maxstrength” flag is disabled by default because it only allows AEAD-PFS (Authenticated Encryption with Associated Data - Perfect Forward Secrecy) cipher suites which can cause interoperability issues. However, when it is enabled, it defines WOLFSSL_CIPHER_TEXT_CHECK, which protects against glitching attacks. If you want other cipher suites to be available, but also want glitching protection for the relevant ciphersuites, you can add -DWOLFSSL_CIPHER_TEXT_CHECK to your CFLAGS environment variable.

Timing Attack

This requires the adversary to precisely time the logical operations performed by a CPU or other device. By measuring these times the adversary is able to uncover the private data that was used to perform these operations. These kinds of attacks are even practical against well known, generally secure algorithms including RSA and ECC. Such  attacks are thwarted by making cryptographic operations run in a constant amount of time independent of the private key. More information on timing attacks can be found at:

Cache Attack

Modern processors perform speculative execution and can leave observable side effects due to execution of branches not taken. This can be in the form of memory access patterns which can be seen in the state of the memory cache. These patterns can indicate information about the private key. The adversary would use nefarious means to make a program access arbitrary locations in the program's memory space to get these patterns.  This attack can be mitigated by eliminating branching in cryptographic operations involving the private key.

RSA Blinding

This involves transforming the input just before the RSA private key operations using some random data. After the operation, the reverse of the transform is performed giving the desired output. This prevents an adversary from gaining knowledge about the private key as they don't know the random data that was used to determine the transform and therefore do not know the true input into the RSA private key operation.


Glitching is when the adversary can feed in modified input data into an algorithm and then observe the error behavior to deduce information about the private key. This requires the adversary to have physical access and intimate knowledge of the software and hardware. They would modify the input into the algorithm by physically changing the values of the input in physical memory. This attack can be detected by copying the input to a separate buffer before a cryptographic operation and comparing the input buffer with that separate buffer after the cryptographic operation to ensure it has not changed.

Disabling Hardening

Generally speaking, you should always leave the “harden” flag enabled, however disabling it can give some performance gains. Here are some factors to consider whether it is appropriate to disable it:

  • Are you only dealing with public data and public keys?
  • Do you really need the performance gains?
  • Are you only doing off-line operations where cryptographic operation timings cannot be observed?
  • Are restrictions in place to ensure no physical access to the hardware?
  • Do you have very simple and audited application code and operating system to minimize nefarious code execution?
  • Did you minimize external interaction (ie network, user interface) to prevent nefarious inputs?
  • Do you sanity check all input data?

If you are still not sure about whether you want to enable hardening, then reach out to your wolfSSL business director or send a message to and let’s start a conversation.

wolfSSL + nuttX initial testing success!

wolfSSL is pleased to announce initial run-time testing of wolfCrypt + NuttX was successfully completed (Crypto algorithm tests and benchmarking) on both BL602 (RISC-V) and NUCLEO-L552ZE-Q (Cortex-M33) targets! wolfSSL engineers are now working on making a publically available drop-in for the NuttX-apps directory that users can take for a spin! The wolfSSL team is very excited about next steps which include but are not limited to:

  • Testing wolfCrypt post-quantum algorithms in NuttX
  • Testing client/server TLS 1.2 and TLS 1.3 connections in NuttX
  • Testing FIPS functionality in NuttX
  • Publishing benchmark results to our website

Console output from tests run on the RISC-V BL602 target:

NuttShell (NSH)

nsh> wolfcrypt_test


 wolfSSL version 5.5.4


error    test passed!

MEMORY   test passed!

base64   test passed!

asn      test passed!

RANDOM   test passed!

MD5      test passed!

SHA      test passed!

SHA-256  test passed!

Hash     test passed!

HMAC-MD5 test passed!

HMAC-SHA test passed!

HMAC-SHA256 test passed!

DES      test passed!

DES3     test passed!

AES      test passed!

AES192   test passed!

AES256   test passed!

RSA      test passed!

DH       test passed!

PWDBASED test passed!

ECC      test passed!

ECC buffer test passed!

logging  test passed!

time test passed!

mutex    test passed!

memcb    test passed!

Test complete

Exiting main with return code: 0

Have any other ideas or Proof of Concepts you would like us to consider? Please don’t hesitate to reach out to with suggestions for our team!


“Get Up to Speed with WolfSSL in 2023: Join Our Webinar Series”

Happy New Year! As we kick off 2023, wolfSSL is excited to announce a series of webinars to help you get started with our software.

First up is our webinar on January 5th at 10 AM (PST) on getting started with the wolfSSL TLS library. This webinar will cover a range of topics including an overview of TLS 1.3, how to build and use the wolfSSL library, and tips on debugging. There will also be a Q&A session to answer any questions you may have. Register here:

On January 19th, join wolfSSL engineer Eric Blankenhorn for a webinar on our wolfMQTT library. This multi-platform, space-conscious and extensible library is a client implementation of MQTT written in C for embedded use, and supports SSL/TLS via the wolfSSL library. Bring your questions for the Q&A session to follow. Register here:

Finally, on January 26th, we’ll be hosting a webinar on getting started with wolfSSH, a lightweight SSHv2 client and server library. This webinar will cover topics such as the wolfSSH package structure, how to build and use the library, and debugging tips. As always, there will be a Q&A session to answer any questions you may have. Register here:

We hope to see you at one or all of these webinars!

Posts navigation

1 2 3 4 159 160 161

Weekly updates


Latest Tweets