Category: wolfSSL/ wolfCrypt

wolfSSL 5.8.4 introduces several updates, including the addition of a GPLv3 exceptions list. This allows specific GPLv3-licensed codebases linking against wolfSSL to continue using wolfSSL under GPLv2.

Current GPLv3 Exceptions:

• MariaDB Server
• MariaDB Client Libraries
• OpenVPN-NL
• Fetchmail
• OpenVPN

Security Fixes

This release includes multiple fixes across TLS 1.2, TLS 1.3, X25519, XChaCha20-Poly1305, and PSK processing. Highlights include:

• A timing-side-channel issue in X25519 specifically affecting Xtensa-based ESP32 devices. Low-memory X25519 implementations are now the default for Xtensa.
• A medium-severity TLS 1.3 server-side DoS risk from repeated KeyShareEntry values in malicious ClientHello messages.
• Several TLS 1.3 downgrade-related issues (PFS downgrades, signature algorithm downgrades, and duplicate extension parsing).
• A memory leak risk in TLS 1.2 certificate digest handling.
• XChaCha20-Poly1305 decryption bounds-check fix and constant-time improvements in PSK binder verification.

Special thanks to Adrian Cinal, Jaehun Lee and Kyungmin Bae (POSTECH), Luigino Camastra (Aisle Research), and all researchers who contributed.

New Features

This release includes focused improvements and additions:

• ML-KEM / ML-DSA: new APIs, PKCS8 seed/import support, and improved key management.
• FreeBSD kernel module: initial support for wolfCrypt in the FreeBSD kernel.
• PKCS7/CMS: expanded decoding capabilities, additional callbacks, and more flexible builds.
• Rust wrapper enhancements: broader algorithm coverage, optional heap/dev_id support, and conditional compilation based on C build options.
• Hardware platform updates: STM32 and PSoC6 improvements, including STM32U5 SAES support.
• New –enable-curl=tiny option for smaller cURL-linked builds.

Improvements & Optimizations

Key improvements include:

• Broader and more consistent testing across TLS 1.3/1.2, libssh2, Arduino, ESP-IDF, and nightly workflows.
• Documentation updates, expanded crypto-callback support, and improved AES/HW offload functionality.
• ESP32, Renesas FSP/RA, and SGX build enhancements.
• Build-system refinements across Autotools, CMake, Apple platforms, and Debian packaging.
• RISC-V and PPC32 assembly introspection helpers and benchmarking updates.

Bug Fixes

Notable fixes:

• C# wrapper correction for Ed25519 raw public-key import.
• Sniffer stability fixes and X.509 path-length and certificate-chain improvements.
• DTLS ordering, cookie handling, and replay protection updates.
• Kernel-mode, FIPS, and PIE-related build fixes.
• ML-KEM/ML-DSA correctness and safety fixes.
• Various static-analysis, warning cleanup, memory-management, and undefined-behavior fixes.

For a more detailed list of changes check out the ChangeLog.md bundled with wolfSSL. To download the latest release go to the download page. For any questions, reach out to us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

We’re excited to announce that the widely-used PDF signature tool pdfsig can now be used with wolfPKCS11 and NSS!

This integration allows you to digitally sign PDF documents using PKCS#11 keys using software tokens, HSMs, or secure elements, through the NSS framework. All powered by the FIPS-ready wolfCrypt engine.

Why This Matters

For many applications – document workflows, certification, legal-signing chains – the ability to sign PDF files in a standards-compliant way is essential. pdfsig is a command-line tool (part of Poppler/NSS toolset) that supports PDF digital signatures, verifying them and creating them (when used with proper PDF fields). FreeBSD Manual Pages+1

With wolfPKCS11 acting as a full PKCS#11 provider for NSS, you can now:

• Bring in a FIPS 140-3 validated cryptographic engine (wolfCrypt) under the covers via wolfPKCS11 for high-assurance signing.
• For embedded Linux applications, use a TPM along with wolfTPM to securely store signing keys, or leverage the secure domain when using wolfBoot.

How It Works

pdfsig (part of Poppler’s tools) supports digital signatures when NSS provides the signing backend.
By loading wolfPKCS11 as a PKCS#11 module in NSS, the signing key and certificate can come from any token accessible via the wolfPKCS11 provider.
Here’s what happens under the hood:

1. NSS loads the wolfPKCS11 shared library as a PKCS#11 provider.
2. NSS accesses the token (software, TPM, or HSM) for the private key.
3. pdfsig signs the PDF via NSS, which routes cryptographic operations through wolfPKCS11 and wolfCrypt.
4. The resulting PDF contains a standards-compliant signature validated by any conformant PDF viewer.

Example: Signing a PDF via NSS and wolfPKCS11

Once you have compiled wolfPKCS11 with NSS, the wolfPKCS11 backend module is used instead of NSS’s built-in one (a small patch to NSS is needed), this ensures that wolfCrypt is used for all cryptographic operations. You can then run:

# 1. Create a new NSS database
mkdir ~/nssdb
echo "mypassword" > ~/nssdb/password.txt
certutil -N -d $HOME/nssdb -f ~/nssdb/password.txt

# 2. Import a certificate and private key into the token
pk12util -i mycert.p12 -d $HOME/nssdb -W mypassword

# 3. Verify that NSS can see the token and key
certutil -L -d $HOME/nssdb

# 4. Sign a PDF file using pdfsig via wolfPKCS11 + NSS
pdfsig input.pdf signed.pdf \
  -add-signature \
  -d $HOME/nssdb \
  -nss-pwd mypassword \
  -nick "pkcs11:token=mytoken;object=mykey;type=private" \
  -reason "Approved using wolfPKCS11"

# 5. Verify the signature
pdfsig signed.pdf

This creates a signed PDF that includes the proper signature field and certificate chain, validated by most PDF viewers.

Benefits

• Hardware-Backed Security: Supports HSMs, TPMs, and other secure key stores via PKCS#11.
• FIPS-Ready Cryptography: Leverages wolfCrypt’s FIPS 140-3 validated algorithms.
• Automation Friendly: Perfect for document signing pipelines and CI/CD workflows.
• Interoperable: Works with standard NSS tooling — no vendor lock-in.

Getting Started

1. Install wolfPKCS11 and wolfSSL from GitHub.
2. Patch and compile NSS with the patch in GitHub.
3. Import your signing key and certificate into the NSS token.
4. Use pdfsig to sign and verify PDF files directly through NSS.

Alternatively, our wolfPKCS11 examples repository has a Dockerfile which can build everything and will run an example sign and verify.

Find out more

If you’d like to integrate wolfPKCS11 with your document signing, HSM, or workflow automation system, contact us at facts@wolfssl.com or call us at +1 425 245 8247 for guidance or evaluation support.
Download wolfSSL Now

During a recent industry expo, the wolfSSL team demonstrated the wolfCrypt benchmark and received frequent questions about memory usage, particularly for post-quantum algorithms.

We happened to be working on a feature which would provide exactly what was being asked for at the time, and I’m happy to report that it is wolfSSL’s GitHub repository now and will be included in the next wolfSSL release.

