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.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.

wolfSSL Riding the CAN Bus

TLDR:  wolfSSL can run over CAN Bus.  This means wolfSSL can secure CAN Bus, which is typically insecure.  As such, you can now authenticate over CAN Bus and encrypt over CAN Bus.

The CAN (Controller Area Network) bus is a common data bus used in vehicles for onboard microcontrollers to communicate to each other. Modern vehicles have dozens of microcontrollers inside them and the usage of this technology is only going to grow in road vehicles as newer safety standards come into effect. Vehicle computers are becoming rather powerful and there have already been instances in the media of these computers being remotely hacked. Security, therefore, will become an important part of CAN bus communication over the coming years.

Part of the downside of the CAN bus protocol is that it only supports a payload of up to 8 bytes per packet, so there are layers on top of this to add flow control and packet headers so that larger packets can be reliably sent. One of the most common of these is ISO-TP (ISO 15765-2), which is regularly used for things such as OBD-2 diagnostic messaging.

A great thing about ISO-TP is that it allows us to send packets of up to 4KB and a great thing about wolfSSL is that you can hook it into pretty much anything with a data send and receive function. We have therefore created an example of how to hook wolfSSL into ISO-TP and use this over a CAN bus. This example can be found at This is a simple echo client and server which will negotiate a TLS handshake and then send / receive encrypted messages. The Linux kernel has a built-in virtual CAN bus as documented in the README, but you can use a real CAN bus to try this on. For example, here is one I made earlier between my laptop and a Raspberry Pi 3A:

Using this setup the example works as below:

And that is it! The code is relatively simple to go through but feel free to contact us for more information. Look out for more CAN bus security tools from wolfSSL in the future.

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

Contact us at for any questions or comments.

Support for Renesas TSIP v1.13 on RX72N

We’re happy to announce that we’ve added support for Renesas TSIP v1.13 on RX72N in wolfSSL v5.0.0! The RX72N MCU is the flagship model of RX series, using a 32-bit RX72N 240 MHz microcontroller.Using the TSIP driver, wolfSSL can offload supported cryptographic and TLS operations to the underlying Renesas hardware for increased performance.

If you have an interest in using wolfSSL with this MCU, check out our benchmark page about RX72N here:

Check out our blog on wolfSSL Renesas TSIP support here:

More information on using wolfSSL in combination with Renesas and wolfSSL’s support for Renesas can be found here:

You can access the GitHub page to wolfSSL here:

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

wolfSSL Added Support for pyOpenSSL

One of the highlights of our wolfSSL library is its exceptional portability, which allows wolfSSL’s team of engineers to frequently add new ports!

We’re happy to announce that we’ve added support for pyOpenSSL in wolfSSL v5.0.0! We have integrated wolfSSL with the pyOpenSSL project, which allows for the use of pyOpenSSL with our SSL/TLS library, wolfSSL. pyOpenSSL is a thin OpenSSL wrapper for python.

You can access the GitHub page to wolfSSL here:

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

Open Quantum Safe and wolfSSL Joint Wireshark Integration

In a recent blog post we showed the details of a quantum-safe connection using wireshark. This post is to announce that now you can also do the exact same thing by following instructions provided by our friends at the Open Quantum Safe group. They have generously hosted a wireshark integration via docker that will display algorithm names using both their naming convention as well as wolfSSL’s.

The default naming convention is OQS’s but if you want to use wolfSSL’s naming convention, simply clone their repo at `` and in the `wireshark/Dockerfile` change the following line:


… to …


… and then follow the rest of the instruction in `wireshark/` and `wireshark/`. We at wolfSSL would like to thank our friends at the OpenQuantumSafe project for their hard work!

For information about wolfSSL and power usage contact

OpenSSL 3.0 Provider Solution with FIPS

As you may know, wolfSSL has integrated our FIPS-certified crypto module, wolfCrypt, with OpenSSL as an OpenSSL engine, in a product we call wolfEngine. OpenSSL 3.0 has done away with the engines paradigm in favor of a new concept, called providers. wolfSSL now has a FIPS 140-2 solution for an OpenSSL 3.0 provider, allowing you to use the latest version of OpenSSL backed by our FIPS-certified wolfCrypt library.

