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

Upcoming Webinar: Twin Oaks and wolfSSL Partner Webinar

wolfSSL presents a partner webinar with Twin Oaks Computing! We’re talking about secure DDS for industrial and military applications. We want to see you there!

Register here:–ySiQ
Wednesday, July 14th, 2021 at 8AM Pacific time (GMT-8)

Twin Oaks Computing, the leader in small footprint Data Distribution Service (DDS) communications middleware, and wolfSSL, the leader in embedded security, are excited to announce a new partnership. This partnership will enable our clients to take advantage of the best features of CoreDX DDS and wolfSSL’s best-tested crypto library.

Industrial systems across all industries are connecting devices and components that have historically not been connected. Adding connectivity creates enormous opportunity from telematics and predictive maintenance to more intelligent operations. However, adding connectivity adds exposure to network-based attacks. These industrial systems share common connection requirements of reliability, scalability, and now, security. How are your software components connected? Do your connectivity protocols meet your reliability, scalability, and security requirements?

This presentation takes an in-depth look at connected industrial and military applications using a combination of the Data Distribution Service (DDS) standardized connectivity protocol from Twin Oaks Computing and wolfSSL’s robust, modular wolfCrypt engine, with a focus on secure data communications.

wolfSSL focuses on providing lightweight and embedded security solutions with an emphasis on speed, size, portability, features, and standards compliance. With a strong history in FIPS 140-2 and TLS 1.3 support, wolfSSL is supporting high-security designs across verticals and securing two billion connections globally.

Bring your questions for the Q&A session to follow!

wolfTPM first to support Nuvoton NPCT75x extra GPIO for safety-critical applications

wolfTPM is the leading TPM library for embedded and baremetal applications. It is widely used in aerospace, military, and medical systems because the wolfSSL TPM 2.0 library is designed specifically for embedded systems. wolfTPM offers a low memory footprint and supports all of the TPM 2.0 commands and operations; as well as provids examples of: attestation, NVRAM usage, secure storage, and sealing.

Today, we have expanded on the new  TPM 2.0 feature called Extra GPIO, by adding support for the newest variant of NPCT75x modules by Nuvoton.

It is now possible to protect and control GPIO by using TPM 2.0 authorization. This way, extra GPIO on the TPM chip becomes a great tool for signaling of critical events across subsystems.

Since, wolfTPM already offers support for extra GPIO for ST33 modules from STMicroelectronics. Here is a brief comparison of the GPIO capabilities between ST33 and NPCT75x :

Manufacturer Model Extra GPIO availability GPIO modes
Nuvoton NPCT75x 2 GPIO for SPI & I2C 3 output modes
STMicroelectronics ST33 2 GPIO for SPI

4 GPIO for I2C
6 modes in total

In safety-critical systems, extra GPIO control through the TPM 2.0 module provides signaling for security events and important changes of the system state. Such use cases are observed in the rising railway IoT automation and in modern automotive systems.

We want to thank the team at Nuvoton led by Mr. Oren and the amazing field application engineer Ms. Dana for collaborating on this project.

If you want to use TPM 2.0 and secure GPIO signaling in your next project please contact us at

wolfMQTT Client Supports HiveMQ Cloud

The wolfMQTT client library “mqttclient” example demonstrates securely connecting over TLS provided by wolfSSL.

We set up a HiveMQ Cloud cluster that can be used for testing. The HiveMQ Cloud broker uses the Server Name Indicator (SNI) extension for TLS client authentication, which is specified using the `-S ` option. The example is located in `/examples/mqttclient/`. You can test with our HiveMQ Cloud cluster using:

./examples/mqttclient/mqttclient -h -t -S -u wolf1 -w NEZjcm7i8eRjFKF -p 8883

Everyone deserves to have their IoT data secure, and wolfSSL provides the best libraries to accomplish that! Secure-IoT-Love from the wolfSSL team!

You can download the latest release here:

Or clone directly from our GitHub repository:

Don’t forget to add a star while you’re there!  Contact us at with any questions or for help using wolfMQTT in your project!