How it works

When building wolfSSL, memory and stack tracking can be enabled via ./confgure options –enable-memory –enable-trackmemory=verbose –enable-stacksize=verbose, or by adding the following macro definitions:

#define WOLFSSL_TRACK_MEMORY
#define WOLFSSL_TRACK_MEMORY_VERBOSE
#define HAVE_STACK_SIZE
#define HAVE_STACK_SIZE_VERBOSE

These options activate both heap allocation tracking and detailed stack usage reporting within the wolfCrypt benchmark.

This allows the benchmark to track the peak and total memory usage during the benchmark for each algorithm, as well as totals for the entire application at the end.

Unlike the regular performance benchmark recording, this mode also tracks memory during the setup phase of each algorithm so that you can see how much RAM is used for the entire initialization and execution of an algorithm.

Example

This example is with an STM32U585 compiled with hardware acceleration for RNG, AES and SHA-256, demonstrating how memory tracking behaves on a resource-constrained embedded system. It is using the small memory model for the post-quantum algorithms:

wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
RNG                        425 KiB took 1.039 seconds,  409.047 KiB/s [heap 494 bytes (8 allocs), stack 1448 bytes]
AES-128-CBC-enc              9 MiB took 1.000 seconds,    8.521 MiB/s [heap 312 bytes (1 allocs), stack 736 bytes]
AES-128-CBC-dec              8 MiB took 1.000 seconds,    8.472 MiB/s [heap 312 bytes (1 allocs), stack 736 bytes]
AES-256-CBC-enc              8 MiB took 1.000 seconds,    7.910 MiB/s [heap 312 bytes (1 allocs), stack 736 bytes]
AES-256-CBC-dec              8 MiB took 1.000 seconds,    7.861 MiB/s [heap 312 bytes (1 allocs), stack 736 bytes]
AES-128-GCM-enc              8 MiB took 1.000 seconds,    7.935 MiB/s [heap 344 bytes (3 allocs), stack 992 bytes]
AES-128-GCM-dec              8 MiB took 1.000 seconds,    7.886 MiB/s [heap 312 bytes (1 allocs), stack 984 bytes]
AES-256-GCM-enc              7 MiB took 1.000 seconds,    7.397 MiB/s [heap 344 bytes (3 allocs), stack 976 bytes]
AES-256-GCM-dec              7 MiB took 1.000 seconds,    7.349 MiB/s [heap 312 bytes (1 allocs), stack 984 bytes]
AES-128-GCM-enc-no_AAD       8 MiB took 1.000 seconds,    7.983 MiB/s [heap 344 bytes (3 allocs), stack 976 bytes]
AES-128-GCM-dec-no_AAD       8 MiB took 1.000 seconds,    7.935 MiB/s [heap 312 bytes (1 allocs), stack 944 bytes]
AES-256-GCM-enc-no_AAD       7 MiB took 1.000 seconds,    7.422 MiB/s [heap 344 bytes (3 allocs), stack 976 bytes]
AES-256-GCM-dec-no_AAD       7 MiB took 1.000 seconds,    7.397 MiB/s [heap 312 bytes (1 allocs), stack 944 bytes]
GMAC Small                  14 MiB took 1.000 seconds,   14.154 MiB/s [heap 0 bytes (0allocs), stack 1536 bytes]
CHACHA                       6 MiB took 1.000 seconds,    5.688 MiB/s [heap 68 bytes (1 allocs), stack 624 bytes]
CHA-POLY                     4 MiB took 1.004 seconds,    3.623 MiB/s [heap 232 bytes (4 allocs), stack 672 bytes]
POLY1305                    16 MiB took 1.000 seconds,   15.918 MiB/s [heap 40 bytes (1 allocs), stack 800 bytes]
SHA-256                     14 MiB took 1.000 seconds,   14.429 MiB/s [heap 344 bytes (2 allocs), stack 624 bytes]
SHA-384                      1 MiB took 1.012 seconds,    1.158 MiB/s [heap 400 bytes (3 allocs), stack 624 bytes]
SHA-512                      1 MiB took 1.016 seconds,    1.153 MiB/s [heap 416 bytes (3 allocs), stack 658 bytes]
SHA-512/224                  1 MiB took 1.012 seconds,    1.158 MiB/s [heap 380 bytes (3 allocs), stack 624 bytes]
SHA-512/256                  1 MiB took 1.012 seconds,    1.158 MiB/s [heap 384 bytes (3 allocs), stack 624 bytes]
SHA3-224                     1 MiB took 1.003 seconds,    1.290 MiB/s [heap 436 bytes (2 allocs), stack 656 bytes]
SHA3-256                     1 MiB took 1.000 seconds,    1.221 MiB/s [heap 440 bytes (2 allocs), stack 656 bytes]
SHA3-384                   975 KiB took 1.016 seconds,  959.646 KiB/s [heap 456 bytes (2 allocs), stack 656 bytes]
SHA3-512                   675 KiB took 1.008 seconds,  669.643 KiB/s [heap 472 bytes (2 allocs), stack 656 bytes]
SHAKE128                     2 MiB took 1.012 seconds,    1.496 MiB/s [heap 576 bytes (2 allocs), stack 672 bytes]
SHAKE256                     1 MiB took 1.003 seconds,    1.217 MiB/s [heap 544 bytes (2 allocs), stack 656 bytes]
HMAC-SHA256                 14 MiB took 1.000 seconds,   14.014 MiB/s [heap 768 bytes (1 allocs), stack 784 bytes]
HMAC-SHA384                  1 MiB took 1.008 seconds,    1.138 MiB/s [heap 896 bytes (2 allocs), stack 840 bytes]
HMAC-SHA512                  1 MiB took 1.008 seconds,    1.138 MiB/s [heap 896 bytes (2 allocs), stack 784 bytes]
RSA     2048   public        58 ops took 1.000 sec, avg 17.241 ms, 58.000 ops/sec [heap 6725 bytes (6 allocs), stack 1040 bytes]
RSA     2048  private         2 ops took 2.047 sec, avg 1023.500 ms, 0.977 ops/sec [heap 2860 bytes (4 allocs), stack 1096 bytes]
DH      2048  key gen         3 ops took 1.278 sec, avg 426.000 ms, 2.347 ops/sec [heap 7752 bytes (10 allocs), stack 1072 bytes]
DH      2048    agree         4 ops took 1.706 sec, avg 426.500 ms, 2.345 ops/sec [heap 10428 bytes (9 allocs), stack 1376 bytes]
ML-KEM 512    128  key gen       290 ops took 1.004 sec, avg 3.462 ms, 288.845 ops/sec[heap 1530 bytes (2 allocs), stack 1096 bytes]
ML-KEM 512    128    encap       278 ops took 1.004 sec, avg 3.612 ms, 276.892 ops/sec[heap 3578 bytes (2 allocs), stack 1088 bytes]
ML-KEM 512    128    decap       206 ops took 1.000 sec, avg 4.854 ms, 206.000 ops/sec[heap 4346 bytes (3 allocs), stack 1088 bytes]
ML-KEM 768    192  key gen       176 ops took 1.000 sec, avg 5.682 ms, 176.000 ops/sec[heap 2042 bytes (2 allocs), stack 1096 bytes]
ML-KEM 768    192    encap       164 ops took 1.008 sec, avg 6.146 ms, 162.698 ops/sec[heap 5114 bytes (2 allocs), stack 1792 bytes]
ML-KEM 768    192    decap       128 ops took 1.012 sec, avg 7.906 ms, 126.482 ops/sec[heap 6202 bytes (3 allocs), stack 1792 bytes]
ML-KEM 1024   256  key gen       108 ops took 1.004 sec, avg 9.296 ms, 107.570 ops/sec[heap 2554 bytes (2 allocs), stack 1096 bytes]
ML-KEM 1024   256    encap       102 ops took 1.008 sec, avg 9.882 ms, 101.190 ops/sec[heap 6650 bytes (2 allocs), stack 1792 bytes]
ML-KEM 1024   256    decap        84 ops took 1.019 sec, avg 12.131 ms, 82.434 ops/sec[heap 8218 bytes (3 allocs), stack 1792 bytes]
ECC   [      SECP256R1]   256  key gen        12 ops took 1.008 sec, avg 84.000 ms, 11.905 ops/sec [heap 4628 bytes (6 allocs), stack 1080 bytes]
ECDHE [      SECP256R1]   256    agree        12 ops took 1.004 sec, avg 83.667 ms, 11.952 ops/sec [heap 9393 bytes (15 allocs), stack 1416 bytes]
ECDSA [      SECP256R1]   256     sign        58 ops took 1.023 sec, avg 17.638 ms, 56.696 ops/sec [heap 308 bytes (5 allocs), stack 1112 bytes]
ECDSA [      SECP256R1]   256   verify        54 ops took 1.000 sec, avg 18.519 ms, 54.000 ops/sec [heap 152 bytes (2 allocs), stack 1432 bytes]
CURVE  25519  key gen         3 ops took 1.086 sec, avg 362.000 ms, 2.762 ops/sec [heap 119 bytes (3 allocs), stack 1000 bytes]
CURVE  25519    agree         4 ops took 1.447 sec, avg 361.750 ms, 2.764 ops/sec [heap 119 bytes (3 allocs), stack 1768 bytes]
ED     25519  key gen         3 ops took 1.102 sec, avg 367.333 ms, 2.722 ops/sec [heap 128 bytes (3 allocs), stack 1136 bytes]
ED     25519     sign         4 ops took 1.494 sec, avg 373.500 ms, 2.677 ops/sec [heap 256 bytes (4 allocs), stack 1792 bytes]
ED     25519   verify         2 ops took 1.538 sec, avg 769.000 ms, 1.300 ops/sec [heap 128 bytes (1 allocs), stack 1792 bytes]
ML-DSA    44  key gen        66 ops took 1.000 sec, avg 15.152 ms, 66.000 ops/sec [heap 26531 bytes (6 allocs), stack 1072 bytes]
ML-DSA    44     sign        16 ops took 1.051 sec, avg 65.688 ms, 15.224 ops/sec [heap 15528 bytes (3 allocs), stack 1416 bytes]
ML-DSA    44   verify        62 ops took 1.027 sec, avg 16.565 ms, 60.370 ops/sec [heap 8104 bytes (1 allocs), stack 1416 bytes]
ML-DSA    65  key gen        38 ops took 1.016 sec, avg 26.737 ms, 37.402 ops/sec [heap 31651 bytes (6 allocs), stack 1040 bytes]
ML-DSA    65     sign         8 ops took 1.008 sec, avg 126.000 ms, 7.937 ops/sec [heap 20648 bytes (3 allocs), stack 1416 bytes]
ML-DSA    65   verify        38 ops took 1.039 sec, avg 27.342 ms, 36.574 ops/sec [heap 9128 bytes (1 allocs), stack 1416 bytes]
ML-DSA    87  key gen        24 ops took 1.079 sec, avg 44.958 ms, 22.243 ops/sec [heap 37795 bytes (6 allocs), stack 1072 bytes]
ML-DSA    87     sign         6 ops took 1.146 sec, avg 191.000 ms, 5.236 ops/sec [heap 26792 bytes (3 allocs), stack 1416 bytes]
ML-DSA    87   verify        22 ops took 1.024 sec, avg 46.545 ms, 21.484 ops/sec [heap 11432 bytes (1 allocs), stack 1416 bytes]
Benchmark complete

