<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title><![CDATA[wolfSSL - Embedded SSL Library — wolfPKCS11 2.1.0 released]]></title>
		<link>https://www.wolfssl.com/forums/topic2540-wolfpkcs11-210-released.html</link>
		<atom:link href="https://www.wolfssl.com/forums/feed-rss-topic2540.xml" rel="self" type="application/rss+xml" />
		<description><![CDATA[The most recent posts in wolfPKCS11 2.1.0 released.]]></description>
		<lastBuildDate>Mon, 06 Jul 2026 05:37:38 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Re: wolfPKCS11 2.1.0 released]]></title>
			<link>https://www.wolfssl.com/forums/post8851.html#p8851</link>
			<description><![CDATA[<p>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.</p><p>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.</p><p>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<a href="https://metroexport.in/">.</a><br />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.</p>]]></description>
			<author><![CDATA[null@example.com (Hemant)]]></author>
			<pubDate>Mon, 06 Jul 2026 05:37:38 +0000</pubDate>
			<guid>https://www.wolfssl.com/forums/post8851.html#p8851</guid>
		</item>
		<item>
			<title><![CDATA[wolfPKCS11 2.1.0 released]]></title>
			<link>https://www.wolfssl.com/forums/post8847.html#p8847</link>
			<description><![CDATA[<p>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.</p><p><span class="bbu"><strong>Post-quantum cryptography</strong></span><br />The headline feature in 2.1.0 is post-quantum support. wolfPKCS11 now supports both <strong>ML-DSA</strong>, the FIPS 204 signature scheme formerly known as Dilithium, and <strong>ML-KEM</strong>, 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.</p><p>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.</p><p><span class="bbu"><strong>CMake build support and API documentation</strong></span><br />Building wolfPKCS11 is now easier to fit into modern toolchains. This release adds a full <strong>CMake build system</strong> alongside the existing Autotools setup, and ships the CMake package configuration in the Debian -dev package so downstream projects can consume it cleanly.</p><p>We have also added <strong>Doxygen API documentation</strong> covering the PKCS#11 interface, giving developers a browsable reference for the supported functions, mechanisms, and attributes.</p><p><span class="bbu"><strong>PKCS#11 specification compliance</strong></span><br />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.</p><p><span class="bbu"><strong>Upgrading from 2.0</strong></span><br />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:<br /></p><ul><li><p>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).</p></li></ul><ul><li><p>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).</p></li></ul><ul><li><p>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).</p></li></ul><p>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.</p><p><span class="bbu"><strong>Memory safety and hardening</strong></span><br />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.</p><p><span class="bbu"><strong>Testing, CI, and interoperability</strong></span><br />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.</p><p><span class="bbu"><strong>With thanks</strong></span><br />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.</p><p><span class="bbu"><strong>Get the release</strong></span><br />wolfPKCS11 2.1.0 is available now. You can find the full changelog and download the release from the <a href="https://github.com/wolfSSL/wolfPKCS11/releases/tag/v2.1.0-stable">wolfPKCS11 GitHub releases page</a>, or clone the repository directly for source access and integration.</p><p>If you have questions about any of the above, please contact us at <a href="mailto:facts@wolfssl.com">facts@wolfssl.com</a> or call us at +1 425 245 8247.</p><p><strong><a href="https://www.wolfssl.com/download/">Download</a> wolfSSL Now</strong></p>]]></description>
			<author><![CDATA[null@example.com (shizuka)]]></author>
			<pubDate>Wed, 01 Jul 2026 17:47:41 +0000</pubDate>
			<guid>https://www.wolfssl.com/forums/post8847.html#p8847</guid>
		</item>
	</channel>
</rss>
