ST and wolfBoot Video Series

We are excited to tell you about our partner collaboration with STMicroelectronics! This collaboration is a video series about wolfBoot, a secure bootloader and the STM32, a family of 32-bit microcontrollers.

This will be at least a 4 part video series with the first two already up and ready and the next two videos already planned

Video 1: wolfBoot for STM32, Part 1: Overview

  • Overview of the wolfSSL products and the wolfBoot support for STM32 devices. The wolfBoot product features such as secure boot, measured boot, encrypted partitions and root of trust (in the bootloader, TPM or secure element). Comparison of the SBSFU, TFM and wolfBoot options for STM32 micro-controllers. Implementation details for design of wolfBoot and how the partitions are defined.”

Video 2: wolfBoot for STM32, Part 2: Getting Started

  • How to download wolfBoot, where to find files and documentation. The wolfBoot product features such as secure boot, measured boot, encrypted partitions and root of trust (in the bootloader, TPM or secure element).”

Video 3: wolfBoot Out of the box with STM32G0.

Video 4: How to expand the wolfBoot HAL support for a new target.

Stay tuned for more information on when the next part of this video series goes live.

Additional Resources

Please contact us at with any questions about the webinar.

For technical support, please contact or view our FAQ page.

In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL.

Fuzz Testing

At wolfSSL, we pride ourselves on offering the Best-Tested SSL/TLS library on the market. We’re able to do so by conducting regular, diligent, and well-planned testing to maintain a robust and secure library. wolfSSL knows that it is impossible to test every single possible path through the software, but opts to practice an approach that is focused on lowering risk of failure. wolfSSL implements an extensive internal testing plan that not only uses automated testing, but makes sure to test well-known use cases. A key process in wolfSSL’s internal testing plan is Fuzz Testing.

What is Fuzz Testing?

Fuzz testing, also known as fuzzing, is an automated software testing technique that is conducted to reveal coding errors and security loopholes in softwares, networks, or operating systems. A fuzz test is a technique that is widely used to discover defects which otherwise would not be identified by merely using traditional functional testing methods. Fuzzing is a black box testing technique that bombards a library with invalid, unexpected, or random data (known as fuzz to the system) in an attempt to expose inputs that cause the system to crash, fail in unexpected ways, or leak memory. This allows wolfSSL to catch bugs that could turn into potential vulnerabilities before they are able to make it into a release!

Fuzzing at wolfSSL

wolfSSL was the first TLS to adopt fuzz testing, and firmly believes that if a TLS and cryptography provider does not do fuzz testing, they are extremely exposed. wolfSSL runs 7 internal fuzz testers nightly to ensure the most secure library on the market. wolfSSL tests using several different software fuzzers, including: 

  • an in-memory fuzzer (managed by wolfSSL)
  • a network fuzzer (managed by wolfSSL)
  • OSS-fuzz (service to run tests provided by Google, tests created by wolfSSL and Guido)
  • libfuzzer (tests created and ran by wolfSSL)
  • tlsfuzzer (project from, test is ran by wolfSSL)
  • AFL (tests created and ran by wolfSSL)
  • Third-party fuzz testing from Robert Horr

As a testament to wolfSSL’s commitment to security, highly respected external testers are utilized when possible. Some of our partners include Guido Vranken in Holland and Robert Horr of T-Systems in Germany. (Check out their guest blog posts: Fuzzing for wolfSSL by Guido Vranken, and Modern testing of the wolfSSL TLS library by Robert Horr).

As stated in the wolfSSL 2019 Annual Report, wolfSSL is the best-tested cryptography on market, more so than OpenSSL, due to consistent implementation of additional fuzz testing resources from both internal and external sources.

For further details regarding the internal wolfSSL process of testing to ensure code quality and security, please reference this blog page.

If there are any specific questions about how wolfSSL tests, please contact our team at If there is a desire to include other SSL/TLS or crypto implementations in wolfSSL interop testing, please let us know. Likewise, if users would like to include wolfSSL in their own test framework, we would be happy to discuss!


wolfSSL and the ALPACA TLS cross-protocol attack

The ALPACA attack may affect TLS servers who share multiple services and protocols on the same TLS endpoint/instance. The attack is difficult to implement because it requires a Man-in-the-Middle (MitM) position that can intercept and divert the victim’s traffic at the TCP/IP layer. 

