RECENT BLOG NEWS
wolfSSL 5.8.2 Now Available
wolfSSL 5.8.2 is now available! We are excited to announce the release of wolfSSL 5.8.2, packed with significant enhancements, introducing new functionalities, and refining existing features!
Important Notes for this Release
- GPLv3 Licensing: wolfSSL has transitioned from GPLv2 to GPLv3.
- Deprecated Feature: `–enable-heapmath` is now deprecated.
- MD5 Disabled by Default: For enhanced security, MD5 is now disabled by default.
Key Highlights of wolfSSL 5.8.2
Vulnerability Mitigations:
- ECC and Ed25519 Fault Injection Mitigation (Low): (Thanks to Kevin from Fraunhofer AISEC)
- Apple Native Cert Validation Override (High – CVE-2025-7395): (Thanks to Thomas Leong from ExpressVPN)
- Predictable `RAND_bytes()` after `fork()` (Medium – CVE-2025-7394): (Thanks to Per Allansson from Appgate)
- Curve25519 Blinding Enabled by Default (Low – CVE-2025-7396): (Thanks to Arnaud Varillon, Laurent Sauvage, and Allan Delautre from Telecom Paris)
New Features:
- Sniffer Enhancements: Support for multiple sessions and a new `ssl_RemoveSession()` API for cleanup.
- New ASN.1 X509 API: `wc_GetSubjectPubKeyInfoDerFromCert` for retrieving public key information.
- PKCS#12 Improvements: `wc_PKCS12_create()` now supports PBE_AES(256|128)_CBC key and certificate encryptions.
- PKCS#7 Decoding: Added `wc_PKCS7_DecodeEncryptedKeyPackage()` for decoding encrypted key packages.
- Linux Kernel Module Expansion: All AES, SHA, and HMAC functionality now implemented within the Linux Kernel Module.
- OpenSSL Compatibility Layer Additions: New APIs for X.509 extensions and RSA PSS: `i2d_PrivateKey_bio`, `BN_ucmp`, and `X509v3_get_ext_by_NID`.
- Platform Support: Added support for STM32N6.
- Assembly Optimizations: Implemented SHA-256 for PPC 32 assembly.
Improvements & Optimizations:
This release includes a wide range of improvements across various categories, including:
- Extensive Linux Kernel Module (LinuxKM) Enhancements: Numerous minor fixes, registrations, and optimizations for cryptography operations within the Linux Kernel Module.
- Post-Quantum Cryptography (PQC) & Asymmetric Algorithms: Updates to Kyber, backward compatibility for ML_KEM IDs, fixes for LMS building and parameters, and OpenSSL format support for ML-DSA/Dilithium.
- Build System & Portability: General build configuration fixes, improvements for older GCC versions, new CMakePresets, and default MD5 disabling.
- Testing & Debugging: Enhanced debugging output, additional unit tests for increased code coverage, and improved benchmark help options.
- Certificates & ASN.1: Improved handling of X509 extensions, fixed printing of empty names, and better error handling.
- TLS/DTLS & Handshake: Corrected group handling, improved DTLS record processing, and refined TLS 1.3 key derivation.
- Memory Management & Optimizations: Stack refactors, improved stack size with MLKEM and Dilithium, and heap math improvements.
- Cryptography & Hash Functions: Added options to disable assembly optimizations for SipHash and SHA3, and improved Aarch64 XFENCE.
- Platform-Specific & Hardware Integration: Explicit support for ESP32P4, public `wc_tsip_*` APIs, and enhanced PlatformIO certificate bundle support.
- General Improvements & Refactoring: Updated libspdm, fixed PEM key formatting, and improved API accessibility for certificate failure callbacks.
wolfSSL 5.8.2 also includes some nice bug fixes, addressing issues across various modules, ensuring greater stability and reliability. For a complete and detailed list of all changes, please refer to the full release notes.
We encourage all users to upgrade to wolfSSL 5.8.2 to take advantage of these important security updates, new features, and performance enhancements. Download the latest release.
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
Live Webinar: WolfGuard: FIPS 140-3 Enabled WireGuard
WireGuard is known for its simplicity, speed, and modern cryptography, but what if your deployment requires FIPS 140-3 validated security? That’s where WolfGuard comes in.
Join wolfSSL Software Engineer Lealem Amedie as he introduces WolfGuard, a FIPS 140-3 enabled WireGuard solution optimized for speed and cryptographic agility. Built on the FIPS-certified wolfCrypt library, WolfGuard delivers all of WireGuard’s functionality with the assurance of FIPS-approved algorithms.
Register Now: WolfGuard: FIPS 140-3 Enabled WireGuard
Date: October 8 | 9 AM PT
This webinar will cover:
- WireGuard fundamentals and implementations (Linux, GO, BoringTun)
- How WireGuard secures tunnels and encrypts data
- FIPS 140-3, FedRAMP, and CMMC 2.0 compliance needs
- How WolfGuard integrates FIPS into WireGuard with zero architectural changes
- Real-world use cases + live demo with WolfGuard Go
If you need WireGuard with FIPS 140-3 compliance and zero complexity trade-offs, WolfGuard is your solution.
Register now to see WolfGuard in action and achieve compliance in your VPN deployments.
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
Every hardware cryptography scheme wolfSSL has ever enabled
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:
- 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:
- Intel ADX and BMI2: Intel and AMD x86.
RSA Curve25519 256 bit Ed25519 256 bit References:
- RDRAND/RDSEED: Intel 64 and IA-32, and AMD Zen processor families.
RNG References:
- 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:
- NXP Coldfire SEC: (MCF547X and MCF548X family of processors)
AES–CBC 128, 192, 256 bit 3DES–CBC 192 bit DES–CBC 64 bit References:
- 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:
- 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:
- 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:
- 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:
- Marvell (Cavium) Nitrox V and III:
AES–GCM 128 bit AES–CBC 128, 192, 256 bit RSA 2048 bit ECC ECDSA RNG References:
- Marvell (Cavium) Octeon II/III:
AES–GCM 128, 192, 256 bit AES–CBC 128, 192, 256 bit 3DES–CBC References:
- 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:
- 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:
- Nordic NRF5x:
AES–ECB 128 bit RNG References:
- Microchip/Atmel ATECC508A/ATECC608A:
ECC 256 bit (NIST-P256) References:
- 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:
- ARMV8:
AES–GCM 128, 192, 256 bits AES–CCM 128, 192, 256 bits AES–CBC 128, 192, 256 bits SHA256 Referenece:
- Arm® TrustZone® CryptoCell-310: nRF52840
RSA 2048 bits AES–CBC 128, 192, 256 bit ECC 256 bit ECDSA 256 bit SHA256 SRNG Reference:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- Xilinx Zynq UltraScale+ MPSoC:tr>RNGSHA-384
AES–GCM 256 bit RSA 256 bit ECC NIST P-384, P-521 SHA3 SHA-384 Reference:
- Xilinx Zynq UltraScale+ MPSoC
AES–GCM 256 bit RSA 2048, 4096 bits SHA3 SHA-384 Reference:
- MAXQ1065 and MAXQ1080:
AES–GCM 128, 192, 256 bit AES–CCM 128, 192, 256 bit ECC NIST-P256 ECC SHA2 SHA-256 Reference:
- 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:
- 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 Summer 2026 Internship Program – Bozeman, MT
wolfSSL is now accepting applications for our Summer 2026 Internship Program in Bozeman, MT! We offer students real-world experience in cybersecurity and embedded systems, within a fast-growing tech company.
Software Engineering Internship
Overview:
Interns who participate in this program gain valuable knowledge in SSL/TLS and the security industry as well as C programming experience on Linux and embedded systems. Throughout the summer, interns play a role in improving wolfSSL products – working on testing, documentation, examples, porting, marketing, and interacting with wolfSSL’s community.
This program is a great opportunity to be part of the Open Source project, learn how real-world software is created and maintained, gain work experience in the field of Computer Science, and work towards a potential future career with the wolfSSL team.
Requirements:
- Currently pursuing a Bachelor’s or higher in Computer Science, Computer Engineering, or a related technical field
- Experience and familiarity with C programming
- Experience and familiarity with git and GitHub
- Experience with embedded systems / microcontrollers, network programming, or Linux/Unix are a plus, but not a hard requirement for application.
Location:
The 2026 internship will be held in-person at the wolfSSL Bozeman, MT office. wolfSSL does not provide housing reimbursement, and interns must be able to relocate to Bozeman and find suitable housing for the summer.
Pay: $35/hour
Application Materials:
- Resume and Cover Letter
- C Programming Sample – A C application which best demonstrates your C programming ability. There are no requirements on the category or length of the application. Sample applications should be able to be compiled and run by wolfSSL recruiters.
- Technical Writing Sample – A writing sample which best demonstrates your writing ability. There is no requirement of topic or length of this sample.
Apply Today
This internship offers valuable real-world experience and the opportunity to contribute to wolfSSL’s mission of securing billions of Internet connections. Interested candidates should send a resume, cover letter, and supporting materials to internships@wolfssl.com.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us +1 425 245 8247.
Download wolfSSL Now
How to use the wolfSSL staticmemory feature
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
wolfPKCS11 v2.0.0 is Here!
We are thrilled to announce the release of wolfPKCS11 v2.0.0, a landmark update that solidifies its position as a top-tier, high-performance PKCS#11 provider. This release is the culmination of the work detailed in our previous blog posts, “Firefox Gets FIPS 140-3 Power” and “wolfPKCS11 Supercharged,” and it brings a new era of security, performance, and flexibility to the PKCS#11 ecosystem.
What’s New in v2.0.0?
This release is brimming with features that establish wolfPKCS11 as a comprehensive and robust backend for Mozilla’s Network Security Services (NSS). This enables any application that relies on NSS to be powered by our FIPS 140-3 validated wolfCrypt engine.
Here are some of the key highlights:
- Full NSS Backend Support: With the addition of 50 new cryptographic mechanisms and a dozen new API functions, wolfPKCS11 now provides extensive support for NSS. This allows for a seamless “drop-in” replacement for the default NSS cryptographic module, offering a straightforward path to FIPS compliance for applications like Firefox, Thunderbird, and various Linux server products.
- Modern and Secure Cryptography: We’ve integrated support for modern and provably secure signature schemes like RSA-PSS, which provide enhanced resilience against cryptographic attacks.
- Advanced Cryptographic Operations: This release introduces a suite of powerful new functions for advanced cryptographic operations. These include comprehensive C_Digest functions for hashing, as well as multi-part signing and encryption with C_SignEncryptUpdate and decryption and verification with C_DecryptVerifyUpdate. We have also added C_SignRecoverInit and C_VerifyRecover for signature schemes with message recovery, providing more options for secure and efficient data handling.
- Comprehensive Algorithm Support: This release includes a full suite of SHA-2 and SHA-3 hashing algorithms, alongside advanced AES capabilities like CKM_AES_KEY_WRAP_PAD for secure key management.
Enhanced Debugging for a Smoother Development Experience
We understand that a smooth development process is crucial. That’s why we’ve introduced new debugging features in this release. You can now enable debug logging for the API, giving you more visibility into the inner workings of the token and helping you troubleshoot issues more effectively.
Our Commitment to Quality and Reliability
This release is not just about adding new features; it’s also a testament to our unwavering commitment to quality and reliability.
You might be wondering about upgrading. Don’t worry! These new features maintain full backward compatibility. The PKCS#11 standard provides a stable API, and this release focuses on “filling in the gaps” by implementing more of the standard’s functions. To ensure a seamless transition for existing users, we also perform rigorous upgrade testing on the token storage, so you can update with confidence.
We’ve introduced a new –enable-nss compile-time option to streamline integration and have significantly improved our CI pipeline with extensive regression testing against the NSS suite, static analysis, and dynamic sanitizers to guarantee stability.
We have also included numerous fixes for TPM users and improved the handling of object attributes for greater security and reliability. These updates transform wolfPKCS11 into a fully-featured, highly reliable, and FIPS-capable PKCS#11 implementation.
Get Started Today!
The latest version of wolfPKCS11 is available now on the wolfSSL download page. We invite you to explore these powerful new features and discover how they can bring the industry-leading performance and certified security of wolfCrypt to the entire ecosystem of applications built on NSS.
For any technical questions, please reach out to us at support@wolfssl.com. For inquiries related to FIPS 140-3 validation, commercial licensing, or any other questions, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: Securing the Edge AI with wolfSSL on the STM32N6
Unlock advanced security with the STM32N6 and wolfBoot for trusted Edge AI applications.
This webinar explores the security and performance advantages of the STM32N6 for Edge AI, with wolfBoot extending protection through a secure, authenticated boot process. You’ll gain practical insights into how the STM32N6’s unique architecture accelerates AI workloads while maintaining strong security—plus see how wolfBoot establishes a hardware root of trust to ensure that only verified code runs on the device.
Register Now: Securing the Edge AI with wolfSSL on the STM32N6
Date: October 1st | 9 AM PT
Built on the Arm® Cortex®-M55 with Helium™ vector processing, the STM32N6 is engineered for high-performance Edge AI. Its built-in Memory Cipher Engine (MCE) safeguards external flash access, giving developers a robust foundation for secure, efficient, and scalable AI-enabled applications.
wolfBoot, wolfSSL’s secure bootloader, strengthens this platform by ensuring firmware integrity and preventing tampered code from executing. It leverages hardware-assisted root of trust features such as measured boot and secure partitions to protect against attacks even when using external flash storage.
This webinar will cover:
- Key features of the STM32N6 for Edge AI
- Security standards update: FIPS 140-3, CNSA 2.0, and PQC
- Best practices and secure boot with wolfBoot
- Cryptographic acceleration and MCE flash protection
- TLS 1.3 demo on STM32N6
Register Now!
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
Secure Data Transfers on BSD Systems
Many developers working on FreeBSD, OpenBSD, and NetBSD may not realize that cURL can be integrated with wolfSSL for secure communications. This combination allows applications to use modern TLS protocols and FIPS 140-3 validated cryptography on BSD platforms.
Secure communication is critical in servers and embedded devices. Using wolfSSL with cURL ensures standards-compliant TLS connections while maintaining portability across BSD-based operating systems.
For projects with constrained environments, wolfSSL also provides tiny-curl, a lightweight cURL variant suitable for low-memory devices.
This setup demonstrates a practical, verified approach to secure networking on BSD systems, using tools that are widely adopted in the industry.
Learn more about wolfSSL solutions! 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
The Radio Equipment Directive (RED) and Evolving Cybersecurity Requirements
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
Support for STM32U5 DHUK
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
New CMS/PKCS#7 decode APIs for SymmetricKeyPackage, OneSymmetricKey, and EncryptedKeyPackage
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
Weekly updates
Archives
- October 2025 (4)
- September 2025 (22)
- August 2025 (23)
- July 2025 (27)
- June 2025 (22)
- May 2025 (25)
- April 2025 (24)
- March 2025 (22)
- February 2025 (21)
- January 2025 (23)
- December 2024 (22)
- November 2024 (29)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)