Better rendering

If you find this data a little complicated to read at a glance, there are two things that can help you. The first is that the wolfCrypt benchmark can be configured to output CSV data; this additional memory tracking will appear in the CSV results. Alternatively, we have a Python script which can reinterpret the benchmark data into a nice table format. Currently, the Python rendering script targets the STM32U585 demo, but it can be easily adapted for other platforms upon request.

Conclusion

With this new enhancement, wolfCrypt users can now quantify both performance and memory footprint under different compile-time configurations. This is especially valuable for post-quantum cryptography and embedded use cases where memory efficiency is critical.

For now this works with bare-metal and POSIX systems, but we intend to adapt it to work with other operating systems, including RTOSs, in the future.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

The Cyclone V, a cost-effective System-on-Chip (SoC) FPGA from Altera, combines a dual-core ARM Cortex-A9 processor (Hard Processor System, HPS) with a range of FPGA fabric configurations, tailored to specific family SKUs.

It can be used with a variety of Real-Time Operating Systems (RTOS), including VxWorks, FreeRTOS, and Azure RTOS, as well as embedded Linux distributions like Yocto and Buildroot. wolfSSL is optimized for these platforms, offering secure communication with TLS v1.3 and DTLS v1.3, secure boot capabilities with wolfBoot, and FIPS 140-3 cryptography. It can fully replace cryptographic operations in embedded Linux, providing a comprehensive FIPS-approved solution for both user space and kernel space.

Additionally, wolfSSL can provide a Hardware Security Module (HSM) solution with wolfHSM on the Cyclone V. By leveraging the Nios II or RISC-V-based Nios V soft-core processor in the FPGA fabric, wolfHSM can be used to provide a dedicated fabric based security module for the Cyclone V.

Cyclone V Cortex-A9 @ 800 MHz on Yocto Linux Scarthgap Benchmarks


Benchmarks are collected from our public benchmarking tool and compiled with -O2 optimization for both the benchmarking app and wolfSSL library. C benchmarking results are collected using a standard ./configure build of the wolfSSL library, and ARM Assembly results benchmarks are collected with a ./configure –enable-armasm build of the library.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now

We love what we do at wolfSSL, to the extent that some of our official projects are even born out of personal side-projects. In that vein, I would like to introduce a demonstration board designed to showcase wolfSSL products at expos. A board we are calling “wolfDemo”.

About Me

For this blog post, I’m going to do something a little different. This is a personal project, and as such, you should probably know a little about the person behind it. My name is Andrew Hutchings, I have an extensive engineering background, and in my spare time, I design new circuit boards for vintage computers.
I was part of the wolfSSL team at Embedded World 2025. This is a photo of the team there, I’m the one in the light-blue jeans.

