Category: wolfSSL/ wolfCrypt

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

The Radio Equipment Directive (RED) 2014/53/EU establishes the regulatory framework for placing radio equipment on the European market. Its goal is to create a unified market while ensuring essential requirements for safety, electromagnetic compatibility, efficient use of the radio spectrum, and more recently cybersecurity and data protection.

To strengthen protections, the European Commission activated Articles 3(3)(d), (e), and (f), which address cybersecurity, privacy, and fraud prevention for certain categories of connected devices. In addition, Articles 3(3)(i) and 4 focus on ensuring that radio equipment remains compliant and interoperable when software updates or modifications are introduced.

These developments overlap with the Cyber Resilience Act (CRA), which will shift some cybersecurity requirements away from RED. Still, RED remains critical, particularly for compliance related to software updates and radio equipment security.

wolfSSL and RED Compliance

• Lightweight TLS/crypto for constrained devices
• FIPS 140-3 validated wolfCrypt for compliance-focused markets
• Support for modern protocols and algorithms, including Post-Quantum Cryptography
• Open source allows third party audits

wolfSSL delivers the security foundation that helps manufacturers align with RED today, and adapt to future changes tomorrow.

If your team is navigating RED compliance or preparing for CRA, or have questions about any of the above, please contact us at facts@wolfssl.com or call +1 425 245 8247.

Download wolfSSL Now

In wolfCrypt and wolfPKCS11 we added support for using a Derived Hardware Unique Key (DHUK) for AES with the STM32U5.

This feature enables use of a device unique AES key (up to 256-bit) available for encryption/decryption. The key cannot be read from the hardware, which makes it great to wrap other symmetric keys for storage and greatly improves security.

In wolfPKCS11 a nice example was added showing how the DHUK can be used to wrap an AES key and then make use of that wrapped key for encryption and decryption. Both wrapping with AES-ECB and AES-CBC modes are supported.

Check out the wolfPKCS11 Example and wolfCrypt Feature PR.

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

Recent commits to wolfSSL have enabled support to decode new CMS/PKCS#7 message types.

The CMS message type EncryptedKeyPackage (defined in RFC 6032) can be decoded with the new API .

The CMS message types SymmetricKeyPackage and OneSymmetricKey (defined in RFC 6031) can be decoded with the new APIs

wc_PKCS7_DecodeSymmetricKeyPackageAttribute(),
wc_PKCS7_DecodeSymmetricKeyPackageKey(),
wc_PKCS7_DecodeOneSymmetricKeyAttribute(), and
wc_PKCS7_DecodeOneSymmetricKeyKey().

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

Previous wolfSSL versions required X.963 KDF support and AES keywrap functionality to be enabled in order to build CMS/PKCS#7 decode support.

Recent changes to wolfSSL have allowed CMS/PKCS#7 decode support to be built without either of these requirements.

Previously, if the user desired to have the HAVE_PKCS7 build option defined, then the HAVE_X963_KDF and HAVE_AES_KEYWRAP build options were also required. Now, the HAVE_X963_KDF and HAVE_AES_KEYWRAP build options are optional and wolfSSL can be built with HAVE_PKCS7 enabled and either or neither of these build options enabled.

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