Embedded SSH client with TPM protected keys

We are adding hardware security to wolfSSH to meet the rising security requirements for connected systems.

Thanks to the widely available Trusted Platform Module (TPM) and our portable wolfTPM library, wolfSSH can have the user’s private SSH key stored and used directly from a hardware security module. This way the private key material is never exposed in raw form and the system has physical tamper-proof protection of its important secrets.

wolfSSH is a portable SSH v2.0 client and server. It also supports the SCP and SFTP protocols. This makes wolfSSH a preferred choice for embedded systems and applications. 

wolfTPM is a portable TPM 2.0 library, designed for baremetal and embedded systems. wolfTPM has its own TPM Interface Layer (TIS) developed in accordance with the Trusted Computing Group Group (TCG). This allows wolfTPM to operate in every operating environment, because it does not require a TPM driver.

For information on our wolfSSH capabilities see

Do you want to use SSH with hardware protected keys? Please email us at

Integration update: wolfSSL is the Secure Socket Solution for Qt

The QSslSocket class in Qt makes it easy to add encryption to your application. wolfSSL makes it secure!

The wolfSSL embedded SSL/TLS library is a lightweight SSL/TLS library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments – primarily because of its small size, speed, and feature set.  It is commonly used in standard operating environments as well because of its royalty-free pricing and excellent cross-platform support. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.2 levels, is up to 20 times smaller than OpenSSL, supports FIPS, and has critical interfaces like TPM 2.0 and  PKCS#11.

Qt has traditionally used OpenSSL as the provider for SSL/TLS in Qt Network for secure network communications. wolfSSL 4.4.0 adds support for building Qt 5.12 and 5.13 against the wolfSSL embedded SSL/TLS library instead of the default OpenSSL backend! The wolfSSL integration with Qt provides a performance-minded alternative, ideal for Qt developers who are looking for a lightweight, progressive, and well-tested SSL/TLS implementation.  

Using wolfSSL as a TLS provider in Qt can have many advantages, depending on application and industry.  Some of these may include:

To learn more about the advantages of using wolfSSL, visit our page on “wolfSSL vs. OpenSSL”. For more insight into building Qt with wolfSSL, the advantages it brings to Qt developers when used in place of OpenSSL, and the current state of SSL/TLS and the cryptography algorithms used, watch this recorded talk by our Engineering Manager, Chris Conlon. 

For instructions on how to compile Qt with the wolfSSL patch, please visit Building Qt with wolfSSL

Questions? Reach out to our support team at!

cURL Security Advisories

The 200th curl release found 3 major security advisories from the curl bug-bounty program. These are the advisories:

This is a Use-After-Free in the OpenSSL backend code that in the absolutely worst case can lead to an RCE, a Remote Code Execution. The flaw is reasonably recently added and it’s very hard to exploit but you should upgrade or patch immediately.

The issue occurs when TLS session related info is sent from the TLS server when the transfer that previously used it is already done and gone.

When libcurl accepts custom TELNET options to send to the server, it the input parser was flawed which could be exploited to have libcurl instead send contents from the stack.

In the Schannel backend code, the selected cipher for a transfer done with was stored in a static variable. This caused one transfer’s choice to weaken the choice for a single set transfer could unknowingly affect other connections to a lower security grade than intended.

Upcoming Webinar: Introducing wolfSentry, an Embeddable IDPS

wolfSSL personally invites you to our wolfSentry webinar, where we are introducing our newest product wolfSentry, a universal, dynamic, embeddable IDPS (intrusion detection and prevention system)! Join us to learn about about what an IDPS is, why you should care, and wolfSentry is the solution to all of your problems

About the webinar:

When: Thursday, July 8th at 10AM Pacific time (GMT-8)
Topic: wolfSentry IDPS webinar presented by wolfSSL


After registering, you will receive a confirmation email containing information about joining the webinar.

Please bring any questions you have, and we look forward to seeing you there!

Posts navigation

1 2 3