I’m also wearing a badge here, which I designed, which is an entirely custom board using an RP2040 microcontroller and power management/battery management hardware. It uses a highly optimised OLED driver and graphics library firmware I wrote for it.

At Embedded World, we were showcasing various wolfSSL products running on stock development boards. It was here I had the thought “what if we had our own development board?”. In my hotel room, I got to work on planning and designing. There are some basic requirements I wanted to target:

• It had to have wolfSSL branding and draw attention.
• It had to have mikroBus sockets. Pretty much every expansion possible is available in the open mikroBus standard.
• It should be easy to use for people who are not as experienced in embedded development.
• It should have a Tag-Connect connector for the JTAG. This is just a personal thing, I use Tag-Connect everywhere.

I quickly settled on the STM32U585 for this board. It has a lot of flash and RAM, hardware crypto acceleration for AES and SHA-256, it is quite fast (Cortex-M33 at 160MHz) and relatively inexpensive. I’ve also developed ST based boards before. So, whilst I figured that I would end up doing boards with other manufacturer’s MCUs, this would be a lower barrier to a first version.

The wolfDemo Board

The final version of the board I think met all my requirements. I used various aspects of the PCB to make the wolfSSL logo and put four addressable cyan LED sections underneath the board to glow for the wolf’s bark, one section for each of the curved bars for the bark. You can see the third from the right bar glowing in the photo above. There are two mikroBus sockets, two input buttons, and a USB to UART for getting log data or flashing the board. It even has Tag-Connect for JTAG, as well as an option for a 10-pin ARM Cortex JTAG header.
In addition, I created a mikroBus click board for the ST33 TPM.

Better Demos

Now that we have a board, we need demos to run on it. We have the wolfCrypt benchmark, it is a great way to show how fast wolfCrypt runs on various platforms. But, at a casual glance in an expo environment, it isn’t the easiest to understand. So, I made some improvements…

Behind the scenes, there is the regular wolfCrypt benchmark running underneath. Although there is a new feature I wrote to show the heap / stack usage for each algo. The front end you are seeing here is a Python script that listens on the USB serial port and processes the results in real-time, rendering it into the table. Also, for an added visual touch, as each log line is sent from the board, the wolf bark LED changes.

What’s Next!

This is not something we will be selling. I’m going to be making more boards in my spare time and sending them to the rest of the team. In fact, I’ve sent some already and have a batch ready to go. This way we can show demos on the board at more events. We have also made the design files and examples publicly available.

There will definitely be more demos. I showed the board for the first time at it-sa in Nuremberg, and partners have already approached us saying that they would like demos of their technology on it. With the mikroBus sockets, we can show wolfSSL’s products running whilst connected to hundreds of different hardware boards.

I will also be designing variants using MCUs from other companies, so that we can show that wolfSSL’s products are extremely versatile.

If you are coming to an event, and wolfSSL is there. Lookout for demos using the wolfDemo board!

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now

We are thrilled to announce a significant enhancement to the wolfSSL repository: the addition of Rust wrappers for wolfCrypt! This integration, available now in our official wolfSSL GitHub repository, allows developers to leverage the robust cryptographic primitives of wolfCrypt directly within their Rust applications, benefiting from Rust’s safety, performance, and modern language features.

Why Rust

Rust has rapidly gained popularity for its focus on safety, particularly memory safety, without sacrificing performance. Its strong type system and ownership model prevent common programming errors like null pointer dereferences and data races, making it an ideal choice for building secure and reliable software. Cryptographic implementations, in particular, demand the highest levels of correctness and security, which align perfectly with Rust’s design principles.

Introducing wolfCrypt Rust Wrappers

The new Rust wrappers provide a safe and idiomatic interface to wolfCrypt’s comprehensive suite of cryptographic algorithms. Rust wrapper development is an ongoing effort and more functionality is planned. Initially Rust wrappers are targeting the wolfCrypt FIPS API. Currently, developers can now easily integrate features such as:

• Asymmetric Cryptography: RSA and ECC
• Symmetric Ciphers: AES
• Hashing: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256
• Key Exchange: Diffie-Hellman, ECDH
• Random Number Generation: FIPS 140-2 certified random number generator (RNG)

More Rust wrappers for functionality such as HMAC, CMAC, KDF, Ed25591, and Ed448, and more are planned.

Key Benefits

• Memory Safety,/strong>: Rust’s ownership and borrowing system eliminates common memory-related vulnerabilities that plague C/C++ implementations, such as buffer overflows and use-after-free errors.
• Thread Safety: The Rust type system prevents data races, ensuring that cryptographic operations are safe in multi-threaded environments.
• Performance: wolfCrypt is renowned for its small footprint and high performance, and these characteristics are preserved when used through the Rust wrappers.
• Ease of Use,/strong>: The wrappers are designed to be intuitive and follow Rust’s best practices, making it straightforward for Rust developers to incorporate powerful cryptography into their projects.
• FIPS 140-2 Compliance: Leverage wolfCrypt’s FIPS 140-2 validated cryptographic modules directly from Rust.

Getting Started

Integrating the wolfCrypt Rust wrappers into your project is simple. You can find the necessary files and detailed instructions within the wolfSSL GitHub repository in the wrapper/rust directory.

Example Usage
Here’s a sneak peek at how easy it is to use the new wrappers (specific API details can be found in the repository).

RNG

use wolfssl::wolfcrypt::random::RNG;

fn main() {
    // Create a RNG instance.
    let mut rng = RNG::new().expect("Failed to create RNG");

    // Generate a single random byte value.
    let byte = rng.generate_byte().expect("Failed to generate a single byte");

    // Generate a random block.
    let mut buffer = [0u32; 8];
    rng.generate_block(&mut buffer).expect("Failed to generate a block");
}

SHA-256

use wolfssl::wolfcrypt::sha::SHA256;

fn main() {
    // Create a SHA256 instance.
    let mut sha = SHA256::new().expect("Error with new()");

    // Feed input data (can be called multiple times).
    sha.update(b"input").expect("Error with update()");

    // Retrieve the final SHA-256 hash.
    let mut hash = [0u8; SHA256::DIGEST_SIZE];
    sha.finalize(&mut hash).expect("Error with finalize()");
}

ECC

use wolfssl::wolfcrypt::random::RNG;
use wolfssl::wolfcrypt::ecc::ECC;

fn main () {
    let mut rng = RNG::new().expect("Failed to create RNG");

    // Generate a new ECC key.
    let mut ecc = ECC::generate(32, &mut rng).expect("Error with generate()");
    let hash = [0x42u8; 32];
    let mut signature = [0u8; 128];

    // Sign a hash with the ECC key.
    let signature_length = ecc.sign_hash(&hash, &mut signature, &mut rng).expect("Error with sign_hash()");
    let signature = &signature[0..signature_length];
}

Community and Support

We encourage the Rust community to explore these new wrappers and provide feedback. Your contributions and insights are invaluable as we continue to improve and expand our offerings. If you encounter any issues or have suggestions, please open an issue or submit a pull request on our GitHub repository.

