<![CDATA[wolfSSL - Embedded SSL Library — wolfPKCS11 2.1.0 released]]> 2026-07-06T05:37:38Z PunBB https://www.wolfssl.com/forums/topic2540-wolfpkcs11-210-released.html <![CDATA[Re: wolfPKCS11 2.1.0 released]]> with ML-KEM and ML-DSA, especially now that the naming aligns with the finalized FIPS standards. Having these algorithms available through the standard PKCS#11 interface should make adoption much smoother for existing applications.

The CMake build system and Doxygen documentation are also very welcome additions. They should make integration into modern development environments much easier and improve the developer experience.

I also appreciate the emphasis on PKCS#11 specification compliance and memory-safety improvements. The notes about the changed default attribute values and the legacy compatibility defines are particularly helpful for anyone planning an upgrade from 2.0.
Thanks to the wolfSSL team and the contributors for all the work that went into this release. Looking forward to trying out version 2.1.0.

]]> https://www.wolfssl.com/forums/user9005.html 2026-07-06T05:37:38Z https://www.wolfssl.com/forums/post8851.html#p8851 <![CDATA[wolfPKCS11 2.1.0 released]]> We are pleased to announce the release of wolfPKCS11 2.1.0, a significant update that brings post-quantum cryptography to our PKCS#11 implementation, adds a CMake build system and Doxygen API documentation, and closes a large number of PKCS#11 specification compliance gaps. It also delivers a thorough round of memory-safety hardening, and expands our CI and interoperability testing.

Post-quantum cryptography
The headline feature in 2.1.0 is post-quantum support. wolfPKCS11 now supports both ML-DSA, the FIPS 204 signature scheme formerly known as Dilithium, and ML-KEM, the FIPS 203 key encapsulation mechanism formerly known as Kyber. ML-DSA support includes CKA_SEED based private key import, and the mechanism and identifier naming has been finalised to match the standardised algorithms.

With these additions, applications using wolfPKCS11 as their PKCS#11 provider can begin moving signing and key-establishment workflows onto quantum-resistant algorithms through the same standard interface they already use, with no change to the underlying integration model.

CMake build support and API documentation
Building wolfPKCS11 is now easier to fit into modern toolchains. This release adds a full CMake build system alongside the existing Autotools setup, and ships the CMake package configuration in the Debian -dev package so downstream projects can consume it cleanly.

We have also added Doxygen API documentation covering the PKCS#11 interface, giving developers a browsable reference for the supported functions, mechanisms, and attributes.

PKCS#11 specification compliance
A large part of this release is dedicated to closing compliance gaps against the PKCS#11 specification, many of them surfaced through negative testing and static analysis. Highlights include correct handling of CKR_OPERATION_ACTIVE, enforcement of CKA_EXTRACTABLE when wrapping a key, fixes to the SHA-512 truncated forms (SHA-512/224 and SHA-512/256), and a correction to CK_ULONG length truncation in C_GenerateRandom and C_SeedRandom. Several attribute defaults were also corrected to match the specification, along with the related C_DeriveKey, C_CopyObject, C_DestroyObject, encapsulation, and C_Login enforcement behaviour.

Upgrading from 2.0
Because some of these corrections change default attribute values, applications and stored tokens created against 2.0 may see different behaviour after upgrading. The pre-2.1 behaviour can be restored at build time using the following defines:

  • WOLFPKCS11_LEGACY_COPYABLE_FALSE_DEFAULT restores the old behaviour where an unset CKA_COPYABLE reads back as CK_FALSE (the PKCS#11 default is CK_TRUE).

  • WOLFPKCS11_LEGACY_PRIVATE_FALSE_DEFAULT restores the old behaviour where an unset CKA_PRIVATE reads back as CK_FALSE for private and secret keys, and disables the matching login-state check on object creation (the PKCS#11 default is CK_TRUE).

  • WOLFPKCS11_LEGACY_WRAP_TRUE_DEFAULT restores the old behaviour where an unset CKA_WRAP or CKA_UNWRAP defaults to CK_TRUE (the PKCS#11 default is CK_FALSE).

We recommend testing against the new, spec-compliant defaults where possible, and reserving the legacy defines for cases where existing tokens or applications depend on the old values.

Memory safety and hardening
This release resolves a broad set of compliance and static-analysis findings identified by Fenrir, our internal code-scanning tooling, along with fixes for resource leaks and secure buffer erasing, as well as a number of smaller correctness issues.

Testing, CI, and interoperability
To keep these improvements locked in, we have expanded the test and CI coverage considerably. New work includes negative testing and validation across the API, a multi-call HMAC regression test, a C_VerifyRecover test, an interoperability test against wolfSSL master, and a wolfBoot integration test to catch regressions early. CI now also covers C++ builds, applies per-job timeouts across all workflows, and has been updated to track upstream dependency changes.

With thanks
Our thanks go to Denis Mingulov for contributing the C_GenerateRandom and C_SeedRandom length-truncation fix, and for reporting several of the issues addressed in this release.

Get the release
wolfPKCS11 2.1.0 is available now. You can find the full changelog and download the release from the wolfPKCS11 GitHub releases page, or clone the repository directly for source access and integration.

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

]]> https://www.wolfssl.com/forums/user5631.html 2026-07-01T17:47:41Z https://www.wolfssl.com/forums/post8847.html#p8847