As the TLS protocol does not protect the integrity of the TCP connection itself this attack redirects traffic from the intended TLS service to another service on the same endpoint. If the client considers the certificate of the substitute server to be valid for the intended server the authentication of the connection is violated.

This can enable cross-protocol attacks at the application layer, where the client unknowingly sends the protocol data for the intended server to the substitute server that expects a different protocol, potentially compromising the security of either server at the application layer.

For server’s hosting multiple services / protocols on the same endpoint here are steps to help prevent this attack:

1) Enable ALPN: The client and server should enable ALPN by setting `–enable-alpn` or by defining `HAVE_ALPN` and initialize ALPN by calling `wolfSSL_UseALPN`. The server (and preferably the client, too) should use the `WOLFSSL_ALPN_FAILED_ON_MISMATCH` option to enforce strict ALPN verification.

2) Enable SNI: The client and server should enable SNI by setting `–enable-sni` or by defining `HAVE_SNI`. The client should initialize it by calling `wolfSSL_UseSNI`. The server should implement a custom verification for the SNI hostname using the `wolfSSL_CTX_set_servername_callback`.


* ALPACA Attack Paper:

* Instructions for wolfSSL:

For questions email

wolfSSL Examples Repository

Upcoming Blog Series

From the early days of the wolfSSL library, we have provided example clients and servers with wolfSSL. These examples have shown how easy it is to use wolfSSL in various configurations. We also use them to help test the library. Over the years we’ve added new features available with TLS to our examples, and our examples have grown a little complicated.

Enter the wolfSSL Examples GitHub repository. This repository contains example clients and servers that set up and test various types of connections. They give you a bare-bones simple demonstration on how to set up a client or server using wolfSSL. In addition to these client/servers, our developers have included examples that demonstrate how to build wolfSSL with specific real time operating systems and TCP/IP stacks for embedded systems and devices, how to link with the wolfSSL library with a simple Enclave, and even how to use some features of the library like the certificate manager or wolfCrypt’s public-key functionality.

The repository contains example applications written in C, each directory represents a unique topic (TLS, DTLS, PSK, etc.) and contains a Makefile as well as a simple tutorial on the given topic. The wolfSSL Examples GitHub repository is a great way to gain familiarity with the wolfSSL lightweight SSL/TLS library so this upcoming blog series will be showcasing it and each topic/directory it contains. Here’s a comprehensive list of the topics to be covered.

android (Android NDK Examples)

This directory contains examples that demonstrate using wolfSSL and wolfSSLJNI on the Android platform, using the Android NDK toolchain.


This directory contains examples for securing a Bluetooth Low Energy Link (BTLE). BTLE packets are small and throughput is low, so these examples demonstrate a way to exchange data securely without BTLE pairing.

certfields (X509 field extraction)

This directory contains an example that demonstrates using wolfSSL to read a DER encoded certificate and extract the public key and subject name information.

certgen (wolfSSL Certificate Generation)

This directory contains examples that demonstrate using wolfSSL to generate and sign certificates.

certmanager (wolfSSL CertManager)

This directory contains examples that demonstrate using CertManager (Certificate Manager) functionality.

crypto (wolfCrypt Examples)

This directory contains examples that demonstrate using the wolfCrypt functionality to encrypt files with different algorithms (AES, 3DES, etc.)

custom-io-callbacks (wolfSSL Custom IO Callbacks)

This directory contains examples that demonstrate how the custom IO callbacks can be used to facilitate a TLS connection using any medium.

DTLS (Datagram TLS)

This directory contains examples of using DTLS, with client and server examples demonstrating UDP, DTLS, non-blocking, session resumption, and multi-threading.

ecc (Elliptic Curve Cryptography)

This directory contains examples that demonstrate the various use-cases of wolfCrypt ECC.

embedded (Embedded Systems)

This directory contains examples that demonstrate TLS client/servers communicating through buffers and using sockets.

hash (wolfCrypt Hash Examples)

This directory contains examples that demonstrate how to hash an input file using wolfCrypt.

java (wolfJSSE Examples)

This directory contains examples that demonstrate HTTPS URL use with wolfJSSE and example keystores.