What’s Next?

wolfSSL is committed to enhancing the security and usability of our products across various platforms and languages. The introduction of Rust wrappers is a testament to this commitment. We plan to continue expanding the functionality and improving the developer experience for our Rust users.

Stay tuned for more updates and exciting developments from wolfSSL!

Useful Links

• wolfSSL GitHub Repository
• Official wolfSSL Website
• Contact Us

If you have any questions, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247. We look forward to seeing what you build with wolfCrypt and Rust!
Download wolfSSL Now

There are three build options for crypto operations when using wolfSSL on Xilinx/AMD Ultrascale+ devices. The lightweight wolfSSL library can use a software only implementation, make use of the ARMv8 crypto extensions along with custom ARM assembly, or offload the operation to the CSU. Each has its trade offs. Recently wolfSSL has made improvements to the ARMv8 optimizations for use with AES-GCM operations.

• Offloading to the CSU (labeled here as the hardened option) free’s up the CPU for other operations and it leverages the hardening available which provides enhancements like additional protections against DPA (differential power analysis)
• ARMv8 crypto extensions is very performant for smaller block sizes and can be taken through a FIPS OE with use of PAA (Processor Algorithm Acceleration)

The following tables are raw numbers of the throughput collected. Collecting the performance on even larger block sizes would show that Xilinx/AMD hardened crypto accelerators continue on linearly until reaching their maximum. The hardened numbers were collected previously using FreeRTOS, the software and ARMv8 were collected while running on Petalinux with the latest wolfSSL version 5.8.2. A VMK180 Versal board was used.

For RSA operations the following chart shows performance differences using a 4096 bit key for private key operations. SP stands for Single Precision.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call +1 425 245 8247.
Download wolfSSL Now

wolfSSL continues to expand its hardware security ecosystem with significant new additions over the past year. Here are the latest keystores and secure elements now supported by our cryptographic library:

New Secure Element Support

TROPIC01 Secure Element
wolfSSL now includes dedicated crypto callback functions for the TROPIC01 secure element, providing seamless hardware-backed cryptographic operations for enhanced security applications.

Enhanced STM32 Hardware Security

STM32MP135F Platform
Complete hardware acceleration suite featuring:

• STM32CubeIDE integration
• Hardware Abstraction Layer (HAL) support for SHA-2 and SHA-3
• AES hardware acceleration
• Hardware RNG integration
• ECC cryptographic operations

Additional STM32 Variants

• STM32H5 – Advanced performance microcontroller with enhanced security features
• STM32WBA – Wireless connectivity focused platform for IoT security
• STM32G4 – General purpose microcontroller series with crypto acceleration
• STM32U575xx – Ultra-low-power microcontroller boards for battery-powered secure devices
• STM32 Cube Expansion Pack – Enhanced development environment support

Expanded Renesas Security Solutions

Renesas TSIP v1.15
Enhanced support for RX65N and RX72N platforms including:

• RSA Public Encrypt and Private Decrypt operations
• AES-CTR mode hardware acceleration
• Improved cryptographic performance

Renesas SCE Integration
New crypto-only RSA support providing dedicated hardware acceleration without requiring full TLS integration.

Development Board and Platform Support

Raspberry Pi Enhanced Support

• RP2350 – Latest generation with enhanced RNG optimizations
• RP2040 – Improved support with performance-optimized random number generation

RISC-V Platform

• SiFive HiFive Unleashed Board – Complete RISC-V development board support for hardware-accelerated cryptography

Operating System and Bootloader Integration

Zephyr Project RTOS
Full integration with the Zephyr real-time operating system, including:

• TPM usage examples
• Hardware security integration
• Real-time cryptographic operations

U-Boot Bootloader
Secure boot integration supporting:

• TPM-based measured boot
• Hardware security module validation
• Boot integrity verification

Microchip Harmony (MPLABX)
Complete development ecosystem support including:

• SPI HAL integration
• Benchmarking tools
• Development environment optimization

Advanced Infineon Security Features

Infineon TriCore (TC2XX/TC3XX)
Hardware security module support with comprehensive TPM integration using the WOLFTPM_INFINEON_TRICORE macro.
Infineon SLB9672/SLB9673
Advanced TPM modules featuring:

• Secure firmware update capabilities
• Enhanced I2C communication
• Industrial-grade security certification

Infineon Development Tools

• Modus Toolbox – Integrated development environment
• CyHal I2C/SPI – Hardware abstraction layer support

Additional TPM Hardware

Nations NS350
New TPM 2.0 module support expanding our certified hardware ecosystem for secure applications.
Memory Mapped I/O (MMIO) TPMs
Direct memory access support for TPM modules, enabling:

• Faster cryptographic operations
• Reduced system overhead
• Simplified hardware integration

Development Environment Enhancements

Espressif IDE Support
Complete integration with Espressif’s development environment for ESP32 and related platforms.
Windows Visual Studio
New project templates and GitHub Actions testing for Windows development environments.

Advanced Security Features

Pre-provisioned Device Identity Keys
Support for manufacturer-provisioned security credentials, enabling:

• Zero-touch device provisioning
• Factory-sealed security credentials
• Simplified device authentication

Secure Firmware Update
Advanced firmware update capabilities for supported TPM modules with cryptographic verification and rollback protection.

Getting Started

These new hardware security features are available in wolfSSL version 5.7.0 and later, with wolfTPM version 3.0.0 and later. To enable support for your specific platform, consult our documentation or contact our technical support team.
The expanded hardware support demonstrates wolfSSL’s commitment to providing comprehensive security solutions across embedded systems, IoT devices, and enterprise applications.

Questions?

If you have questions about any of the above, please contact us at facts@wolfssl.com, call us at +1 425 245 8247, or visit our FAQ page for more information.
Download wolfSSL Now

At wolfSSL we support hardware cryptography for a wide range of platforms. The benefits of hardware cryptography include reduced code footprint size, improved security, acceleration of cryptographic operations, and utilization of . For example, this allows everything from wolfBoot to TLS cipher suites to enjoy acceleration of cryptographic operations.

Furthermore, we have deep partnerships with industry leaders such as Intel, NXP, and Renesas. We support standard Intel instruction extensions such as AES-NI, AVX, and ADX and BMI2, and have recently published a joint whitepaper on using wolfBoot with 11th Gen Intel Core processors. We also support NXP’s Cryptographic Accelerator and Assurance Module (CAAM), and have leveraged this for hardware acceleration on a number of NXP i.MX series processors. Other examples include Espressif and Analog Devices, to name but a few.

If you’re curious for a list of every hardware cryptography scheme and platform we have enabled, then read on:

• AES-NI: Intel 64 and IA-32 Xeon and Core, and AMD Zen processor families.
  

  AES–GCM	128, 192, 256 bit
  AES–CCM	128, 192, 256 bit
  AES–CBC	128, 192, 256 bit
  AES–ECB	128, 192, 256 bit
  AES–CTR	128, 192, 256 bit

  References:

  1. White Paper: Applying wolfBoot to 11th Gen Intel Core Processors for Secure Boot