wolfSSL is also in the process of getting certified for FIPS 140-3.  Once certified, our OpenSSL 3.0 provider solution will also be FIPS 140-3 ready. Like wolfEngine, the wolfSSL provider for OpenSSL is an excellent pathway for users looking to get FIPS compliance fast while still using OpenSSL.

For more information, visit our blog post on the difference between FIPS 140-2 and FIPS 140-3.

If you have any questions regarding OpenSSL 3.0 provider solutions, please contact us at

wolfBoot UEFI Support

We’re happy to announce that we’ve added experimental support to run wolfBoot as an EFI application! The Unified Extensible Firmware Interface (UEFI) is a specification that describes an interface between the operating system (OS) and the platform firmware and it replaces the old BIOS-like firmware. Now wolfBoot can run inside the UEFI environment on Intel x86_64 machines and load and verify other EFI applications.

This means that we can use it to boot and verify Linux (Linux supports booting as EFI application, a.k.a. EFI STUB) on UEFI machines.

UEFI has a several other interesting features that we plan to integrate in the future: such as SecureBoot and TPM.

To try wolfBoot EFI visit our repository on GitHub, you can also run an example on QEMU!

As usual for more information, please reach out to!

Power Usage Benchmark with EEMBC

The latest benchmarks of wolfSSL power consumption on an STM32L476G device are up ( What we found is that using wolfSSL’s SP math (with assembly speed ups) is superior on the device. It has a positive impact on both the speed and power consumption.

With the measurements used with EEMBC ( higher final scores are better. Without using any optimizations in building wolfSSL the power usage collected was 2170 and performance was 502. Once turning on optimizations and SP assembly the power usage was 13200 and performance was 3050.

The energy score is derived from an inverted, weighted, micro Joules per iteration. Similarly the performance is an inverted, weighted, microseconds per iteration. ECDSA operations saw a significant performance and power usage improvement with SP math enabled and assembly optimizations compiled in. ECDSA operations are the biggest resource consumers with TLS handshakes and a good indication of how long and how much power a TLS connection will use.

For information about wolfSSL and power usage contact

wolfSSL NXP SE050 Support

We are excited to announce wolfSSL’s support for the NXP SE050. The wolfSSL SE050 port supports a variety of algorithms including: SHA, SHA2-224, SHA2-256, SHA2-384, SHA2-512, AES-CBC, AES-ECB, ECDSA, ECDHE and most notably ED25519 / CURVE25519.

In the tested configuration a Raspberry Pi 2b was connected to the SE050 dev kit through a header board. Please refer to this guide if interested in replicating hardware configuration (

Below are hardware accelerated benchmarks using the NXP SE050:

TRNG0.114 KB/s
ECDH - Shared SecretAvg 169.276 ms
ECDSA - SignAvg 102.899 ms
ECDSA - VerifyAvg 102.920 ms
ED25519 - SignAvg 261.323 ms
ED25519 - VerifyAvg 143.541 ms
CURVE25519 agreeAvg 157.089 ms

If you have an interest in using wolfSSL with this board, please see:

Additionally, wolfSSL also provides support for the latest version of the TLS protocol, TLS 1.3! Find more information about TLS 1.3 here:
For more information, please contact

MQTT Secure Firmware Update Example

Our wolfMQTT project includes an example for secure firmware update or Over the Air (OTA) update. This example uses the wolfSSL embedded SSL/TLS library to hash/sign the binary image and send it over MQTT. The example has two applications. One is called fwpush, which hashes, signs and publishes the firmware image over TLS to an MQTT broker. The second is called fwclient, which subscribes to the example firmware update topic, receives the firmware image and validates the signature of it. This example is located in examples/firmware.

The latest wolfMQTT releases can be downloaded at:

Documentation for wolfMQTT can be found here:

The latest source code can be found on our GitHub repo at:

For questions please contact support at

wolfSSL Support Added for Python

We’re happy to announce that we’ve added wolfSSL support to Python version 3.8.5 using our OpenSSL compatibility layer! The wolfSSL port allows you to use Python with our FIPS 140-2/3 certified wolfCrypt library. To build Python with wolfSSL, follow the instructions in our open source projects repository here.

To view wolfSSL’s collection of open source project ports, visit our osp repository on GitHub!

For more information, please reach out to!

Posts navigation

1 2 3 4 5 143 144 145

Weekly updates


Latest Tweets