mynewt (Apache Mynewt Examples)

This directory contains examples that demonstrate using wolfSSL with Apache Mynewt OS.

picotcp (picoTCP Examples)

This directory contains a TLS server created by using picoTCP via wolfSSL custom callbacks.

pk (Public-Key)

This directory contains examples that demonstrate various wolfCrypt public-key functionality (storing and loading keys after generation, extracting public key from private key, etc.).

pkcs11 (PKCS #11)

This directory contains examples of using wolfSSL’s PKCS #11 feature and a TLS server example using a PKCS 11 based key.

pkcs7 (PKCS #7)

This directory contains example applications that demonstrate usage of the wolfCrypt PKCS#7/CMS API, included in the [wolfSSL embedded SSL/TLS library].

PSK (Pre-Shared Keys)

This directory contains examples of using PSK, with client and server examples demonstrating TCP/IP, PSK, non-blocking, session resumption, and multi-threading.

riot-os-posix-lwip (RIOT-OS)

This directory contains examples that demonstrate how to use wolfSSL TLS sockets over RIOT-OS POSIX sockets.

RT1060 (i.MX RT1060-EVK)

This directory contains a wolfCrypt benchmark test application for i.MX RT1060-EVK.

SGX_Linux (Linux Enclave)

This directory contains an example application, written in C, which demonstrates how to link the wolfSSL lightweight SSL/TLS library with a simple Enclave (SGX) using Linux .

SGX_Windows (Windows Enclave)

This directory contains an example application, written in C++, which demonstrates how to link the wolfSSL lightweight SSL/TLS library with a simple Enclave (SGX) using Windows.

signature (Sign and Verify Examples)

This directory contains examples that demonstrate using wolfSSL to sign and verify binary data (supports RSA and ECC for signing and MD2, MD4, MD5, SHA, SHA224, SHA256, SHA384 and SHA512).

tirtos_ccs_examples (TI-RTOS)

This directory contains a client/server example that demonstrates using wolfSSL in a TI-RTOS ecosystem.


This directory contains examples of using SSL/TLS, with client and server examples demonstrating TCP/IP, SSL/TLS, non-blocking, session resumption, and multi-threading.

utasker (uTasker wolfSSL Example Tasks)

This directory contains example uTasker client and server tasks that demonstrate using wolfSSL with the uTasker stack. These have been tested on the uTasker Simulator.

wolfCLU (wolfSSL Command Line Utility)

This is a tool to provide command line access to wolfCrypt cryptographic libraries. wolfSSL command line utility will allow users to encrypt or decrypt a user specified file to any file name and extension.

Please contact wolfSSL at with any questions, bug fixes, or suggested feature additions.

wolfSSL supports TLS 1.3 !

Checkout out latest release:

wolfSSL Acceleration in Clavister’s OneConnect Next-Gen Firewall VPN Client

Clavister, one of Europe’s leading cybersecurity vendors, announced that their latest release of OneConnect for macOS, iOS and iPadOS utilizes acceleration from wolfSSL for better performance metrics. 

“We managed to leverage the acceleration in wolfSSL and could see a reduction of cpu usage (which should translate into better battery life),” says Clavister. If you’re not familiar with our performance benchmarks, visit our benchmarks page

wolfSSL is constantly expanding our hardware acceleration support portfolio. Check out our website for more information and send us a message to inquire about support for your target.

View Clavister’s announcement here

Follow wolfSSL on LinkedIn to stay tuned to more updates and use cases! Want to share how wolfSSL has helped your customers win? Write to us at


wolfSSL v4.8.1 Release

wolfSSL version 4.8.1 is available for download!!

This version of wolfSSL includes many new features, ports, and some great fixes. Some of the new features added includes:

  • A tie in for use with wolfSentry
    • wolfSentry is a universal, dynamic, embedded IDPS (intrusion detection and prevention system)
    • The build option added to enable the code for use with wolfSentry can be compiled using the autotools flag –enable-wolfsentry. wolfSentry is our new product that can be used in a similar fashion as a firewall but unlike many firewall applications available today wolfSentry is designed for deeply embedded IoT devices with resource constraints.
    • Learn more from our webinar: Introducing wolfSentry, an Embeddable IDPS
  • A number of API for the compatibility layer 
    • Helps support replacing OpenSSL using wolfSSL along with updating your crypto for FIPS requirements, 
  • A QNX CAAM driver for use with NXP’  i.MX devices, 
    • CAAM stands for Cryptographic Accelerator and Assurance Module. When used, it speeds up the cryptographic algorithms such as ECC and AES, as well as increases security by using encrypted keys and secure memory partitions.
  • Support for STM32G0
  • Zephyr project example,
    • The Zephyr Project is a scalable real-time operating system (RTOS) supporting multiple hardware architectures, optimized for resource constrained devices, and built with safety and security in mind.
  • An easy-to-use Dolphin emulator test for DEVKITPRO
    • devkitPro is a set of tool chains for compiling to gaming platforms.
  • Fixes for PKCS#7 
    • PKCS#7 is used to sign, encrypt, or decrypt messages under Public Key Infrastructure (PKI). It is also used for certificate dissemination, but is most commonly used for single sign-on.
  • Better parsing and handling of edge cases along with fixes for existing ports. 
  • Fixes that came from testing with Coverity and fsanitizer tools. 
    • Coverity is very efficient in finding issues, and is often used as a metric for good code (based on how many issues are found and fixed)
    •  fsanitizer is a static analysis tool
  • Two vulnerabilities announced, 
    • one dealing with OCSP 
      • OCSP or “Online Certificate Status Protocol” is an Internet protocol that is used to obtain the revocation status of an X.509 digital certificate.
    • the other with a previously fixed base64 PEM decoding side channel vulnerability.
      • PEM, or “Privacy Enhanced Mail” is the most common format that certificates are issued in by certificate authorities.

For a full list of changes, check out the updated bundled with wolfSSL or view our page on GitHub here ( Any questions can be sent directly to

wolfMQTT Release v1.9.0

The summer release of wolfMQTT v1.9.0 is now available! This release has several bug fixes and features including:

  • Fixes for Sensor Network client (PR #204, 214, 219)
  • Fixes for non-blocking (PR #205)
  • Fixes for multithread (PR #207, 209, 211, 218)
  • Fix for MQTTv5 publish response handling (PR #224, 220)
  • Fix subscribe return code list (PR #210)
  • Fix switch statement fallthrough on other toolchains (PR #225)
  • Add HiveMQ Cloud capability with SNI feature (PR #222)
  • Add ability to publish files from example client, fix chunked publish (PR# 223)

Check out the changelog from the download for a full list of features and fixes, or contact us at with any questions:

While you’re there, show us some love and give the wolfMQTT project a Star!
You can download the latest release here:
Or clone directly from our GitHub repository:

Sea Air Space 2021

Onwards! wolfSSL will be at Sea Air Space in Maryland this August 2-4. Come find us at booth 946 to talk to the leader in embedded FIPS certificates.

Sea Air Space – August 2nd-4th, 2021
Gaylord Ntl Resort & Convention Center (National Harbor, MD)
Booth #946

Join us so we can learn about your security requirements. We’ll have Engineering and Sales on the ground to support conversations around:

  • FIPS 140-3
  • Secure boot
  • Latest updates in wolfSSL 4.8.1
  • wolfSentry IDPS (intrusion detection and prevention system)
  • wolfCrypt as an engine for OpenSSL
  • Entropy assurance with wolfRAND
  • DO-178C DAL A certification
  • Benchmarking wolfCrypt
  • 24×7 commercial-style developer support for your mission-critical projects
  • Testing, testing, testing

Head over to the event website to register and email us at to book a meeting at the event!

Follow wolfSSL on Twitter
Star wolfSSL on GitHub

wolfTPM v2.2 Release

We are excited to announce the release of v2.2.0 for wolfTPM. This release adds several new examples such as remote attestation, seal/unseal and GPIO control. There are minor fixes for authenticated sessions. A few coding refactors to improve readability and reliability. We also added endorsement hierarchy support to several examples. If you are using QNX then you will appreciate the built-in HAL SPI driver support.

  • Fix for using multiple authenticated sessions.
  • Added QNX support.
  • Added new examples for remote attestation (make / activate credential).
  • Added GPIO support and examples for ST33 and Nuvoton NPCT75x modules.
  • Added new example for sealing a secret using TPM key.
  • Added Endorsement Hierarchy support to many examples.
  • Added missing TPM2_CreateLoaded and wrapper.
  • Refactored the reference HAL IO code into separate files.
  • Refactor of the TPM IO code to separate files.
  • Refactor the assignment of structs to use memcpy to avoid alignment issues.
  • Documentation improvements for API’s with Doxygen, QEMU and Windows TBS.

For a detailed list of changes see our here:

For questions please email us at

True Random vs. Pseudorandom Number Generation

Pseudo Random Number Generator (PRNG)

Software-generated random numbers only are pseudorandom. They are not truly random because the computer uses an algorithm based on a distribution, and are not secure because they rely on deterministic, predictable algorithms. Since a seed number can be set to replicate the “random” numbers generated, it is possible to predict the numbers if the seed is known. Pseudorandom number generation in everyday tools such as Python and Excel are based on the Mersenne Twister algorithm. 

An example use of PRNGs is in key stream generation. Stream ciphers, such as Chacha, encrypt plaintext messages by applying an encryption algorithm with a pseudorandom cipher digit stream (keystream). Keystreams of some block cipher modes, such as AES CTR (counter) mode, act as a stream cipher and can also be regarded as pseudorandom number generation.

True Random Number Generator (TRNG)

For truly random numbers, the computer must use some external physical variable that is unpredictable, such as radioactive decay of isotopes or airwave static, rather than by an algorithm. At the quantum level, subatomic particles have completely random behavior, making them ideal variables of an unpredictable system. Most higher end microcontrollers have TRNG sources, which wolfSSL can use as a direct random source or as a seed for our PRNG. Intel RDRAND, a silicon-based TRNG, is supported by wolfSSL.

Additionally, wolfSSL supports the following hardware systems involving TRNGs:

You can find the full list of all hardware acceleration/cryptography platforms currently supported by wolfSSL here: Hardware Cryptography Support

RNGs in cryptography

However, true RNGs on their own are often not cost efficient, and can be subject to gradual decline. Thus, there is still some reliance on post-processing algorithms (that are deterministic and vulnerable) to further improve randomness, as the quality of their entropy source is not consistent. The combination of a TRNG and a PRNG can limit the negative effects of this decline. For example, in NXP i.MX RT1060, the TRNG present in the core can be used as an entropy source to determine the seed of a Deterministic Random Bit Generator (DRBG), which on its own is a PRNG, but in combination with the TRNG results in a good approximation of randomness, without weakness over time. 

wolfSSL uses the SHA2-256 (Secure Hash Algorithm) Hash_DRBG described in NIST’s SP 800-90A (the specification for three allegedly cryptographically secure pseudorandom number generators for use in cryptography). Additionally, wolfRand, wolfSSL’s FIPS module which includes a hardware entropy source, is conformant to NIST’s SP 800-90B (the design principles and requirements for the entropy sources used by random-bit generators, and the tests for the validation of entropy sources).

For cryptographic purposes, a more secure approximation of a true random number can be achieved with a combination of algorithms, rather than just relying on one. In the update from TLS 1.1 to TLS 1.2, the MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs, which continue to be used in TLS 1.3 with SHA2-256 and SHA2-384. 

MD5/SHA-1 (Message Digest/Secure Hash Algorithm) combined two Message Authentication Code (MAC) algorithms to provide a balance between speed and security. Meanwhile, a cipher suite is a set of cryptographic instructions or algorithms that helps secure network connections through Transport Layer Security(TLS)/Secure Socket Layer (SSL). During the SSL handshake between the web server and the client, the two parties agree on a cipher suite, which is then used to secure the HTTPS connection. A typical cipher suite contains 1 key exchange, 1 bulk encryption, 1 authentication, and 1 MAC algorithm. 

For more information on cipher suites and their uses, visit “What is a Cipher Suite?


Truly random numbers are difficult to generate because they are not cost-efficient and subject to decline over time. However, random number generation can be made more effective by using multiple random processes in combination, either with a TRNG/PRNG combination, or an ensemble of algorithms in a cipher suite.

For more information on wolfRand or general inquiries about wolfSSL, contact us at

Posts navigation

1 2