• AVX1/AVX2: Intel and AMD x86.
  

  SHA3, SHA2	SHA-256, SHA-384, SHA-512
  AES–GCM	128, 192, 256 bits
  ChaCha20-Poly1305	256 bit AEAD stream cipher
  Poly1305

  References:

  1. https://www.wolfssl.com/wolfssl-performance-intel-x86_64-part-2/
  2. https://www.wolfssl.com/wolfssl-performance-intel-x86_64-part-3/
  3. https://www.wolfssl.com/intels-extended-instructions-accelerates-hash-algorithms/

• Intel ADX and BMI2: Intel and AMD x86.
  

  RSA
  Curve25519	256 bit
  Ed25519	256 bit

  References:

  1. https://www.wolfssl.com/wolfssl-performance-intel-x86_64-part-5/
  2. https://www.wolfssl.com/wolfssl-performance-intel-x86_64-part-6/

• RDRAND/RDSEED: Intel 64 and IA-32, and AMD Zen processor families.
  

  RNG

  References:

  1. https://www.intel.com/content/www/us/en/developer/articles/guide/intel-digital-random-number-generator-drng-software-implementation-guide.html
  2. https://www.amd.com/content/dam/amd/en/documents/pdfs/developer/aocl/amd-secure-random-number-generator-library-2.0-whitepaper.pdf

• Platform Security Architecture (PSA) Crypto API:
  

  AES–GCM	128, 192, 256 bit
  AES–CCM	128, 192, 256 bit
  AES–CBC	128, 192, 256 bit
  AES–ECB	128, 192, 256 bit
  AES–CTR	128, 192, 256 bit
  SHA2	SHA-224, SHA-256
  SHA1
  ECC	256 bit (NIST-P256)
  RNG

  References:

  1. https://www.wolfssl.com/platform-security-architecture-psa-crypto-api-support-wolfssl/
  2. https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src/port/psa

• NXP Coldfire SEC: (MCF547X and MCF548X family of processors)
  

  AES–CBC	128, 192, 256 bit
  3DES–CBC	192 bit
  DES–CBC	64 bit

  References:

  1. https://www.wolfssl.com/docs/nxp/

• NXP Coldfire CAU/mmCAU: (NXP Coldfire and Kinetis)
  

  AES–GCM	128, 192, 256 bit
  AES–CCM	128, 192, 256 bit
  AES–CBC	128, 192, 256 bit
  AES–ECB	128, 192, 256 bit
  AES–CTR	128, 192, 256 bit
  3DES–CTR
  SHA2	SHA-256
  SHA1
  HMAC	SHA1, SHA2
  MD5

  References:

  1. https://www.wolfssl.com/docs/nxp/
  2. https://www.wolfssl.com/improved-nxp-mmcau-crypto-hardware-performance/
  3. https://www.wolfssl.com/improved-nxp-mmcau-crypto-hardware-performance-2/

• STMicroeletronics: STM32MP135
  

  AES–GCM	128, 192, 256 bit
  AES–CCM	128, 192, 256 bit
  AES–CTR	128, 192, 256 bit
  AES–CBC	128, 192, 256 bit
  DES/3DES–CBC	64 bit / 192 bit
  SHA2	SHA-224, SHA-256, SHA-384, SHA-512
  SHA3
  RNG

  References:

  1. https://www.wolfssl.com/wolfssl-on-stm32-mpus/

• STMicroeletronics: STM32H753ZI, STM32H573I, STM32F437, STM32F777, STM32L4A6Z, STM32L562E, STM32U585
  

  AES–CCM	128, 192, 256 bit
  AES–GCM	128, 192, 256 bit
  AES–CTR	128, 192, 256 bit
  AES–CBC	128, 192, 256 bit
  DES/3DES–CBC	64 bit / 192 bit
  SHA2	SHA-224, SHA-256
  RNG

  References:

  1. https://github.com/wolfSSL/wolfssl/blob/master/IDE/STM32Cube/STM32_Benchmarks.md
  2. https://www.wolfssl.com/docs/benchmarks/#stm32
  3. https://www.wolfssl.com/docs/benchmarks/#stm32f777ni
  4. https://www.wolfssl.com/wolfboot-on-stm32h5-enhancing-secure-boot-with-trustzone-m/

• STMicroeletronics: STM32WBA52, STM32WB55, STM32WL55
  

  AES–GCM	128, 192, 256 bit
  AES–CCM	128, 192, 256 bit
  AES–CTR	128, 192, 256 bit
  AES–CBC	128, 192, 256 bit
  SHA2	SHA-256
  ECC	256 bit (NIST-P256)
  RNG

  References:

  1. https://github.com/wolfSSL/wolfssl/blob/master/IDE/STM32Cube/STM32_Benchmarks.md
  2. https://www.wolfssl.com/support-stm32_pka-accelerator/
  3. https://www.wolfssl.com/announcing-stm32wba-support-in-wolfssl/

• Marvell (Cavium) Nitrox V and III:
  

  AES–GCM	128 bit
  AES–CBC	128, 192, 256 bit
  RSA	2048 bit
  ECC
  ECDSA
  RNG

  References:

  1. https://www.wolfssl.com/wolfssl-asynchronous-support/
  2. https://www.wolfssl.com/wordpress/wp-content/uploads/2018/04/wolfssl_async.pdf

• Marvell (Cavium) Octeon II/III:
  

  AES–GCM	128, 192, 256 bit
  AES–CBC	128, 192, 256 bit
  3DES–CBC

  References:

  1. https://www.wolfssl.com/wolfssl-on-cavium-octeon/
  2. https://github.com/wolfSSL/wolfAsyncCrypt/blob/master/wolfcrypt/src/port/cavium/README_Octeon.md

• Microchip PIC32 MX/MZ:
  

  AES–CTR	128, 192, 256 bit
  AES–CBC	128, 192, 256 bit
  DES/3DES–CBC	64 bit / 192 bit
  SHA2	SHA-256
  SHA1
  HMAC	SHA1, SHA2
  MD5

  References:

  1. https://www.wolfssl.com/docs/pic32/

• Texas Instruments Crypto Connected Launchpad: (TI TM4C series boards)
  

  AES–GCM	128, 192, 256 bit
  AES–CCM	128, 192, 256 bit
  AES–CBC	128, 192, 256 bit
  AES–ECB	128, 192, 256 bit
  AES–CTR	128, 192, 256 bit
  DES–CBC	64 bit
  3DES–CBC	192 bit
  SHA2	SHA-224, SHA-256
  SHA1
  MD5

  References:

  1. https://www.ti.com/lit/ug/spmu372a/spmu372a.pdf
  2. https://www.ti.com/tool/EK-TM4C129EXL

• Nordic NRF5x:
  

  AES–ECB	128 bit
  RNG

  References:

  1. https://www.wolfssl.com/true-random-vs-pseudorandom-number-generation/
  2. https://www.wolfssl.com/wolfssl-on-nordic-nrf52/

