RECENT BLOG NEWS
wolfSSL 5.8.0 Released
We are excited to announce that wolfSSL version 5.8.0 is now available. This release brings several important new features and improvements. Below are the key new additions:
New Features
- Implemented various fixes to support building for Open Watcom, including OS/2 support and Open Watcom 1.9 compatibility (PR 8505, 8484).
- Added support for STM32H7S (tested on NUCLEO-H7S3L8) (PR 8488).
- Added support for STM32WBA (PR 8550).
- Added Extended Master Secret Generation Callback to the –enable-pkcallbacks build (PR 8303).
- Implemented AES-CTS (–enable-aescts) in wolfCrypt (PR 8594).
- Added support for libimobiledevice commit 860ffb (PR 8373).
- Initial ASCON hash256 and AEAD128 support based on NIST SP 800-232 IPD (PR 8307).
- Added blinding option when using a Curve25519 private key by defining the macro WOLFSSL_CURVE25519_BLINDING (PR 8392).
ML-DSA and Post-Quantum Cryptography Enhancements
In line with NIST’s latest documentation, wolfSSL has updated its Dilithium implementation to ML-DSA (Module-Lattice Digital Signature Algorithm), which is fully supported in this release. Additionally, the release includes updates to further optimize ML-DSA and LMS (Leighton–Micali Signature) schemes, reducing memory usage and improving performance.
Linux Kernel Module (linuxkm) Updates
wolfSSL 5.8.0 expands support for the Linux Kernel Module (linuxkm), with several important enhancements to improve kernel-level cryptographic integration. This includes extended LKCAPI registration support for rfc4106(gcm(aes)), ctr(aes), ofb(aes), ecb(aes), and the legacy one-shot AES-GCM backend. Compatibility improvements have been added for newer kernels (?6.8), and calls to scatterwalk_map() and scatterwalk_unmap() have been updated for Linux 6.15. The release also registers ECDSA, ECDH, and RSA algorithms with the kernel crypto API and introduces safeguards for key handling, including forced zeroing of shared secrets. These changes make it possible to use more wolfSSL functionality in the kernel space.
For a full list of fixes and optimizations check out the ChangeLog.md bundled with wolfSSL. Download the latest release from the download 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
Securing UEFI with wolfSSL’s FIPS 140-3 Cryptography
One of the biggest strengths of the wolfSSL portfolio is its ability to adapt and run in the most diverse environments, whether it’s a minimal bare-metal deployment or a complex, multi-layered operating system.
This blog highlights recent improvements in the wolfSSL products regarding integration with the Unified Extensible Firmware Interface (UEFI)—the modern way to interface with hardware firmware during the initial steps after booting a machine (UEFI has replaced the legacy BIOS).
wolfSSL can already enhance UEFI firmware with component authentication and secure updates, as wolfBoot—our secure boot solution—can run as a UEFI application inside UEFI environments (Check out the build instruction).
Recently, wolfSSL has made it even simpler for other UEFI applications to access wolfSSL cryptographic services (using wolfCrypt). wolfSSL has improved its use of UEFI features, leveraging TRNG and crypto accelerators exposed by UEFI.
UEFI applications can now consume a FIPS 140-3 certified range of wolfSSL cryptographic algorithms (AES, RSA, DSA, ECDSA, SHA), key derivation functions, and secure communication protocols (D)TLS up to v1.3.
As a leader in embedded FIPS certificates, wolfSSL can assist you in the certifying of your UEFI based operating environments (OE’s) and assists you in the ACVP (Automated Cryptographic Validation Protocol).
The use cases are many: OS-agnostic secure communication, TPM attestation, disk encryption, and more.
If you are interested in using wolfSSL cryptography, wolfSSL TLS communication, any wolfSSL product inside a UEFI environment, or 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 Java JSSE Provider Supports DTLS 1.3
wolfSSL’s Java JSSE provider (wolfJSSE) now supports DTLS 1.3! This support includes DTLS 1.3 on both client and server side through the SSLEngine interface. This support can be found in the wolfssljni GitHub master branch, and will be included in the next stable release.
Benefits of DTLS 1.3
DTLS 1.3 (see RFC 9147) brings improved security and performance over DTLS 1.2, including:
- Reduced handshake latency (fewer round trips)
- Enhanced privacy (encrypted handshake messages)
- Improved resilience against network attacks
- Modern cryptographic algorithms
Getting Started
wolfJSSE can be built on a number of platforms, including Unix/Linux, macOS, Windows, and Android. See the wolfSSL JNI/JSSE Manual for instructions on building the library.
Example Applications
wolfJSSE includes sample DTLS 1.3 client and server applications which can be used as a reference and to try out Java DTLS 1.3 functionality. To compile the examples run:
ant examples
The example client is located in “./examples/provider/DtlsClientEngine.java” and the server is located in “./examples/provider/DtlsServerEngine.java”. Each can be run from the root “wolfssljni” directory using the wrapper scripts that share the same name. Example output should be similar to:
./examples/provider/DtlsServerEngine.sh DTLS 1.3 Server listening on port 11113 DTLS 1.3 Server Engine created Waiting for client connection... Client connected from /127.0.0.1:58703 DEBUG: Sent packet with 176 bytes DEBUG: Received packet with 383 bytes DEBUG: Sent packet with 176 bytes DEBUG: Sent packet with 36 bytes DEBUG: Sent packet with 69 bytes DEBUG: Sent packet with 721 bytes DEBUG: Sent packet with 109 bytes DEBUG: Sent packet with 66 bytes DEBUG: Received packet with 908 bytes DEBUG: Received packet with 110 bytes DEBUG: Received packet with 66 bytes DEBUG: Sent packet with 72 bytes DEBUG: Sent packet with 255 bytes DTLS handshake completed successfully Pausing briefly before processing application data... DEBUG: Received packet with 40 bytes DEBUG: Received packet with 49 bytes Received from client: Hello from DTLS 1.3 Client! Echoing message back to client DEBUG: Sent packet with 49 bytes Closing connection... Connection closed ./examples/provider/DtlsClientEngine.sh Client socket created, connecting to localhost:11113 DTLS 1.3 Client Engine created Starting DTLS handshake... DEBUG: Sent packet with 310 bytes to localhost/127.0.0.1:11113 DEBUG: Received packet with 176 bytes from /127.0.0.1:11113 DEBUG: Sent packet with 383 bytes to localhost/127.0.0.1:11113 DEBUG: Received packet with 176 bytes from /127.0.0.1:11113 DEBUG: Received packet with 36 bytes from /127.0.0.1:11113 DEBUG: Received packet with 69 bytes from /127.0.0.1:11113 DEBUG: Received packet with 721 bytes from /127.0.0.1:11113 DEBUG: Received packet with 109 bytes from /127.0.0.1:11113 DEBUG: Received packet with 66 bytes from /127.0.0.1:11113 DEBUG: Sent packet with 908 bytes to localhost/127.0.0.1:11113 DEBUG: Sent packet with 110 bytes to localhost/127.0.0.1:11113 DEBUG: Sent packet with 66 bytes to localhost/127.0.0.1:11113 DEBUG: Received packet with 72 bytes from /127.0.0.1:11113 DTLS handshake completed successfully Processing post-handshake session tickets... Received post-handshake packet of 255 bytes, processing... Processed post-handshake packet: OK, consumed: 255, produced: 0 Pausing briefly before sending data... Pausing after handshake to allow connection to stabilize... Sending application data: Hello from DTLS 1.3 Client! DEBUG: Sent packet with 40 bytes to localhost/127.0.0.1:11113 DEBUG: Sent packet with 49 bytes to localhost/127.0.0.1:11113 Waiting for server response (allowing time for processing)... Now attempting to receive server response... Waiting for application data packet from server... Received packet of 49 bytes Raw bytes: 2F DA 82 00 2C DB B7 A5 0D 19 31 20 68 A2 0C 1C 91 75 F6 65 ... Unwrap result: OK, consumed: 49, produced: 27 Successfully decrypted data: Hello from DTLS 1.3 Client! Closing connection... Connection closed
If you have questions about using DTLS 1.3 from your Java application, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Xilinx vs STM: wolfSSL Integration and Build Experience Compared
Selecting the right hardware for an embedded project can be a complex decision—but choosing a security library doesn’t have to be. wolfSSL offers broad platform support, running seamlessly on everything from bare-metal systems to full-featured operating systems. In this post, we’ll compare how wolfSSL integrates with two widely used embedded platforms: Xilinx and STM. While both are popular choices, they offer distinct differences in architecture, development tools, and integration workflows.
Platform High Level Overview
Xilinx
- Primarily FPGA-based (Zynq, Zynq Ultrascale+, Versal)
- Offers ARM Cortex-A cores alongside programmable logic
- Development environment: Xilinx Vitis / Petalinux
- OS: Often uses Linux (Yocto or Petalinux), FreeRTOS or bare-metal
STM (STMicroelectronics)
- Microcontroller-focused (e.g., STM32 family)
- Most are based on ARM Cortex-M cores, with some series using Cortex-A cores
- Development environment: STM32CubeIDE, Makefiles, or bare-metal toolchains
- OS: Often bare-metal or FreeRTOS
wolfSSL Build Process
Xilinx
- Autotools or CMake to build wolfSSL in userspace
- Cross-compilation with Petalinux SDK or Vitis toolchain
- Hardware acceleration via Xilinx’s crypto engine, ARM assembly optimizations or custom logic in the PL with crypto callbacks
STM (STMicroelectronics)
- Predefined example configuration files in wolfSSL/IDE/STM32Cube
- Integration with STM32CubeMX-generated projects
- Support for HAL/LL drivers, and FreeRTOS (if applicable)
Cryptographic Acceleration
Xilinx
- Advanced FPGAs allow for hardware acceleration of cryptographic primitives
- Can use custom IP cores or external crypto accelerators
- wolfSSL’s ARM assembly optimizations
- Potential for extreme performance gains, but at the cost of complexity
STM (STMicroelectronics)
- Some STM32 parts support hardware ECC, AES, SHA, and RNG
- wolfSSL can use these via direct calls to HAL drivers
- Easier to configure and use but offers less flexibility compared to FPGAs and on average has a less powerful CPU
- wolfSSL’s ARM assembly optimizations
Some Use Cases We See
- Xilinx if:
- You need programmable logic and customizable crypto acceleration
- Your application runs Linux and demands high throughput
- You have a complex security architecture
- STM if:
- You want quick integration for a bare-metal or FreeRTOS-based project
- Your focus is low power and minimal footprint
- You need an edge microcontroller
Both Xilinx and STM platforms are well-supported by wolfSSL, but the experience differs significantly. Xilinx generally offers power and flexibility—ideal for high-performance secure systems—while STM excels in simplicity and efficiency, making it perfect for lightweight, resource-constrained designs.
Whether you’re targeting a Linux-based Zynq application or a real-time STM32 sensor node, wolfSSL provides the building blocks you need to implement robust embedded security.
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
Secure Your Oracle Linux 8 Deployment with wolfSSL’s FIPS 140-3 Validated Module
If you’re stuck on OL8 for some reason, have no desire to migrate to OL9 or later, and still need FIPS support for OpenSSL 1.x, then we can help with our FIPS 140-3 module, which plugs into the OpenSSL 1.x engine interface.
If you have questions about FIPS, please reach out to us at fips@wolfssl.com. For any other inquiries, contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live webinar: Open Source Secure Boot Meets Open Hardware: wolfBoot Integration with TROPIC01 Secure Element
Join us for an exciting webinar showcasing the integration of the TROPIC01 secure element with wolfBoot, bringing open source secure boot down to the hardware level.
Register Now: Open Source Secure Boot Meets Open Hardware: wolfBoot Integration with TROPIC01 Secure Element
Date: June 25th | 9 AM PT
The Tropic Square team has integrated support for the TROPIC01 secure element into wolfBoot, using it as a hardware Root-of-Trust for the secure boot process. This integration is a milestone because it extends wolfBoot’s open source transparency right down to the hardware, enabling users and security researchers to audit the entire security chain—from software to hardware.
This approach aligns with Kerckhoff’s principle, which states that a cryptosystem should remain secure even if everything about it, except the secret key, is publicly known. By opening the design and implementation, users don’t have to blindly trust that the secure element is free from vulnerabilities or backdoors.
This webinar will cover:
- An overview of the TROPIC01 open architecture secure element and wolfBoot
- A demo of TROPIC01 integrated into the secure boot process
- Why “security by obscurity” fails—and how Tropic Square and wolfSSL deliver transparent, Open Source security that builds trust
Register now to learn how to build transparent, auditable, open source secure boot solutions from silicon to software.
As always, our webinar will include Q&A throughout. 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
wolfTPM Support for Das U-Boot
wolfTPM now includes support for Das U-Boot, extending TPM 2.0 access to early boot stages in secure embedded systems. This port enables direct TPM communication in U-Boot environments using software SPI and provides both native and high-level APIs for flexibility.
Key Features
- SOFT SPI Driver
- Full TPM 2.0 command set
- Both native API and wrapper APIs for complex TPM operations
- Two integration paths:
- __linux__: Uses tpm2_linux.c to communicate via standard Linux TPM interfaces
- __UBOOT__: Direct SPI communication via tpm_io_uboot.c
U-Boot TPM Commands
The wolftpm command interface in U-Boot offers a rich set of TPM 2.0 operations. including:
- Basic TPM control: init, startup, self_test, info
- PCR management: pcr_extend, pcr_read, pcr_allocate, pcr_print
- Security features: clear, change_auth, dam_reset, dam_parameters
- Firmware management: firmware_update, firmware_cancel
- Capability reporting: caps, get_capability
These commands allow developers to initialize, configure, and query TPM state from within U-Boot, enabling security features even before the OS loads.
Extended Functionality
While U-Boot includes basic TPM 2.0 command support through its native library, wolfTPM extends this functionality with the ability to manage firmware updates.
Firmware Management Support
wolfTPM includes dedicated commands for managing TPM firmware, allowing users to directly perform updates and control firmware behavior from the U-Boot shell:
- firmware_update <manifest_addr> <manifest_sz> <firmware_addr> <firmware_sz>
Performs a full firmware update on the TPM by providing a signed manifest and firmware image.</styel=”font-family:courier> - firmware_cancel
Allows users to cancel or abandon an ongoing firmware update process.
These capabilities are not present in U-Boot’s built-in TPM stack, which lacks any mechanism for managing TPM firmware or triggering a reboot of the TPM device. With wolfTPM, developers gain direct control over the TPM lifecycle, supporting scenarios like:
- Field upgrades of TPM firmware
- Factory provisioning with verified firmware images
- TPM resets and recovery via startup/shutdown sequences
By leveraging wolfTPM in U-Boot, embedded developers and security teams can take full advantage of the TPM 2.0 specification—including lifecycle and provisioning flows that go beyond what standard U-Boot TPM implementations provide.
Getting Started
For detailed build instructions, configuration options, and sample usage:
- Pull Request with full details: PR#398
- Documentation and examples: examples/u-boot/README.md
Conclusion
wolfTPM’s U-Boot support is ideal for securing early boot environments with TPM 2.0 features. With a rich command-line interface, flexible APIs, and tested support for QEMU and swtpm, it’s a robust solution for TPM integration in embedded platforms.
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
wolfTPM Support for Zephyr RTOS
wolfSSL now has support for Zephyr RTOS through a newly added wolfTPM Zephyr port. This enables easy integration of TPM 2.0 functionality in embedded projects using Zephyr, expanding the flexibility and portability of secure applications.
Below is a summary of the key features introduced in the PR#395:
Key Changes and Features
Zephyr Module Integration
wolfTPM has been added as a Zephyr module, complete with CMake and Kconfig support. This makes it simple to include TPM functionality in any Zephyr-based project using standard module inclusion through west.
Sample Applications
Two test/sample applications are included in the port:
- wolftpm_wrap_test – tests core TPM wrapper functionality
- wolftpm_wrap_caps – displays TPM capabilities
Both examples build and run successfully on qemu_x86, providing developers with a solid foundation to build on.
Custom Configuration Support
The module uses a user_settings.h configuration file, which can be customized or replaced as needed by developers to match project-specific requirements.
CI Integration
A new