• Microchip/Atmel ATECC508A/ATECC608A:
  

  ECC	256 bit (NIST-P256)

  References:

  1. https://www.wolfssl.com/docs/atmel/
  2. https://www.wolfssl.com/wolfssl-support-atecc508aatecc608a-crypto-coprocessor-2/
  3. https://www.wolfssl.com/using-wolfssl-on-the-atmel-atecc508a-with-tls-1-3-tls13/

• Espressif ESP32: ESP32, ESP32-C3, ESP32-C6, ESP32-S2, ESP32-S3
  

  AES–GCM	128, 192, 256 bits
  AES–CBC	128, 192, 256 bits
  RSA	Up to 4096 bits
  SHA2	SHA-224, SHA-256, SHA-384, SHA-512
  SHA1
  RNG

  Note: Support for all AES/RSA bit sizes and truncated SHA2 acceleration will vary across devices. E.g. no AES-192 HW on the S2, S3, and no SHA-384, SHA-512 HW support on C3, C6. Consult the user_settings.h in reference 3 for more info.

  References:

  1. https://www.wolfssl.com/docs/espressif/
  2. https://www.wolfssl.com/espressif-risc-v-hardware-accelerated-cryptographic-functions-up-to-1000-faster-than-software/
  3. https://github.com/wolfSSL/wolfssl/blob/master/IDE/Espressif/ESP-IDF/examples/template/components/wolfssl/include/user_settings.h

• ARMV8:
  

  AES–GCM	128, 192, 256 bits
  AES–CCM	128, 192, 256 bits
  AES–CBC	128, 192, 256 bits
  SHA256

  Referenece:

  1. https://www.wolfssl.com/wolfssl-on-armv8-lemaker-2/

• Arm® TrustZone® CryptoCell-310: nRF52840
  

  RSA	2048 bits
  AES–CBC	128, 192, 256 bit
  ECC	256 bit
  ECDSA	256 bit
  SHA256
  SRNG

  Reference:

  1. https://www.wolfssl.com/wolfssl-adds-support-arm-trustzone-cryptocell-310/
     

• Intel QuickAssist Technology:
  

  RSA	2048 bits
  AES–GCM	128, 192, 256 bits
  AES–CBC	128, 192, 256 bits
  3DES
  SHA2	SHA-256, SHA-384, SHA-512
  SHA1
  HMAC	SHA1, SHA2
  MD5

  Reference:

  1. https://www.wolfssl.com/wolfssl-asynchronous-intel-quickassist-support/

• NXP LTC (KSDK):
  

  AES–GCM	128, 192, 256 bit
  AES–CCM	128, 192, 256 bit
  AES–CBC	128, 192, 256 bit
  AES–ECB	128, 192, 256 bit
  AES–CTR	128, 192, 256 bit
  DES/3DES
  ECC	256 bit
  ECDSA	256 bit
  Curve25519	256 bit
  Ed25519	256 bit
  SHA2	SHA-256, SHA-384, SHA-512
  SHA1
  HMAC	SHA1, SHA2
  MD5

  Reference:

  1. https://www.wolfssl.com/docs/nxp/
  2. https://www.wolfssl.com/nxp-kinetis-k8x-ltc-support-for-pki-rsaecc-with-tls13/

• NXP SE050:
  

  ECC	256 bit
  ECDSA	256 bit
  Curve25519	256 bit
  Ed25519	256 bit
  RNG

  Reference:

  1. https://www.wolfssl.com/ssltls-support-nxp-se050-wolfssl/
  2. https://www.wolfssl.com/wolfssl-nxp-se050-support-update/
  3. https://www.wolfssl.com/wolfssl-support-nxp-se050-scp03/
  4. https://www.wolfssl.com/wolfssl-nxp-se050-support-benchmarks/

• CAAM: NXP i.MX 6, i.MX 7, and i.MX 8
  

  AES–GCM	128, 192, 256 bits
  AES–CCM	128, 192, 256 bits
  AES–CTR	128, 192, 256 bits
  AES–XTS	128, 192, 256 bits
  ECC
  Curve25519	256 bit
  SHA2	SHA-256, SHA-384, SHA-512
  SHA1
  HMAC	SHA1, SHA2

  Reference:

  1. https://www.wolfssl.com/caam-supported-wolfssl/
  2. https://www.wolfssl.com/docs/benchmarks/#nxp_i.mx6
  3. https://www.wolfssl.com/mx6-caam-integrity-os/
  4. https://www.wolfssl.com/caamqnxi-mx8/

• Silicon Labs EFR32:
  

  AES–GDM	128, 192, 256 bit
  AES–CCM	128, 192, 256 bit
  AES–CBC	128, 192, 256 bit
  SHA2	SHA-224, SHA-256
  SHA1
  ECC	256 bit
  ECDSA	256 bit
  RNG

  Reference:

  1. https://www.wolfssl.com/wolfssl-adds-silicon-labs-hardware-acceleration-support/

• Renesas RX65N and RX72N:
  

  AES–GCM	128, 256 bit
  AES–CBC	128, 256 bit
  SHA2	SHA-256, SHA-512
  SHA1
  HMAC	SHA1, SHA2
  RNG

  Reference:

  1. https://www.wolfssl.com/docs/renesas/
  2. https://www.wolfssl.com/docs/wolfssl-renesas-tsip/
  3. https://www.wolfssl.com/support-renesas-tsip-v1-13-rx72n/
  4. https://www.wolfssl.com/docs/benchmarks/#renesasrx65n

• Renesas Synergy DK-S7G2:
  

  RSA	2048 bits
  AES–CBC	128 bit
  SHA2	SHA-256
  SHA1
  HMAC	SHA1, SHA2
  ECC	256 bit
  ECDSA	256 bit

  Reference:

  1. https://www.wolfssl.com/docs/benchmarks/#renesasrx71m

• Cypress PSoC6 (32-bit Arm Cortex M4):
  

  SHA2	SHA-256, SHA-512
  ECC	Supports up to NIST P-521

• Xilinx Versal:
  

  AES–GCM		256 bit
  RSA		2048 bit
  ECC		NIST P-384, P-521
  SHA3		SHA-384
  RNG

  Reference:

  1. https://www.wolfssl.com/versal-support/

• Xilinx Zynq UltraScale+ MPSoC:tr>RNGSHA-384
  

  AES–GCM	256 bit
  RSA	256 bit
  ECC	NIST P-384, P-521
  SHA3	SHA-384

  Reference:

  1. https://www.wolfssl.com/versal-support/

• Xilinx Zynq UltraScale+ MPSoC
  

  AES–GCM	256 bit
  RSA	2048, 4096 bits
  SHA3	SHA-384

  Reference:

  1. https://www.wolfssl.com/wolfssl-running-xilinx-versal-hardware-encryption/
  2. https://docs.xilinx.com/v/u/en-US/wp512-accel-crypto
  3. https://docs.xilinx.com/v/u/en-US/wp512-accel-crypto

• MAXQ1065 and MAXQ1080:
  

  AES–GCM	128, 192, 256 bit
  AES–CCM	128, 192, 256 bit
  ECC	NIST-P256
  ECC	SHA-256

  Reference:

  1. https://www.wolfssl.com/support-maxq1065-wolfssl

• MAX32665 and MAX32665:
  

  AES–	>128, 192, 256 bit
  AES–GCM/td>	>128, 192, 256 bit
  RSA/td>
  ECC/td>	NIST-P256
  SHA2/td>	SHA-256

  Reference:

  1. a href=”https://www.wolfssl.com/max32666-and-max32665-hardware-acceleration-added-to-wolfssl/”>https://www.wolfssl.com/max32666-and-max32665-hardware-acceleration-added-to-wolfssl/

Do you have a platform requiring hardware cryptographic support that isn’t on our list? Or are you curious about benchmarking? Reach out to us at facts@wolfssl.com with the details of your platform and we will be glad to help you! Also, check out our wolfSSL and wolfCrypt benchmark page.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now

wolfSSL is an embedded cryptographic library that includes a TLS/DTLS implementation. For resource-constrained devices or safety-critical applications, dynamic memory allocation via malloc and free system calls may be unavailable. To address these scenarios, wolfSSL offers the –enable-staticmemory feature. This feature provides a robust and straightforward allocation mechanism as an alternative. It utilizes a pre-allocated buffer, segmenting it into sections that applications can acquire by calling XMALLOC and release back to the memory pool using XFREE.

To activate this feature, compile wolfSSL using ./configure –enable-staticmemory or, if utilizing a user_settings.h file, define WOLFSSL_STATIC_MEMORY. Subsequently, execute make. Following compilation, the application must invoke wc_LoadStaticMemory to designate the buffer for partitioning and utilization, and then transmit the resulting “heap hint” to all XMALLOC and XFREE calls. By default, XMALLOC and XFREE calls will revert to the system’s malloc and free if no “heap hint” is provided. To circumvent all system malloc and free calls, the macro WOLFSSL_NO_MALLOC can be defined. For instance, this can be achieved via ./configure –enable-staticmemory CPPFLAGS=-DWOLFSSL_NO_MALLOC.

An additional option available, introduced in wolfSSL version 5.7.0 and subsequent releases, is the utilization of a globally defined “heap hint.” This global heap hint is established by invoking the setter function void* wolfSSL_SetGlobalHeapHint(void* heap). Consequently, any invocation of XMALLOC or XFREE that receives a NULL pointer as the “heap hint” will default to employing the globally configured “heap hint” pointer.

Setting up the memory sizes to use for each of the sections can be a difficult problem. To help some with a base configuration of the memory sizes there is a relatively new memory “bucket” optimizer tool located in the wolfssl-examples repository. It takes in the logging output of memory allocation calls from an application and provides a suggested static memory configuration based on the results. It’s possible in some cases to get even more optimized with the configuration but this example application gives a very good starting point.

The following is an example output when providing the memory logs of testwolfcrypt to the optimizer:

Building wolfSSL and collecting memory usage logs

$ ./configure --enable-staticmemory CPPFLAGS="-DWOLFSSL_DEBUG_MEMORY -DWOLFSSL_DEBUG_MEMORY_PRINT" -q && make > /dev/null && ./wolfcrypt/test/testwolfcrypt &> testwolfcrypt.log

Running the optimizer application on the resulting memory usage log

$ make
gcc  -o memory_bucket_optimizer memory_bucket_optimizer.c -lwolfssl

$./memory_bucket_optimizer testwolfcrypt.log 
Found 24 unique allocation sizes
Peak heap usage: 60074 bytes (maximum concurrent memory usage)
Allocation Sizes, Frequencies, and Concurrent Usage:
Size    Count   Max Concurrent
----    -----   --------------
4208    1       1
3128    914     19
2112    85      1
1600    13      1
1120    13      1
1040    1       1
1024    4       2
800     37      1
257     65      2
256     9       1
235     7       1
227     5       1
223     5       1
207     5       1
191     5       1
136     5       1
128     8       1
104     5       1
72      5       1
64      6       1
48      5       1
32      2       1
28      1       1
0       0       0
Optimization Summary:
Padding size per bucket: 32 bytes
Maximum unique buckets allowed: 9
Total buckets created: 9
Note: Reached maximum bucket limit (9). Some allocations may use larger buckets.
Note: Allocations with waste < padding size use existing buckets to reduce overhead
Note: Bucket limit helps balance memory efficiency vs. management overhead
Optimized Bucket Sizes and Distribution:
Data Size + Padding = Bucket Size    Dist
----------------------------------------
272     + 32      = 304            2
800     + 32      = 832            1
1024    + 32      = 1056           2
1040    + 32      = 1072           1
1120    + 32      = 1152           1
1600    + 32      = 1632           1
2112    + 32      = 2144           1
3136    + 32      = 3168           19
4208    + 32      = 4240           1
WOLFMEM_BUCKETS and WOLFMEM_DIST Macros:
#define WOLFMEM_BUCKETS 304,832,1056,1072,1152,1632,2144,3168,4240
#define WOLFMEM_DIST 2,1,2,1,1,1,1,19,1
Memory Efficiency Analysis:
Note: Allocations with waste < 32 bytes (padding size) use existing buckets
Size    Count   Concurrent Bucket   Waste   Coverage
----    -----   ---------- ------   -----   --------
4208    1       1          4240    0       ?
3128    914     19         3168    8       ?
2112    85      1          2144    0       ?
1600    13      1          1632    0       ?
1120    13      1          1152    0       ?
1040    1       1          1072    0       ?
1024    4       2          1056    0       ?
800     37      1          832     0       ?
257     65      2          304     15      ?
256     9       1          304     16      ?
235     7       1          304     37      ?
227     5       1          304     45      ?
223     5       1          304     49      ?
207     5       1          304     65      ?
191     5       1          304     81      ?
136     5       1          304     136     ?
128     8       1          304     144     ?
104     5       1          304     168     ?
72      5       1          304     200     ?
64      6       1          304     208     ?
48      5       1          304     224     ?
32      2       1          304     240     ?
28      1       1          304     244     ?
0       0       0          304     272     ?
Efficiency Summary:
Total allocations: 1206
Allocations handled: 1206 (100.0%)
Total memory waste: 16654.00 bytes
Average waste per allocation: 13.81 bytes
Total bucket memory: 73984 bytes
Memory overhead: 1239 bytes
  - Padding per bucket: 32 bytes (included in bucket sizes)
  - Heap structures: 296 bytes
  - Alignment: 15 bytes
Total memory needed: 75223 bytes
Data memory: 3141010 bytes
Buffer Size Recommendations:
============================
Minimum buffer size needed: 75224 bytes
Usage in wolfSSL application:
============================
// Allocate buffer
byte staticBuffer[75224];
// Load static memory
WOLFSSL_HEAP_HINT* heapHint = NULL;
if (wc_LoadStaticMemory_ex(&heapHint, 9, bucket_sizes, bucket_dist,
    staticBuffer, 75224, 0, 0) != 0) {
    // Handle error
}
// Use in wolfSSL context
wolfSSL_CTX_load_static_memory(&method, NULL, staticBuffer,
    75224, 0, 1);

Additional documentation about the staticmemory feature can be found in the wolfSSL manual.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now