1 Topic by shizuka

(0 replies, posted in Announcements)

wolfSSL JNI/JSSE 1.19.0 is now available for download! This release fixes SSLSocket read and handshake timeouts on Windows, resolves SSLEngine issues on TLS 1.3 connections, and adds new JNI APIs for canceling a handshake and managing native session timeouts. Along with these changes, 1.19.0 contains fixes for session caching and resumption, connection shutdown, X.509 certificate handling, and input validation.

New JNI Functionality

  • Cancel a handshake before it completes: WolfSSLSession.sendUserCanceled()

  • Manage native session timeouts: WolfSSLSession.sessionSetTimeout() and related methods

  • Get negotiated DH group size in bits: WolfSSLSession.getDhKeySize()

  • WolfSSL.wolfssl_chacha and wolfssl_camellia bulk cipher constants for getBulkCipher()

SSLSocket and SSLEngine Fixes

  • Windows – SSLSocket.setSoTimeout() read and handshake timeouts now work on Windows, SSLSocket.close() cleanly ends blocked reads on Windows/select() builds, and WolfSSL.getErrno() returns WSAGetLastError().

  • TLS 1.3 SSLEngine – Fixed an IllegalArgumentException when retrying unwrap() after BUFFER_OVERFLOW, and truncated JDK HttpClient responses when TLS 1.3 servers send no session ticket.

  • Apache HttpClient 5 – Fixed handshake failures caused by lowercase “https” endpoint identification.

  • Connection shutdown – A close notify alert is now sent when closing mid-handshake, shutdownSSL() no longer loops on a WANT_READ/WANT_WRITE left from an unfinished handshake, SSLSocket.read() returns -1 when the peer closes without a close notify, and SSLSocket.close() treats SO_LINGER as seconds and does not wait when it is 0.

  • Error reporting – getError() now returns the original native error instead of SSL_ERROR_SYSCALL.

Bug Fixes & Reliability Improvements

  • FIPS – FIPS CASTs now run once per process, fixing failures when concurrent threads create WolfSSL objects.

  • Sessions – Sessions invalidated with SSLSession.invalidate() are no longer resumed or cached, and session IDs and SNI names are kept after close and in sessions from the cache.

  • Java properties – jdk.tls.disabledAlgorithms DH key size limits are enforced on the negotiated DH group, jdk.tls.*.SignatureSchemes parsing handles a comma followed by a space.

  • Trust and hostname checks – Stricter LDAPS wildcard hostname checks with a basic X509TrustManager, failure on a corrupt system trust store, and subject alternative names containing NUL bytes omitted instead of returned truncated.

  • X.509 and CRL – Corrected Extended Key Usage, Key Usage, getExtensionValue(), and subject/issuer DN output in WolfSSLX509, getPublicKey() support for EdDSA and RSASSA-PSS keys, locale-independent date parsing, and revocation dates and signing errors in certificate, CSR, and CRL generation.

  • Resource handling and validation – Fixed native resource leaks when SSLSocket.close() overlaps I/O, SSLServerSocket.accept() leaking the accepted socket on wrap failure, and SSLEngine send buffer growth on large wrap() calls. Invalid read()/write() offsets, negative session timeouts, and empty ALPN protocol names are now rejected.

  • PSK, ALPN, and DTLS – Fixed PSK handshakes with no identity hint or a maximum-length client identity, ALPN names with commas or non-ASCII bytes in select callbacks, and dtlsSetPeer()/dtlsGetPeer() with IPv6 addresses.

Examples & Testing

  • RMI, threaded socket, and dual-provider FIPS example servers now use client certificates, and the RMI TLS client enables HTTPS hostname verification.

  • Android example native libraries are linked with 16 KB page alignment for Android 15+.

  • New socket read and handshake timeout tests, close interrupt tests on Windows, and test certificates covering EKU, Key Usage, EdDSA, and RSA-PSS public keys.

  • Makefile now auto-detects JAVA_HOME and supports JNI include paths with spaces.

wolfSSL JNI/JSSE 1.19.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfSSL JNI/JSSE User Manual can be found here. Full details on this release can be seen in the ChangeLog.md on GitHub. For any questions or to get help using wolfSSL products in your projects, contact us at support@wolfssl.com.

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

Go to forum: Announcements

2 Topic by shizuka

(0 replies, posted in Announcements)

wolfCrypt JNI/JCE 1.12.0 is now available for download! This release brings Ed25519 and Ed448 signature and key support, new AES-XTS, AES Key Wrap, and AES-CFB cipher modes, SHAKE128 and SHAKE256 message digests, and raw RSA operations. Along with these additions, 1.12.0 fixes bugs in RSA, AES, and DH exception and parameter handling, in certificate path validation and revocation checking, and in WKS KeyStore loading.

New JCE Functionality

  • Add Ed25519 / Ed448 support to Signature, KeyPairGenerator, and KeyFactory

  • Add EdDSA key and certificate storage to WKS KeyStore

  • Implement EdECPublicKey and EdECPrivateKey on JDK 15+

  • Add AES-XTS Cipher support as AES/XTS/NoPadding

  • Add AES Key Wrap (RFC 3394) Cipher support as AESWrap and AES/KW/NoPadding

  • Add AES-CFB Cipher support for CFB128, CFB8, and CFB1

  • Add SHAKE128 and SHAKE256 MessageDigest support

  • Add RSA/ECB/NoPadding Cipher for raw RSA operations

New JNI Functionality

  • Add new Ed448, AesXts, AesKeyWrap, AesCfb, and Shake classes

  • Add Ed25519 DER key import/export plus context and pre-hash sign/verify

  • Add raw RSA support: Rsa.direct()

  • Add native AES-GCM IV generation: AesGcm.setIV() and AesGcm.encryptEx()

  • Add WolfCrypt.getDigestSize() wrapping native wc_HashGetDigestSize()

  • Add a WolfCrypt.encryptedKeyPemToDer() overload

New Property Support

  • wolfjce.wks.maxIterations Security property – Bound the PBKDF2 iteration count accepted when loading WKS KeyStores (default 10,000,000)

Bug Fixes & Reliability Improvements

  • JCE exception behavior – Signature throws SignatureException for wrong-length RSA signatures and native signing errors, oversized RSA encrypt input throws IllegalBlockSizeException, AES-CCM tag mismatches throw AEADBadTagException, and Cipher.update() throws ShortBufferException before input is consumed.

  • AES parameters – Enforced 7 to 13 byte AES-CCM nonces, included the CCM auth tag in getOutputSize(), returned random IVs from getParameters() before init(), and allowed AES-GCM decrypt init() with null parameters.

  • RSA and DH – Rejected invalid RSA key sizes and exponents at KeyPairGenerator.initialize(), fixed default-salt RSA-PSS verify for small keys, fixed DH KeyAgreement.init() handling of DHParameterSpec, and fixed DH shared secrets for primes over 4096 bits, such as ffdhe8192.

  • Certificate path validation – Fixed PKIXCertPathChecker certificate ordering, PREFER_CRLS and NO_FALLBACK revocation behavior, reporting of revoked stapled OCSP responses as BasicReason.REVOKED, and evaluation of all keySize operators in jdk.certpath.disabledAlgorithms.

  • WKS KeyStore – Fixed loading from streams that return partial reads and ML-DSA key and cert matching with NULL SPKI algorithm parameters, and WolfCryptPBEKey passwords are now compared in constant time.

  • FIPS – Fixed FIPS RSA, DH, and ECC JNI wrappers passing wrong sizes on big-endian platforms, and the FIPS error callback leaving native threads attached to the JVM.

  • Memory safety – Stricter IV, key, input, and output buffer validation across native AES, 3DES, ChaCha, PBKDF, MD5, SHA, RSA, and ECC wrappers, overflow-safe bounds checks, and fixes for native context leaks.

New Examples

  • Added EdDSAExample, AesXtsExample, AesKeyWrapExample, AesCfbExample, and ShakeExample for new algorithms

  • Added Ed25519 / Ed448 certs and WKS KeyStores, updated expired example certs, keys, and KeyStores

  • Example scripts now run from any directory and handle paths containing spaces

  • Android example native libraries are linked with 16 KB page alignment for Android 15+

Expanded Testing & CI Infrastructure

  • GitHub Actions EdDSA build matrix on Linux and macOS

  • AES-XTS non-streaming fallback testing, and AES Key Wrap and raw RSA enabled in the Windows Visual Studio build

  • Known-answer and interop tests for the new AES modes, SHAKE, and EdDSA, plus new DH and ECC FIPS JNI wrapper tests

wolfCrypt JNI/JCE 1.12.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfCrypt JNI/JCE User Manual can be found here. Full details on this release can be seen in the ChangeLog.md on GitHub. For any questions or to get help using wolfSSL products in your projects, contact us at support@wolfssl.com.

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

Go to forum: Announcements

3 Topic by shizuka

(0 replies, posted in Announcements)

We are pleased to announce the release of wolfPKCS11 2.2.0. This release adds verify-only support for the LMS/HSS and XMSS/XMSS^MT stateful hash-based signature schemes, an option to ship wolfPKCS11 as a single self-contained library with wolfSSL linked in, and much faster token writes on custom storage backends.

It also delivers a large round of PKCS#11 compliance, memory-safety and concurrency hardening, along with fixes for TPM, Windows and NSS users.

New features
LMS/HSS and XMSS/XMSS^MT signature verification
wolfPKCS11 can now verify signatures from the two stateful hash-based signature families approved in NIST SP 800-208: LMS/HSS (RFC 8554) and XMSS/XMSS^MT (RFC 8391). Public keys are imported from their raw encoding, can be stored on the token, and are used through C_Verify with the standard PKCS#11 v3.3 CKM_HSS, CKM_XMSS and CKM_XMSSMT mechanisms.

Support is enabled with --enable-lms and --enable-xmss, and is off by default. This first step is verify only: key generation, private key import and signing are rejected.

A self-contained library with static wolfSSL
wolfPKCS11 can now link a static wolfSSL into libwolfpkcs11, using --with-static-wolfssl=/path/to/libwolfssl.a with Autotools or -DWOLFPKCS11_STATIC_WOLFSSL=yes with CMake. The module then ships as one library with no run-time dependency on libwolfssl.

The embedded wolfSSL symbols stay hidden, so an application that uses its own wolfSSL, even one built with a different configuration, can still load the module through dlopen() or wc_Pkcs11_Initialize(). This option needs an ELF linker and cannot be combined with wolfTPM support. As part of this work, the Autotools build now exports the PKCS#11 v3.0 and v3.2 functions, and the CMake build exports only the C_* functions.

Faster token writes
Creating or destroying a token object used to rewrite every object on the token. wolfPKCS11 now writes only the objects that change, and C_SetAttributeValue on a token object is stored straight away. On an STM32U585 running a wolfBoot TrustZone keystore, creating eight token objects dropped from 24.9 seconds to 6.3 seconds.

Security and compliance hardening
Much of this release closes findings from Fenrir, our internal code-scanning tooling, across PKCS#11 compliance, memory safety and concurrency. The main areas are:

  • Access control and login state: private objects are limited to user sessions, setting CKA_TRUSTED needs an SO session, login lockout counts also cover C_SetPIN, and closing all sessions now logs the application out.

  • Stored objects: each object's policy (class, key type, key generation mechanism and operation flags) is now bound to its encrypted key data as authenticated data. Stored records are validated before use, and store failures are reported and rolled back.

  • Operations and parameters: operation state is released when an operation is replaced, cancelled or fails. AES-GCM, AES-CCM, OAEP, PSS, CMAC, ECDH, DH, HKDF and TLS derive parameters are checked, and lengths that do not fit in 32 bits are rejected.

  • Templates and attributes: attribute templates are validated before an object is changed, and key material and certificate values are fixed once an object is created.

  • Zeroisation: key material and transient MAC, AES and RNG buffers are cleared after use and on error paths.

On the concurrency side, the internal read/write lock has been rewritten so it is never released by a thread that did not take it. We also fixed a double free when two sessions destroy the same token object, and a race where C_DestroyObject could remove a different object. ThreadSanitizer now runs in CI to keep it that way.

Object handles also stay unique when object IDs run out. Previously, after about 268 million objects, a session object could take the handle of an existing token object.

Notable fixes

  • TPM ECDH: EC keys generated on a TPM slot are now created with TPM capabilities that match CKA_SIGN and CKA_DERIVE, and ECDH runs on the TPM itself.

  • Windows: the PKCS#11 structures now use the 1-byte packing other PKCS#11 modules use on Windows, fixing crashes in applications that call through C_GetFunctionList. The default token path is now %APPDATA%\wolfPKCS11, and MinGW-w64, Cygwin and MSYS2 builds work again.

  • Default token path: WOLFPKCS11_DEFAULT_TOKEN_PATH is now used ahead of the home directory, and a path set with --with-default-token-path or CMake now works.

  • NSS: database paths with a sql:, dbm: or extern: prefix now work, and C_WrapKey no longer leaves an operation active after a length query, which broke pk12util -o.

  • PIN changes: C_SetPIN now re-encrypts protected token objects under the new token key, so they can still be read after the next C_Initialize.

  • Attributes: CKA_CHECK_VALUE is now computed by key type, and C_GetAttributeValue returns CKR_ATTRIBUTE_TYPE_INVALID for attributes an object does not have while still filling in the rest of the template.

  • Memory leak: decoding already-loaded keys at C_Login no longer leaks memory when wolfSSL is built with HAVE_WOLF_BIGINT, for example with --enable-pkcs11.

  • FIPS: the AES key wrap with padding code now builds against FIPS v5.2 modules.

Upgrading from 2.1
Some of these fixes change behaviour that applications or stored tokens may depend on. Please check the following before upgrading:

  • Stored tokens: tokens written by 2.1 and earlier load as before, and each object moves to the new policy-bound format the next time it is stored. Earlier releases cannot read the new format, so a token used with 2.2 cannot be moved back to 2.1.

  • Token path: the lookup order is now WOLFPKCS11_TOKEN_PATH, the NSS store directory, WOLFPKCS11_DEFAULT_TOKEN_PATH, then the home directory. Builds that set a default path and keep tokens in $HOME/.wolfPKCS11 should set WOLFPKCS11_TOKEN_PATH or move the token files.

  • Windows: applications must be rebuilt against the new headers because of the structure packing change. Define WOLFPKCS11_NO_PACKED_STRUCTS to keep the old layout.

  • AES-CMAC: CKM_AES_CMAC now produces and checks a full 16-byte MAC, where earlier releases used 8 bytes.

  • Check values: the CKA_CHECK_VALUE of a generic secret key is now the first three bytes of the SHA-1 hash of its value, as PKCS#11 3.2 defines.

  • Stricter checks: C_SetAttributeValue rejects changes to CKA_TOKEN, CKA_PRIVATE, CKA_MODIFIABLE, key components and certificate values. C_CreateObject requires the key or certificate value, and deriving, encapsulating or decapsulating into a private key needs a user login.

  • TPM EC keys: keys stored by earlier releases were created for signing only and cannot be used for ECDH.

The full list, including the smaller changes, is in the 2.2 release notes.

With thanks
Our thanks go to Peter Dennis Bartok for reporting the C_GetAttributeValue and CKA_CHECK_VALUE issues (#221, #245), and to Nazar Serhiichuk for reporting the Windows ABI issue (#208).

Get the release
wolfPKCS11 2.2.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

Go to forum: Announcements

4 Topic by shizuka

(0 replies, posted in Announcements)

wolfSSH v1.6.0 is now available. This release has five vulnerability fixes, strict key exchange enabled by default, ML-DSA host keys and user authentication, and the largest hardening pass wolfSSH has had. Several defaults have changed, so please read the Behavior Changes section before upgrading. See the ChangeLog.md for the full list.

Vulnerabilities
This release addresses five CVEs: one critical, one high, and three medium.

  • [Critical] CVE-2026-16516: The client did not check that the ECDSA curve in a server’s host key blob matched the negotiated algorithm. A man-in-the-middle could substitute a key on a different curve and pass verification. This also requires a lax public key check callback. It affects versions through 1.5.0. Thanks to zhangph (afldl).

  • [High] CVE-2026-83540: wolfSSHd on Windows shared one authentication context and logon token across concurrent connections. As a result, a user with a valid account could end up logged in as another, more privileged user. Non-Windows builds are unaffected. It affects 1.4.15 through 1.5.0 and was found by internal testing.

  • [Medium] CVE-2026-84897: A server accepted the DH GEX messages that only a server sends from an unauthenticated client. This let the client force expensive primality testing of an attacker-chosen group. It affects 1.2.0 through 1.5.0. Thanks to Abdullah Al Ishtiaq, Kai Tu, Matthew Carter, Xiaotian Zhou, Ananna Rahman, Yilu Dong, Tianwei Yu, Ali Ranjbar, and Syed Rafiul Hussain.

  • [Medium] CVE-2026-81535: With –enable-fwd, forwarded-tcpip channel opens bypassed the forwarding policy callback. A client also accepted these opens for forwards it never requested. It affects 1.4.8 through 1.5.0. Thanks to zhangph (afldl).

  • [Medium] CVE-2026-83742: A length wrap in wolfSSH_RealPath() let a crafted SFTP path write a NUL byte past the end of a stack buffer. It requires an authenticated session and affects 1.4.11 through 1.5.0 on non-Windows builds. Thanks to Asif Nadaf.

All wolfSSH users should upgrade. Users of wolfSSHd on Windows, and client applications with permissive public key check callbacks, should treat this as urgent.

Behavior Changes

  • v1.6.0 tightens many defaults. Changes most likely to affect existing applications:

  • wolfSSL must be built with –enable-wolfssh.

  • Strict KEX (the Terrapin mitigation) is on by default. You can opt out with wolfSSH_CTX_SetStrictKex().

  • The DH group exchange minimum is now 2048 bits. RSA user authentication keys must also be at least 2048 bits.

  • The “none” cipher and MAC require –enable-none-cipher.

  • The server disconnects after 6 failed authentication attempts. This is configurable with wolfSSH_CTX_SetMaxAuthAttempts().

  • Applications must now drain stderr. Ignoring WS_EXTDATA will exhaust the channel window.

  • A peer’s channel EOF is now reported as WS_EOF. Send your own with wolfSSH_ChannelSendEof().

  • wolfSSH_shutdown() may return WS_WANT_WRITE. Call it again until it completes.

  • Forwarding is stricter. forwarded-tcpip opens require a fwdCb, and the client refuses opens that don’t match a registered forward.

  • wolfSSHd changes:

    • StrictModes is enforced by default.

    • LoginGraceTime defaults to 120 seconds.

    • Sessions use a 022 umask.

    • Match is limited to User and Group.

New Features

  • Strict key exchange, with wolfSSH_GetStrictKexNegotiated().

  • ML-DSA-44, -65, and -87 host keys and user authentication, including X.509 and composite variants.

  • OpenSSH certificate user authentication in wolfSSHd (–enable-ossh-certs).

  • TPM-resident host keys, including X.509 host certificates.

  • Host keys from the Windows certificate store.

  • Builds with neither RSA nor ECDSA, such as Ed25519 only.

  • Client-side remote port forwarding.

  • SFTP session confinement with wolfSSH_SFTP_SetConfinePath().

  • Independent cipher and MAC negotiation in each direction.

  • Per-channel stderr flow control.

  • RFC 4254 half-close support.

  • Application-driven channels.

  • New wolfSSHd options:

    • PubkeyAuthentication.

    • prohibit-password and forced-commands-only for PermitRootLogin.

    • %u/%h expansion in AuthorizedKeysFile.

  • make sbom targets for CycloneDX and SPDX output.

Improvements and Fixes
This release has well over a hundred fixes, many from static analysis, fuzzing, and external audits. Highlights:

  • Validation of peer DH and ECDH public keys.

  • Bounded KEXINIT parsing, which closes a pre-auth CPU DoS.

  • Constant-time RSA verification.

  • Log injection sanitization.

  • SCP symlink hardening.

  • Per-session SFTP handle tracking and limits.

  • Zeroization of secrets.

  • A fix for a wolfSSHd user enumeration timing oracle.

  • Fixes for several fail-open wolfSSHd Match defects.

  • Corrected SFTP and SCP behavior across rekeys and on Windows, Zephyr, and Harmony.

  • FIPS wolfSSL fixes for DH-GEX and agent RSA signing.

Thanks to everyone who reported issues this cycle.

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

Go to forum: Announcements

5 Topic by shizuka

(0 replies, posted in Announcements)

wolfSSL 5.9.4 is now available with new cryptographic algorithms, expanded post-quantum support, new hardware ports, significant assembly performance work, and a number of vulnerability fixes. Users are always recommended to stay up to date with wolfSSL releases. In this release the use cases affected by high severity reports are: trusted peer certificates (WOLFSSL_TRUST_PEER_CERT, including builds using OPENSSL_COMPATIBLE_DEFAULTS such as –enable-nginx, –enable-haproxy, –enable-all and –enable-distro), client-side multiple OCSP response stapling (HAVE_CERTIFICATE_STATUS_REQUEST_V2 with WOLFSSL_CSR2_OCSP_MULTI), and client-side Raw Public Keys (–enable-rpk, –enable-all, –enable-distro).

Vulnerabilities
This release addresses 11 CVEs (3 high, 4 medium, 4 low), down from 32 in 5.9.2. Most of them apply only to specific, non-default build configurations or API usage. Highlights include certificate validation fixes for name constraints, trusted peer matching and OCSP/CRL fallback, a (D)TLS 1.2 client ChangeCipherSpec ordering fix, and a session cache reference fix for TLS 1.2 resumption. Thanks to all the researchers who responsibly disclosed issues, including the Anthropic OSS program, Cantina Security, Jorge Milla (Pig-Tail), PathDiff, the Fuzz0x team, Jack Lloyd, Ben Smyth, and several independent contributors.

For the full list of vulnerabilities addressed, visit the wolfSSL Vulnerability Page.

Important Notes

  • liboqs is no longer used for any algorithm. Falcon now has a native wolfCrypt implementation, and the liboqs dependency and its configure and CMake options have been removed.

  • Certificates carrying trailing bytes after the DER structure are now rejected unless WOLFSSL_NO_ASN_STRICT is defined.

  • –disable-tlsv12 now truly compiles TLS 1.2 out, and WC_RNG gains a per-instance lock and fork handlers by default so one RNG can be shared between threads and across fork().

  • Under FIPS, HMAC-MD5 is rejected, short AES-GCM IVs return FIPS_BAD_VALUE_E, the CMAC minimum tag is 64 bits, and RSA-PSS salts longer than the hash are refused (FIPS 186-5).

New Features

  • New algorithms: Argon2 (RFC 9106) password hashing, AES-GCM-SIV (RFC 8452), KMAC and cSHAKE (SP 800-185), AES Key Wrap with Padding (RFC 5649), and a Time-Stamp Protocol (RFC 3161) implementation.

  • –enable-tinytls13 — a TLS 1.3-only footprint profile (PSK + ECDHE floor with optional minimal X.509).

  • TLS receive read-ahead (–enable-readahead) to cut the number of recv() calls per record, plus zero-copy AEAD encryption on the send path.

  • Runtime policy APIs to require an external PSK in (D)TLS 1.3 and to enforce Extended Master Secret.

  • SBOM generation with make sbom (SPDX 2.3 + CycloneDX 1.6) and make bomsh (OmniBOR build provenance) to support EU Cyber Resilience Act compliance.

  • WOLFSSL_X509_TINY and WOLFSSL_X509_VERIFY_ONLY certificate parser profiles, and true zero-allocation X.509 verification for WOLFSSL_NO_MALLOC builds.

Post-Quantum Cryptography Updates

  • Native Falcon (levels 1 and 5) with crypto callbacks and ARM DSP / AArch64 NEON acceleration, replacing the liboqs wrapper

  • FrodoKEM added with C and assembly for x86_64, AArch64, AArch32 and Thumb2, plus ASN.1 keys and X.509 certificates.

  • SLH-DSA (FIPS 205) authentication in the TLS 1.3 and DTLS 1.3 handshake for all twelve parameter sets.

  • Post-quantum-only TLS 1.3 builds — ML-KEM key exchange with ML-DSA or SLH-DSA authentication and no RSA/ECC/DH.

  • ML-DSA for PKCS#7/CMS SignedData (RFC 9882) and in the OpenSSL compatibility layer.

  • AVX512 assembly for ML-KEM and ML-DSA, a constant-time ML-DSA low-bits check, and a new –enable-all-quantum-crypto bundle.

TLS and DTLS Improvements

  • RFC 9846 (TLS 1.3 update) conformance work, including the general_error alert, key update limits, and NewSessionTicket hardening.

  • Extended Key Usage is now enforced on chain-supplied intermediate CAs.

  • RFC 5746 renegotiation_info is checked by default on TLS 1.2 clients, and SHA-1 signature schemes are no longer offered by default for TLS 1.2.

  • DTLS: rotatable cookie secrets, DTLS 1.2 Connection ID support, stricter peer address handling, and many DTLS 1.3 correctness fixes.

  • New dtls_bench DTLS throughput benchmark with an optimized DTLS send path.

Hardware and Embedded Ports

  • STM32 bare-metal crypto port (no HAL required) with DHUK (Device Hardware Unique Key) hardware-protected keys, validated on a 27-board reference matrix spanning about 20 STM32 families, plus STM32V8 (Cortex-M85) and STM32CubeMX2 support.

  • New ports for the RealTek AmebaPro2, WISeKey/SealSQ VaultIC, Vorago VA416x0 TRNG, and the TI C2000 C28x DSP family.

  • SE050/SE05x enhancements including on-chip key generation, SCP03 key rotation and attestation, plus Zephyr, NetX, Renesas, NXP and other port fixes.

Assembly and Performance

  • New Intel x64 AES assembly using AVX512/VAES, AVX512 ChaCha20-Poly1305, and AVX512 IFMA X25519/Ed25519.

  • AArch64 and ARM32 runtime CPU feature dispatch, new PPC64/PPC32 AES and SHA assembly, and a full RISC-V 64-bit SP implementation.

Build System

  • CMake gains ~100 options and 37 application bundles to match autotools.

  • Linux and FreeBSD kernel module improvements, and FIPS v7 readiness work.

Rust Wrapper

  • Released versions 2.1.0 and 2.2.0 of the wolfssl-wolfcrypt Rust crate, with the dilithium module renamed to mldsa and numerous build-option gating fixes.

Get the Update
Dive into the full ChangeLog for a complete list of changes.

If you have any questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

Go to forum: Announcements

6 Topic by shizuka

(0 replies, posted in Announcements)

We are excited to announce wolfCOSE 2.0.0, a major update to wolfSSL’s complete, zero-allocation C implementation of CBOR (RFC 8949) and COSE (RFC 9052) built on wolfCrypt. This release adds standardized HSS/LMS stateful hash-based signatures, RFC 9338 countersignatures, RFC 9783 PSA/EAT attestation, RFC 9864 fully specified signature algorithms, delegated signing, and experimental COSE-HPKE, while preserving the small and deterministic memory profile required by embedded systems.

Feature 1: HSS/LMS Stateful Hash-Based Signatures
v1.0.0 shipped ML-DSA (FIPS 204 / RFC 9964) at all three security levels. v2.0.0 adds the second NIST-standardized post-quantum family, HSS/LMS, using the COSE representation from RFC 8778. It works with COSE_Sign1, multi-signer COSE_Sign, delegated signing, and lean sign-only or verify-only profiles.`


Feature 2: PSA/EAT Attestation and Delegated Signing
v2.0.0 adds RFC 9783 PSA/EAT attestation token issuance and verification in both COSE_Sign1 and COSE_Mac0 envelopes, with UEID-selected key resolution, software-component iteration, current and legacy profiles, and compile-time gates so a device that only issues tokens does not link the verifier.

Attestation keys rarely leave the hardware that owns them, so delegated signing lets an HSM, secure element, PSA Crypto service, or remote KMS produce the signature while wolfCOSE builds and parses the message. The private key never enters wolfCOSE, and the same path covers COSE_Sign1, COSE_Sign, ML-DSA, and HSS/LMS.

Feature 3: RFC 9338 Countersignatures
v2.0.0 adds full and abbreviated RFC 9338 countersignatures across all six tagged message types. A second party can endorse an existing message in place and have it verified independently, which is what approval chains, audit evidence, and multi-party authorization need, without rebuilding the original COSE message.

Default Algorithm Identifiers Now RFC 9864
RFC 9864 replaces the polymorphic RFC 9053 signature identifiers with fully specified algorithms that bind the algorithm to its intended curve. wolfCOSE 2.0.0 uses ESP256, ESP384, ESP512, Ed25519, and Ed448 by default.

Behavior change: the deprecated ES256, ES384, ES512, and EdDSA identifiers require WOLFCOSE_ENABLE_DEPRECATED_ALGS. Since the protected algorithm identifier is covered by the signature, an existing message cannot be relabeled; it must be re-signed.

Experimental COSE-HPKE
v2.0.0 includes experimental COSE-HPKE P0 support for COSE_Encrypt0 and multi-recipient COSE_Encrypt, with command-line support and automated tests. It requires both WOLFCOSE_EXPERIMENTAL and the selected HPKE operation gates, keeping draft protocol behavior out of production builds unless an application asks for it.

Other v2.0.0 Release Improvements

  • COSE_Key and CBOR API expansion: exact encoded-size queries, public-only key encoding, raw ECC coordinate support, metadata inspection before key import, safer context initialization, and zero-copy capture of skipped CBOR items.

  • STM32 integration: the I-CUBE-wolfCOSE pack gives drop-in STM32CubeMX and STM32CubeIDE integration with an on-device test.

  • MISRA C:2012 and C:2023 checked, with release qualification covering C and C++ compilation, Valgrind, merged coverage, and reproducible source archives.

  • Expanded CI: cppcheck, Clang analyzer, GCC -fanalyzer, and Coverity; CodeQL and Semgrep; ASan and UBSan; plus interoperability testing against t_cose/QCBOR, go-cose, python-cwt, Rust coset, OpenSSL, and RFC vectors.

Getting Started
wolfCOSE requires wolfSSL 5.8.0 or later as its crypto backend, and wolfSSL 5.9.2 or later for ML-DSA.

git clone https://github.com/wolfSSL/wolfCOSE.git
cd wolfCOSE
git checkout v2.0.0
make
make test

wolfCOSE is dual-licensed under GPLv3 and a commercial license. For commercial licensing, FIPS 140-3 integration, custom ports, or help deploying post-quantum COSE, contact facts@wolfssl.com or support@wolfssl.com, or call +1 425 245 8247. We would love to hear what you are building.

Download wolfSSL Now

Go to forum: Announcements

7 Topic by shizuka

(0 replies, posted in Announcements)

wolfTPM 4.2.0 centers on TCG TPM 2.0 v1.85 specification compliance in the firmware TPM (fwTPM), expanded post-quantum support up to TLS 1.3 authentication, and new platform backends. The result is a portable, hardware-backed root of trust that is standards-compliant and quantum-ready on hardware ranging from microcontrollers to Linux edge devices.

TPM 2.0 v1.85 Specification Compliance in the fwTPM
The firmware TPM received a broad round of TCG v1.85 conformance work so that it behaves like a certified discrete TPM on the paths used by measured boot and attestation:

  • Command-code masking and corrected vendor-bit return codes (PR #556)

  • PolicyAuthorize compliance and corrected response codes for the keySign name ticket and approvedPolicy (PRs #567, #572)

  • Authenticated object context blobs on ContextSave / ContextLoad (PR #568)

  • Rejecting unsupported LoadExternal private types, corrected creation-ticket HMAC ordering, and ML-DSA / ML-KEM template validation in LoadExternal and CreateLoaded (PRs #573, #578)

  • NV space authorization validation and v1.85 revision reporting (PR #575)

  • Corrected command-attribute reporting, the verified-ticket HMAC algorithm, and SPDM responder version negotiation (PRs #577, #579, #584)

Post-Quantum Authentication for TLS 1.3
v4.2.0 extends post-quantum support from primitives to a complete authentication flow:

  • TPM-backed ML-DSA authentication for post-quantum TLS 1.3, with a complete example and tests (PR #559)

  • SealSQ QVault post-quantum TPM support (PR #570)

  • ML-KEM credential activation and ML-DSA quotes in the fwTPM (PR #592)

The --enable-pqc, --enable-mldsa, and --enable-mlkem build options limit the post-quantum footprint to the operations your product performs.

New Platform and HAL Backends
This release adds two new ways to reach the TPM:

  • wolfHAL I2C and SPI backends, enabled with --enable-wolfhal and an application-supplied board.h (PR #562)

  • NVIDIA Jetson Orin (Tegra234) OP-TEE firmware TPM, reached through the Linux TPM kernel driver as /dev/tpmrm0 (PR #576)

  • Finer per-command-group gating macros in the fwTPM for tighter code-size control (PR #574)

  • Caller-supplied policy authorization for firmware upgrade (PR #560)

Also in This Release
ST33 firmware update: corrected Generation 1 manifest sizing with oversized-command rejection (PR #583) and field-upgrade command selection from the TPM command set (PR #586).

Performance: reused transport connections and reduced NV-write and hash-cache overhead (PR #563).

Build and licensing: fixes for AES_BLOCK_SIZE under OpenSSL coexistence (PR #552), TIS-lock builds without wolfCrypt (PR #564), and --enable-pqc with --disable-wolfcrypt (PR #606); refreshed example CA certificates with a refresh script (PR #601); new contribution guidance (PR #569); and a GPLv2 exception allowing wolfTPM combined with U-Boot from Cisco Systems, Inc. to be licensed under GPLv2 (PR #557).

Security Hardening
v4.2.0 includes a security-hardening pass driven by Fenrir, Coverity, static analysis, negative testing, and input-validation review. The changes include hardening of the crypto callback, ASN.1 parsing, parameter encryption, and marshalling (PR #551); bounded response decrypt-parameter sizing with primary-key auth zeroization (PR #555); fixes for a fwTPM response buffer overflow and an SPDM clear-frame command bypass (PR #561); a wolfCrypt refcount race fix in P521 primary derivation and a policy-session authorization-bypass fix (PR #571); transactional fwTPM state changes with hardened PolicyPCR and private-blob wrapping (PR #593); and a further set of fwTPM protocol, key-derivation, zeroization, and bounds fixes (PRs #554, #558, #565, #581, #582, #588, #591, #595, #596, #597, #598, #599, #600, #603, #604, #605, #608).

Getting Started

git clone https://github.com/wolfSSL/wolfTPM.git
cd wolfTPM
git checkout v4.2.0
./autogen.sh
./configure --enable-fwtpm –enable-swtpm
make && make check

The full change log is available in ChangeLog.md.

For commercial licensing, FIPS 140-3 integration, DO-178C DAL A qualification kits, custom HAL ports, or help deploying TPM 2.0 v1.85 post-quantum, contact facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Go to forum: Announcements

8 Topic by shizuka

(0 replies, posted in Announcements)

wolfEngine version 1.4.1 is officially here. Built as an OpenSSL engine backed by the wolfCrypt FIPS 140-3 cryptographic module, wolfEngine brings FIPS-validated cryptography to legacy OpenSSL 1.0.2 and 1.1.1 applications without requiring application code changes. This update delivers critical security fixes for two TLS AEAD nonce-reuse vulnerabilities, along with FIPS enhancements and a comprehensive hardening pass.

Interoperability and FIPS Enhancements

  • AES-CTR no longer reinitializes after keying, preserving proper state across operations.

  • ECC and MAC modules now interoperate smoothly with OpenSSL 1.0.2r.

  • Replaced AES_BLOCK_SIZE with WC_AES_BLOCK_SIZE across all source files.

  • Integrated mandatory initialization logic required by the current wolfSSL-FIPS module.

  • Added simplified build scripts and resolved path issues for non-standard install locations.

Security Hardening
The 1.4.1 release includes a thorough code cleanup to harden the engine against edge-case failures. Control handlers for AES-ECB, AES-CBC, and DES3-CBC now have corrected NULL checks, while key object cleanup logic for RSA, DH, and ASN.1 has been hardened against assignment errors. ASN.1 parsing for ECDSA signatures and HMAC enforces strict length bounds, and TLS record lengths for AES-CBC-HMAC are validated against underflow. Additionally, private-key BIGNUMs, buffered GCM plaintext, and derived keys are zeroized immediately after use. Pre-set DH private keys longer than the prime are also rejected during key generation, closing a heap write vulnerability.

Security Fixes

CVE-2026-81020, AES-GCM Nonce Reuse on TLS 1.2 and DTLS 1.2
Severity, High. Affects wolfEngine 0.9.0 through 1.4.0.
The 8-byte explicit nonce was generated once and failed to increment per record. Because every AES-GCM record within a connection reused the same key and nonce pair, both confidentiality and integrity were compromised. TLS 1.3 and non-TLS uses are unaffected. This impacts wolfEngine versions 0.9.0 through 1.4.0 in both FIPS and non-FIPS builds.

CVE-2026-81341, AES-CCM Nonce Reuse on TLS 1.2 and DTLS 1.2
Severity, Medium. Affects wolfEngine 0.9.0 through 1.4.0.
The explicit nonce was pulled from the record input buffer instead of the TLS sequence number, causing static nonce reuse across records. Exposure is reduced because AES-CCM cipher suites require explicit opt-in. TLS 1.3 and non-TLS modes remain unaffected. This impacts versions 0.9.0 through 1.4.0.

Download and Upgrading
Anyone using TLS 1.2 or DTLS 1.2 with AES-GCM or AES-CCM through wolfEngine should update to 1.4.1 immediately.

Grab the latest release on GitHub at https://github.com/wolfSSL/wolfEngine and review the included ChangeLog for full release notes.

For general questions, FIPS 140-3 details, or commercial licensing, contact facts@wolfssl.com. For technical support, reach out to support@wolfssl.com.

Download wolfSSL Now

Go to forum: Announcements

9 Topic by shizuka

(0 replies, posted in Announcements)

wolfProvider version 1.2.2 is now available. As an OpenSSL 3.x provider, wolfProvider routes cryptographic operations through the wolfCrypt FIPS 140-3 module, allowing existing OpenSSL applications to gain a FIPS-validated cryptographic core without modifying any application code. This release introduces native Windows support, PKCS#8 private-key encryption, FIPS build hardening, and a high severity security fix for AES-GCM in TLS 1.2.

Windows and Visual Studio 2022 Support
wolfProvider now compiles natively on Windows using Visual Studio 2022, building libwolfprov.dll against OpenSSL 3.x and wolfSSL configured via user_settings.h. Both non-FIPS and FIPS configurations are fully supported, bringing the same integration Linux users rely on directly to Windows environments.

PKCS#8 Private-Key Encryption
The PKCS#8 encoder now encrypts private keys whenever a cipher is assigned on the PrivateKeyInfo encoder. This ensures encrypted PKCS#8 output works smoothly through the provider as callers expect. This update also tightens PKCS#8 feature guards and expands cipher-rejection test coverage.

FIPS and Interoperability Enhancements

  • Restored the default FIPS policy mask in WOLFSSL_USER_SETTINGS builds, added portable FIPS CAST-mutex initialization, and balanced wolfCrypt init and cleanup calls.

  • Stopped advertising SHA-512/224 and SHA-512/256 in FIPS and self-test builds.

  • Matched OpenSSL’s ML-KEM NULL output handling.

  • Expanded hostap smoke tests and EAP test coverage in CI.

Additional fixes, including X25519 public-key length validation and buffer sizing for ECX/ECC get_params, can be found in the included ChangeLog.

Security Fixes
CVE-2026-81019, AES-GCM Explicit Nonce Reuse on TLS 1.2 and DTLS 1.2

Severity, High. Affects wolfProvider 1.0.0 through 1.2.1.
The 8-byte explicit nonce was generated when setting up the fixed IV, but it did not increment for subsequent records. Because successive AES-GCM records within the same encryption context reused the exact same key and nonce pair, confidentiality was weakened by repeated keystreams and integrity was vulnerable to authentication tag forgery. TLS 1.3, and non-TLS uses of AES-GCM are unaffected. This impacts wolfProvider versions 1.0.0 through 1.2.1 across both FIPS and non-FIPS builds.

Download and Upgrade
Anyone running TLS 1.2 or DTLS 1.2 with AES-GCM through wolfProvider should update to 1.2.2 immediately.

You can find the release on GitHub at https://github.com/wolfSSL/wolfProvider alongside the full ChangeLog.

For questions on wolfProvider, FIPS 140-3, or commercial licensing, reach out to facts@wolfssl.com. For direct technical assistance, contact support@wolfssl.com.

Download wolfSSL Now

Go to forum: Announcements

10 Topic by shizuka

(0 replies, posted in Announcements)

The wolfSSL team is pleased to announce wolfBoot 2.9.0, expanding hardware support, adding new image and cryptographic options, and continuing security hardening across boot and update flows.

More Hardware Targets
wolfBoot 2.9.0 adds support for several new platforms, including:

  • STM32N6, STM32U3, STM32C5, STM32G4 and STM32WBA

  • NXP LPC54S018M-EVK and Kinetis KL26

  • Xilinx Zynq-7000 ZC702

  • NXP T2080 and CW VPX3-152 with VxWorks 7 64-bit boot support

Existing ports also received significant updates. wolfHAL is now integrated into wolfBoot, with an STM32WB example, while STM32H5 gains firmware TPM support in TrustZone and a wolfHSM-backed TrustZone engine.

Additional improvements include hardware cryptography on LPC55S69, hardware-based DICE attestation on NXP MCXN, enhanced PolarFire SoC M-mode support, improved ZynqMP Linux boot, and fixes for Vorago VA416x0 shadow updates.

New Features
wolfBoot 2.9.0 adds RSA-PSS image signatures and a generic crypto-callback interface for hardware-accelerated cryptography.

FIT image support has been extended to handle gzip-compressed kernels and ramdisks, including initramfs, as well as FPGA bitstreams.

The release also introduces:

  • Boot benchmarking

  • One-shot hashing

  • Monolithic self-update optimizations

  • Multi-root-CA verification and keystore-less operation with wolfHSM

  • Pre-computed IDevID authentication values

  • Persistent boot and update failure diagnostics

  • An sbom Makefile target generating CycloneDX and SPDX output for software-transparency and CRA-readiness workflows

Security Hardening
This release continues Fenrir fuzzing-driven hardening across image parsing and update paths.

New checks bound unauthenticated image sizes before loading them into RAM, enforce memory-copy limits during disk updates, and strengthen image authenticity and integrity verification against fault injection.

The release also fixes several LMS, XMSS, OTP keystore, device-tree, self-update and unit-test issues, while ensuring sensitive DICE claim data is zeroized after use.

Download it now
wolfBoot 2.9.0 is available on our download page and on GitHub, bringing broader platform coverage, stronger hardware integration and continued improvements to secure firmware verification and update reliability.

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

Go to forum: Announcements

11 Topic by shizuka

(0 replies, posted in Announcements)

wolfTPM v4.1.0 delivers the post-quantum upgrade path we promised in v4.0.0, alongside a major round of firmware TPM (fwTPM) hardening. It delivers three headline capabilities:

  • TPM 2.0 v1.85 Post-Quantum Cryptography: ML-DSA and ML-KEM native and in the fwTPM.

  • fwTPM Hardening: Dictionary Attack protection to the TCG spec, SPDM secured transport, and session, policy, and NV fixes.

  • Runtime TPM Locality Control: select locality 0-4 at runtime with a single API call.

All of it runs on the same wolfCrypt engine trusted in FIPS 140-3 and DO-178C DAL A deployments.

Feature 1: TPM 2.0 v1.85 Post-Quantum Cryptography
v4.0.0 shipped with post-quantum support listed as coming soon. It is here. The fwTPM now implements the TPM 2.0 v1.85 post-quantum algorithms: ML-DSA sign/verify and ML-KEM encapsulate/decapsulate, with seed handling to TCG Phase B, ML-DSA primary keys via TPM2_CreateLoaded, PQC parameter encryption in the examples, and dedicated PQC CI and fuzz coverage.

Build Only What You Use
Post-quantum keys and code are large, so v4.1.0 adds layered build macros to trim the PQC footprint to the operations you actually perform:

--enable-pqc                          # lean ML-DSA + ML-KEM subset
--enable-mldsa[=all|sign-only|verify-only|no]
--enable-mlkem[=all|enc|dec|no]
--disable-hash-mldsa

–enable-pqc now selects the lean PQC subset, while –enable-v185 remains the full specification build. Per-algorithm (WOLFTPM_MLDSA, WOLFTPM_MLKEM) and per-operation macros each have a matching WOLFTPM_NO_* opt-out. New _ex session, OAEP, and PQC-hash wrappers round out the API, and the build enforces a wolfSSL v5.8.0+ PQC floor with upstream-drift CI.

Feature 2: fwTPM Hardening
The firmware TPM introduced in v4.0.0 received a major round of work to close the gap with discrete hardware.

Dictionary Attack Protection to the TCG Spec

  • noDA honored on objects (TPMA_OBJECT_noDA), not just NV indices.

  • failedTries persisted in NV, including the non-orderly-shutdown +1 penalty.

  • recoveryTime self-heal and separate lockoutRecovery, with DA properties reported via TPM2_GetCapability.

  • New wrappers wolfTPM2_DictionaryAttackLockReset and wolfTPM2_DictionaryAttackParameters, a da_check example, and a CI retry harness.

Sessions, Policy, and NV

  • Transient state kept across command-port reconnects.

  • continueSession set in the password-auth response, and PolicyAuthorize zero-ticket handling.

  • Append-only NV journal for write-once flash ports.

  • Optional transparent TPM_RC_RETRY handling for TPMs that momentarily report busy. Opt in via TPM2_SetCommandRetries or -DWOLFTPM_MAX_RETRIES=N.

  • SPDM secured transport extended to the fwTPM, and FIPS 140-3 capability reporting.

Feature 3: Runtime TPM Locality Control
TPM locality lets a platform distinguish measurements made by trusted early boot code (DRTM) from ordinary software. The new wolfTPM2_SetLocality(dev, locality) API selects locality 0-4 at runtime, and the PCR reset example takes a -loc=n flag. It works on the TIS/SPI driver and the fwTPM over socket and TIS/SHM; platforms without a locality interface cleanly return NOT_COMPILED_IN.

The fwTPM per-PCR locality enforcement was replaced with a single source-of-truth table matching the TCG PC Client profile. Behavior change: DRTM PCRs 17-22 can no longer be extended from locality 0, exactly as the specification requires.

Other v4.1.0 Release Improvements

  • New crypto-primitive examples (getrandom, hash, AES, ECDH) and a WOLFTPM2_ECC_DEFAULT_CURVE option.

  • Optional hardware-reset HAL: –enable-hal-reset pulses the nRST line via the Linux GPIO char device.

  • Freestanding builds via WOLFTPM_NO_STD_HEADERS for bare-metal targets without a standard C library.

  • SBOM generation (make sbom): CycloneDX and SPDX documents for EU Cyber Resilience Act (CRA) compliance.

  • Fixed TPM_CAP_ALGS / TPM_CAP_COMMANDS capability paging, and Nations NS350 example fixes.

  • Extensive security hardening: automated Fenrir review, Coverity fixes across the fwTPM paths, and CodeQL/Semgrep review gates.

  • CI and build improvements: expanded CMake tests, a GHCR container image, and nightly fuzzing.

Getting Started

git clone https://github.com/wolfSSL/wolfTPM.git
cd wolfTPM
git checkout v4.1.0
./configure --enable-fwtpm --enable-pqc
make && make check

  • Examples: examples/ directory, including the new da_check, PCR-locality, and crypto-primitive demos.

For commercial licensing, FIPS 140-3 integration, DO-178C DAL A qualification kits, custom HAL ports, or help deploying TPM 2.0 v1.85 post-quantum, contact facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Go to forum: Announcements

12 Topic by shizuka

(0 replies, posted in Announcements)

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

Go to forum: Announcements

13 Topic by shizuka

(0 replies, posted in Announcements)

We are excited to announce the first stable release of wolfCOSE 1.0.0, a complete, zero-allocation C implementation of CBOR (RFC 8949) and COSE (RFC 9052/9053) built on top of wolfCrypt. wolfCOSE brings standards-based signing, encryption, and authentication of CBOR data to even the smallest embedded targets, with a tiny footprint, no dynamic memory, and a clear path to FIPS 140-3.

What is COSE?
COSE (CBOR Object Signing and Encryption) is the compact, binary counterpart to JOSE/JWT. Where JOSE secures JSON, COSE secures CBOR, the concise binary data format used across IoT, firmware update (SUIT), attestation (EAT), W3C WebAuthn, and digital credentials. COSE is the cryptographic message format of choice when every byte and every allocation counts, which makes it a natural fit for the constrained devices wolfSSL has always targeted.

A complete COSE implementation
wolfCOSE 1.0.0 implements all six COSE message types from RFC 9052, in both single-actor and multi-actor forms:

  • COSE_Sign1 / COSE_Sign: single-signer and multi-signer signatures

  • COSE_Encrypt0 / COSE_Encrypt: single-recipient and multi-recipient encryption

  • COSE_Mac0 / COSE_Mac: single-key and multi-recipient authentication

It ships with its own dependency-free CBOR engine (RFC 8949) that enforces deterministic/preferred encoding and rejects non-preferred or trailing input on decode, plus full COSE_Key / COSE_KeySet serialization, including complete RFC 8230 RSA private keys.

40 algorithms, including post-quantum
wolfCOSE 1.0.0 supports 40 algorithms across signing, encryption, MAC, and key distribution (RFC 9053):

  • Signing: ES256/384/512, EdDSA (Ed25519/Ed448), PS256/384/512

  • Encryption: AES-GCM (128/192/256), AES-CCM variants, ChaCha20-Poly1305

  • MAC: HMAC-SHA256/384/512, AES-MAC

  • Key distribution: Direct, AES Key Wrap, ECDH-ES + HKDF

  • Post-quantum: ML-DSA-44/65/87

Of particular note is standardized post-quantum signing: wolfCOSE implements ML-DSA (FIPS 204) at all three security levels, conformant to RFC 9964 (“ML-DSA for JOSE and COSE”), using the RFC 9964 AKP key type. This lets you sign and verify CBOR objects with quantum-resistant signatures today, using the canonical, standards-track encoding.

Built for embedded: zero allocation, tiny footprint
wolfCOSE was designed from the start for deeply embedded use:

  • Zero dynamic allocation. Every operation uses caller-provided buffers, with no heap and no hidden .data or .bss. Memory use is deterministic, which matters for safety-critical and FIPS deployments.

  • Tiny footprint. An ES256 COSE_Sign1 build is roughly 5.1 KB verify-only and 6.8 KB sign + verify for the wolfCOSE COSE + CBOR engine.

  • Lean configuration layer. WOLFCOSE_LEAN, WOLFCOSE_HAVE_* feature gates, verify-only profiles, and a bounded-stack WOLFCOSE_MIN_BUFFERS mode let you compile in only what you need. Verify-only ECC images link cleanly against sign-disabled wolfCrypt.

Quality and standards

  • Path to FIPS 140-3 through wolfCrypt FIPS Certificate #4718. wolfCrypt is wolfCOSE’s sole cryptographic dependency.

  • MISRA C:2012 and C:2023 checked.

  • Extensively tested: ~240 algorithm-combination round-trips, static analysis (cppcheck, Clang analyzer, GCC -fanalyzer, Coverity), CodeQL and Semgrep security scanning, ASan/UBSan sanitizers, and a wolfCOSE ? t_cose wire-interop conformance suite.

  • Standards implemented: RFC 8949 (CBOR), RFC 9052/9053 (COSE), RFC 8230 (RSA keys for COSE), and RFC 9964 (ML-DSA for JOSE and COSE).

Getting wolfCOSE
wolfCOSE requires wolfSSL 5.8.0 or later as its crypto backend (post-quantum ML-DSA requires wolfSSL 5.9.2 or later). It is a Makefile-only project whose only dependency is wolfCrypt. Run make, make test, and you are running.

Source: https://github.com/wolfSSL/wolfCOSE
Release: https://github.com/wolfSSL/wolfCOSE/releases/tag/v1.0.0
Documentation: see the project README and wiki

wolfCOSE is dual-licensed under GPLv3 and a commercial license. If you are building a product and need commercial licensing, FIPS, or support, please reach out.

Have questions, or want to tell us about your COSE use case? Contact us any time at facts@wolfssl.com or support@wolfssl.com, or call +1 425 245 8247. We would love to hear what you are building.

Download wolfSSL Now

Go to forum: Announcements

14 Topic by shizuka

(0 replies, posted in Announcements)

wolfSSL 5.9.2 has been released with a broad range of new features and enhancements around Post-Quantum Cryptography, crypto callback support, our Rust wrapper, and embedded hardware support. Similar to wolfSSL 5.9.1, a large number of CVEs are addressed in this release, along with general bug fixes. Additionally, there are some security hardening behavior changes we want to note.

Vulnerabilities
This release addressed 32 CVEs in total, which is in line with the previously discussed trend of AI-driven CVE reporting. While this is an increase in absolute number over the previous release, it is important to note a few points:

  • The number of [High] and [Critical] CVEs actually decreased.

  • The time between releases 5.9.2 and 5.9.1 (~ 2 months) was larger than between 5.9.1 and 5.9.0 (< 1 month).

  • The [High] CVEs this release were more narrow in scope, constrained mainly to specific OpenSSL compatibility API, or features that are disabled by default.

Use cases that are affected by [High] severity CVEs are: X509 verification with –enable-opensslextra with the API X509_verify_cert(), DTLS 1.3, the Renesas TSIP TLS port (WOLFSSL_RENESAS_TSIP_TLS) with TLS 1.3, X509 chain validation with Raw Public Key support (HAVE_RPK), and the OpenSSL compatibility API PKCS7_verify().

We would like to thank the many researchers from teams at NVIDIA Project Vanessa, Anthropic, UC Berkeley Sky Lab, as well as all the many independent contributors who responsibly disclosed these vulnerabilities.

See our wolfSSL Vulnerability page for the full list.

New Features

  • wolfCrypt SRAM PUF (Physically Unclonable Function) support, deriving device-unique keys from SRAM power-on state using a BCH fuzzy extractor and HKDF (wc_PufInit, wc_PufEnroll, wc_PufReconstruct).

Security Hardening / Behavior changes

  • FIPS 205 SLH-DSA: The SLH-DSA sign/verify hash APIs now take a pre-hashed message digest instead of a raw message (callers must now hash the message before invoking these APIs). This brings SLH-DSA’s behavior in line with ML-DSA’s wc_dilithium_{sign,verify}_ctx_hash API, as well as NIST’s ACVP signature interface.

  • FIPS 204 ML-DSA: We renamed the post-quantum signature implementation from its pre-standardization name Dilithium to its NIST-standardized name ML-DSA (mirroring the earlier Kyber to ML-KEM rename). The header wolfssl/wolfcrypt/dilithium.h remains for now as a temporary compatibility shim.

  • Our CmacVerify APIs were hardened to more closely conform to NIST SP 800-38B MAC length guidance, and these verify functions will now correctly enforce bounds on tag length checks.

Crypto Callbacks

  • Added wc_swdev, a software CryptoCb device used by our test programs to exercise WOLF_CRYPTO_CB_ONLY_* builds.

  • Added CryptoCb support for SLH-DSA.

Post Quantum Cryptography

Hardware and Embedded Ports

Rust Wrapper

Pruning / Cleanup

  • The liboqs SPHINCS+ implementation was replaced with our own SLH-DSA.

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

Go to forum: Announcements

15 Topic by shizuka

(0 replies, posted in Announcements)

wolfCLU release 0.2.0 is now available. Major feature additions were added; dual-algorithm certificates, a full OCSP client/responder, a cross-platform test suite, and a large round of security hardening.

Highlights:

  • Chimera (dual-algorithm) certificates. wolfCLU can now generate Chimera certificates carrying both a conventional and a post-quantum signature on a single X.509 cert, so one certificate satisfies both classical and PQC-aware verifiers. (PR 182, @Yu-Ma28051503)

  • OCSP client and responder. New OCSP client and responder, both with HTTP and SCGI transports. SCGI lets the responder be fronted by nginx in production. (PR 200, @julek-wolfssl)

  • Cross-platform Python tests. The shell-based test suite was ported to Python (unittest), so it now runs on Windows in addition to Linux and macOS. (PR 215, @julek-wolfssl)

  • Explicit key files for enc. The enc command now accepts an explicit key file instead of deriving the key from a password. (PR 224, @embhorn)

Security Hardening:
A large set of fixes from static analysis using wolfSSL internal Fenrir project: out-of-bounds writes in argv processing, a stack buffer overflow in encryption setup, a shell command injection, a use-after-free, a potential double-free, a heap buffer over-read, plus numerous null-pointer and sanity-check fixes across command and init paths. (PRs 202–223; @miyazakh, @aidangarske, @JacobBarthelmeh, @yosuke-wolfssl, and others)

Other Changes:
ML-DSA sign/verify now passes a context for OpenSSL interop (PR 195), the post-quantum groups list was updated to match the latest wolfSSL (PR 209), and there were assorted fixes to the enc, pkey, req, and ECC sign/verify paths along with expanded test coverage and README updates. See the full commit log for details.

Download wolfCLU now and contact facts@wolfssl.com for any questions.

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

Go to forum: Announcements

16 Topic by shizuka

(0 replies, posted in Announcements)

wolfSSL is excited to announce the first official release of wolfPSA 5.9.1, a wolfCrypt-backed implementation of the Arm PSA interfaces for embedded and connected systems.

What is PSA?
PSA, or Platform Security Architecture, defines standard interfaces for security services used in embedded systems. In practice, PSA gives applications, RTOSes, secure firmware, and test frameworks a common way to request cryptography and attestation services without tying the application to one specific secure-world implementation.

wolfPSA provides this compatibility layer on top of wolfCrypt. It acts as a PSA Crypto engine interface for operations such as random generation, key management, hashing, MAC, cipher, AEAD, signatures, key agreement, and key derivation. It also exposes the PSA Initial Attestation interface expected by PSA-based systems, helping projects build against a standard API surface while relying on wolfSSL components underneath.

What is included in wolfPSA 5.9.1?
wolfPSA 5.9.1 is the initial public wolfPSA release and follows the wolfSSL 5.9.1 version numbering. This release includes:

  • PSA Crypto API entry points implemented in C on top of wolfCrypt

  • Static and shared builds: libwolfpsa.a and libwolfpsa.so

  • PSA lifecycle, RNG, key management, persistent key storage, cipher, AEAD, hash, MAC, asymmetric crypto, key derivation, and TLS 1.3 PRF/HKDF support

  • Algorithm coverage including AES, ChaCha20, ChaCha20-Poly1305, SHA-1/SHA-2/SHA-3, HMAC, CMAC, RSA, ECC/ECDSA/ECDH, Curve25519/Curve448, Ed25519/Ed448, and configured compatibility options

  • Integration points for post-quantum and hash-based algorithms when enabled in wolfCrypt, including ML-KEM, ML-DSA, LMS, and XMSS

  • Standalone tests and demos, including PSA API calls, PSA-backed wolfCrypt benchmarking, and TLS examples using PSA-managed keys

First demo use case: wolfBoot secure domain + Zephyr
One of the first application-side integration cases for wolfPSA is the wolfBoot TrustZone-M secure domain work for Zephyr.

In this model, wolfBoot runs in the ARMv8-M secure world and provides the secure boot, firmware update, and secure service boundary. wolfPSA is hosted inside that secure domain, while Zephyr runs in the non-secure world and calls PSA Crypto APIs through the wolfBoot-backed TEE/NSC interface.

This demonstrates wolfPSA as more than a standalone library: it becomes a compatibility layer for PSA-aware applications and RTOS environments, while allowing wolfBoot and wolfCrypt to anchor the cryptographic boundary in the secure domain.

Availability
wolfPSA 5.9.1 is available now. It is designed for teams building PSA-compatible embedded systems, Zephyr TrustZone designs, secure boot chains, and products that want wolfCrypt-backed cryptography behind a standard PSA-facing API.

For questions about wolfPSA, wolfBoot secure-domain integration, licensing, or commercial support, contact us at facts@wolfssl.com or call +1 425 245 8247.

Download wolfSSL Now

Go to forum: Announcements

17 Topic by shizuka

(0 replies, posted in Announcements)

wolfCrypt JNI/JCE 1.10.0 is now available for download! This release brings new JCE Cipher support for RSA OAEP padding schemes and RSA key wrapping (WRAP/UNWRAP modes), a PKIX CertPathBuilder implementation using native wolfSSL X.509 functionality, default FIPS error callback registration, new JNI utilities for hex string conversion and PEM-to-DER, enhanced WolfSSLX509StoreCtx methods, and two new system properties for flexible native library loading and OCSP/CRL timeouts. Along with these additions, 1.10.0 delivers extensive bug fixes, memory-safety improvements, FIPS compliance enhancements, and an expanded testing matrix.

New JCE Functionality:

  • Add Cipher RSA/ECB/OAEPWithSHA-256AndMGF1Padding support

  • Add Cipher RSA/ECB/OAEPWithSHA-1AndMGF1Padding support

  • Add Cipher WRAP_MODE and UNWRAP_MODE support for RSA-based key wrapping

  • Add PKIX CertPathBuilder implementation using native wolfSSL X509_STORE

  • Add jdk.certpath.disabledAlgorithms enforcement to CertPathBuilder and CertPathValidator

  • Register default FIPS error callback in WolfCryptProvider for FIPS error debugging

  • Enrich WolfCryptException with FIPS module status for FIPS_NOT_ALLOWED_E errors

  • Add Java 9+ module support (JPMS) for jlink compatibility

New JNI Functionality:

  • Add hex string conversion via WolfCrypt.toHexString() and WolfCrypt.hexStringToByteArray()

  • Add PEM to DER conversion support for keys and certificates

  • Add setFlags() and setVerificationTime() methods to WolfSSLX509StoreCtx

New Property Support:

  • wolfssl.skipLibraryLoad System property – Skip automatic System.loadLibrary() calls for advanced embedding scenarios

  • wolfjce.ioTimeout System property – Configure OCSP/CRL IO timeouts

Bug Fixes & Reliability Improvements
Beyond the new features, version 1.10.0 includes a substantial set of bug fixes and reliability improvements focused on FIPS error visibility, cryptographic correctness, input validation, and memory safety:

  • Fixed FIPS error callback lifecycle (including proper deregistration in JNI_OnUnload)

  • Corrected Ed25519 signature length handling, RSA public-key flattening/export, unsigned return values, and pointer casts

  • Added HMAC/ByteBuffer/offset-length bounds validation, improved NULL checks, and missing releaseByteArray() calls across ECC, RSA, ChaCha, and AES-GCM

  • Implemented defensive copies of IV arrays, constant-time GMAC tag verification, secure zeroization of keys and buffers, and proper cleanup for AES-CTR/AES-OFB/GMAC

  • Fixed signed integer overflow risks in bounds checks, DH key export paths, ECC private-key import curve handling, and reduced unnecessary WC_RNG allocations

  • Expanded FIPS-compliant SecureRandom sanitization and fixed threaded MessageDigest hangs on FIPS errors

Expanded Testing & CI Infrastructure
CI coverage has been expanded with new workflows and modern platform support:

  • Java 24 and 25 tests added to GitHub Actions workflows

  • Linux 32-bit testing with Java 17 via GitHub workflow

  • UndefinedBehaviorSanitizer (UBSan) GitHub workflow

  • SpotBugs static analysis target and dedicated GitHub Actions workflow

  • Android FIPS Ready automated emulator testing via GitHub workflow

  • Java 9+ module (JPMS) testing workflow

  • Improved JUnit test reliability for FIPS mode and CI environments

New Examples

  • Added CertPathBuilder and CertPathValidator example demonstrating PKIX path building and validation with disabledAlgorithms enforcement

  • Updated Android example project: migrated from jcenter() to mavenCentral() and AndroidX, added Gradle wrapper with distributionSha256Sum, JKS-to-BKS KeyStore conversion script for testing, and CMakeLists.txt exclusion list updates

wolfCrypt JNI/JCE 1.10.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfCrypt JNI/JCE User Manual can be found here. Full details on this release can be seen in the ChangeLog.md on GitHub. For any questions, or to get help using wolfSSL products in your projects, contact us at support@wolfssl.com.

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

Go to forum: Announcements

18 Topic by shizuka

(0 replies, posted in Announcements)

wolfSSL JNI/JSSE 1.17.0 is now available for download! This release brings JSSE?level PSK support, Java Platform Module System (JPMS) compatibility, SSLEngine hardening, a large expansion of X.509 and CRL capabilities at the JNI layer, and two new properties for FIPS and native library loading. Along with the new functionality, 1.17.0 contains a substantial set of bug fixes, compatibility improvements, and stability changes driven by AI-facilitated analysis and test integrations with Spring Boot, Netty, and OkHttp.

New JSSE Functionality

  • Pre-Shared Key (PSK) support – Full JSSE-level PSK via WolfSSLParameters for SSLSocket and SSLEngine (client and server).

  • Java 9+ Module System (JPMS) support – Conditional module-info.java compilation for jlink compatibility.

  • Trust and KeyStore enhancements — CertPathTrustManagerParameters and KeyStoreBuilderParameters now supported in WolfSSLTrustManager.

New JNI Functionality & Certificate APIs

  • Extract SNI directly from a raw ClientHello buffer with WolfSSL.getSNIFromBuffer()

  • RSA-PSS sign/verify and RSA sign-check PK callback support.

  • Basic Constraints pathLen parameter in WolfSSLCertificate / WolfSSLCertRequest.addExtension().

  • Full CRL generation and decode wrappers in WolfSSLCRL.

  • Extended X.509 support:

    • SKID, AKID, CRL Distribution Points, and Netscape Cert Type extensions.

    • Name Constraints via new WolfSSLNameConstraints / WolfSSLGeneralName classes.

    • Extended AIA interface for separate OCSP and CA Issuer URL retrieval.

    • WolfSSLAltName class with full SAN parsing (including otherName for MS AD UPN, iPAddress, and directoryName).

New Configuration Properties

  • wolfjsse.skipFIPSCAST Security property – Skip automatic FIPS CAST execution during wolfJSSE initialization.

  • wolfssl.skipLibraryLoad System property – Skip automatic System.loadLibrary() calls for advanced embedding scenarios.

Bug Fixes & Reliability Improvements
This release includes numerous stability and compatibility fixes, particularly for SSLEngine and SSLSocket:

  • Improved SSLEngine buffer handling (BUFFER_UNDERFLOW/OVERFLOW), close/shutdown state transitions, and handshake status reporting.

  • Better SNI handling, session timeout behavior, and principal return types (X500Principal).

  • Spring Boot and Netty compatibility improvements (SSLHandshakeException on handshake errors, SSLEngine(host, -1) support).

  • Multiple null-pointer, memory-leak, and thread-safety fixes in native callbacks and FIPS error handling.

  • Cipher suite filtering aligned with jdk.tls.disabledAlgorithms and TLS version configuration.

  • Various edge-case fixes for PSK, certificate loading, and high file descriptor handling.

Expanded Testing & CI Infrastructure

  • Static analysis – New SpotBugs build target and GitHub Actions workflow.

  • Android FIPS Ready – Automated Android emulator testing via GitHub workflow.

  • Sanitizers – UndefinedBehaviorSanitizer (UBSan) GitHub workflow.

  • Linux 32-bit testing with Java 17 via GitHub workflow.

  • Expanded test matrix support for Java 24 and 25.

  • Module system and build verification – JPMS (Java Module System) testing workflow.

New Examples & Testing

  • PSK client/server examples for both SSLSocket and SSLEngine.

  • DualProviderFIPSTest demonstrating wolfJSSE + wolfJCE dual-provider FIPS usage.

  • Updated Android example with TLS connection and FIPS error callback support.

wolfSSL JNI/JSSE 1.17.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfSSL JNI/JSSE User Manual can be found here. Full details on this release can be seen in the ChangeLog.md on GitHub. For any questions, or to get help using wolfSSL products in your projects, contact us at support@wolfssl.com.

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

Go to forum: Announcements

19 Topic by shizuka

(0 replies, posted in Announcements)

wolfTPM v4.0.0 is our largest release to date. It delivers three headline capabilities:

  • Firmware TPM (fwTPM) – a portable TPM 2.0 built on wolfCrypt.

  • SPDM Secured Transport – encrypted host-to-TPM communication.

  • ST33 TPM 2.0 Firmware Update – new update tool for STMicro ST33KTPM2X.

All three are powered by the same wolfCrypt engine trusted in FIPS 140-3 and DO-178C DAL A deployments.

Feature 1: Firmware TPM (fwTPM)
The fwTPM is a portable TPM 2.0 command processor. It is implemented entirely on top of wolfCrypt. It covers 105 of 113 commands in the TPM 2.0 v1.38 specification (93%). The full object, session, policy, attestation, PCR, and NV families are included.

Use it as a drop-in replacement for a discrete TPM chip. Or use it in CI as a replacement for external simulators like the Microsoft TPM simulator and IBM swTPM.

Why It Matters

  • Reduce BOM and physical attack surface. Parts that never shipped with a TPM can now gain TPM services. No extra chip. No exposed bus.

  • Portability. The same fwTPM runs on a Cortex-M in TrustZone, a dedicated RPU on an MPSoC, a hardened RISC-V core, or an FPGA soft core.

  • Supply-chain integrity. Your TPM becomes part of your signed firmware image. No separate silicon vendor in the trust path.

  • Same crypto you already trust. RSA, ECC, SHA-2/3, AES, and HMAC all come from the FIPS 140-3 wolfCrypt module, qualifiable to DO-178C DAL A for avionics.

Where fwTPM Runs

fwTPM is designed to live in an isolated execution environment. Proven homes include:

  • Microchip PolarFire SoC (MPFS250T) – Run in FPGA with Mi-V RISC-V soft-core or run in a dedicated core (E51 Monitor or U54)

  • Arm TrustZone-M. Reference port on STMicro STM32H5 (NUCLEO-H563ZI). TrustZone-M gives isolated code, data, flash, and crypto peripherals.

  • AMD/Xilinx Zynq UltraScale+ MPSoC and Versal Gen 1 / Gen 2. Multiple deployment options on the same part: Arm TrustZone on the APU, a dedicated Cortex-R5F (UltraScale+) or R52 (Versal Gen 2) on the RPU, or a MicroBlaze V (RISC-V) soft core.

  • AMD Spartan UltraScale+ (MicroBlaze V or Cortex-M1 soft core)

  • Altera Agilex 5 (Nios V soft core). TPM functionality entirely inside programmable logic.

Integration

  • Transports: Socket mssim or swtpm (auto detected), shared memory IO and register-level TIS for bare-metal SPI, I2C or UART.

  • NV storage: File-backed on hosted systems. HAL callback for embedded flash. TLV journal format suits wear-levelled flash.

  • Footprint knobs: Features can be disabled if not required to reduce code size. Attestation, Policy, NV, Credential, Dictionary Attack.

Feature 2: SPDM Secured Transport
When a TPM speaks to its host over a PCB trace, that trace is attackable. SPDM closes the gap. Commands and responses ride over a vendor-defined TCG channel. The channel is encrypted with AES-256-GCM and integrity-checked on every packet.

What’s New

  • Vendors: Nuvoton NPCT75x and Nations Technologies NS350. (More coming soon)

  • Session modes:

    • Identity-key mode over ECDH P-384, on both NPCT75x and NS350.

    • PSK mode on NS350.

  • Auto-connect with SPDM-only lock-down. Once locked, wolfTPM establishes the encrypted session on every open. Plaintext commands are rejected.

  • New spdm_ctrl utility. Full lifecycle: enable, disable, provision PSK, clear PSK, lock, unlock.

Why It Matters
Anywhere the TPM is physically accessible – servers in colocation, defense platforms, medical devices, industrial controllers, in-vehicle ECUs – SPDM closes the last-inch attack surface.

Feature 3: ST33 TPM 2.0 Firmware Update
STMicro’s ST33KTPM2X introduced a new Generation 2 firmware format using LMS signing. wolfTPM v4.0.0 adds the st33_fw_update example tool for supporting firmware updates on older Gen 1 and newer Gen 2 firmware versions. See examples/firmware/README.md for usage.

Other v4.0.0 Release Improvements

New HALs

  • Raspberry Pi 4 hardware SPI

  • U-Boot (tpm_io_uboot.c)

  • Espressif ESP-IDF SPI

  • Linux auto-detection between /dev/tpmX and direct SPI

Hardening

  • Fenrir and Coverity findings addressed across tpm2_wrap, tpm2_packet, tpm2_asn, NV, session auth, SPDM, and fwTPM paths.

  • ForceZero on every sensitive stack buffer.

  • Constant-time export for ECDH shared secrets and ECC signature r/s.

  • Short-circuit OR removed from all auth paths.

  • Bounds checks and NULL-deref guards across ASN.1, PCR, and key-load code.

CI

  • ASan and UBSan sanitizer jobs.

  • Pedantic gcc and clang matrices.

  • macOS and Windows fwTPM builds.

  • Weekly libFuzzer plus per-PR smoke.

Coming Soon: TPM 2.0 v1.85 Post-Quantum

Right behind this release. Post-quantum algorithms from TPM 2.0 v1.85 are landing in both the fwTPM server and the wolfTPM client library:

  • ML-KEM (Kyber) for key encapsulation

  • ML-DSA (Dilithium) for signatures

Why now? Harvest-Now-Decrypt-Later (HNDL) mitigation for long-lived device identity keys. Deploy fwTPM today. Get a drop-in PQC upgrade path without respinning silicon.

Getting Started

git clone https://github.com/wolfSSL/wolfTPM.git
cd wolfTPM
git checkout v4.0.0
./configure --enable-fwtpm
make && make check

For commercial licensing, FIPS 140-3 integration, DO-178C DAL A qualification kits, custom HAL ports, or early access to the v1.85 PQC branch, contact facts@wolfssl.com or +1 425 245 8247.

Download wolfSSL Now

Go to forum: Announcements

20 Topic by shizuka

(0 replies, posted in Announcements)

We are pleased to announce the release of wolfBoot 2.8.0, a major update that expands platform support, strengthens PSA and TrustZone integration, and delivers another round of meaningful hardening across the secure boot and firmware update flow.

This release stands out for the breadth of hardware now supported. wolfBoot 2.8.0 adds or extends support for AMD/Xilinx Versal Gen 1 VMK180, Microchip PolarFire SoC MPFS250, NXP MCXN, MCXW71, S32K14x, LPC55S69, NXP T1040 RDB, refreshed T2080 configurations, and Nordic nRF54L15. For product teams working across multiple silicon families, wolfBoot continues to prove itself as a highly portable and consistent secure boot solution.

Version 2.8.0 also brings an important step forward for PSA-based designs. New support for wolfPSA secure storage, TrustZone-backed PSA services, PSA crypto, PSA attestation, and DICE-based attestation flows makes wolfBoot an even stronger foundation for modern embedded security architectures. With new Zephyr integration replacing the TEE layer through PSA-facing interfaces, this release opens up new options for developers building secure RTOS-based systems.

wolfBoot is now also available as complete secure boot + TEE (PSA) replacement for TrustZone systems running Zephyr OS.

On the product integration side, wolfBoot 2.8.0 adds a new generic hook framework for pre-init, post-init, and boot customization, along with custom encryption-key hooks, PKCS11-backed encrypted partitions, improved status and image-inspection tooling, monolithic self-update builds, and reproducible-build support. These improvements make it easier to adapt wolfBoot to real deployment requirements while keeping the codebase compact and focused.

Existing targets also benefit from substantial work in this release. Highlights include improved STM32H5 TrustZone and PKCS11 integration, external flash dual-bank updates on PSoC6, expanded AURIX TC3xx self-update and wolfHSM configurations, refreshed Renesas RA6M4 and RX projects, and better clang/LLVM support with dedicated CI coverage.

As always, security and reliability remain central. wolfBoot 2.8.0 strengthens image parsing, signing, and update flows with tighter checks and safer handling across signatures, TLVs, delta images, partition layouts, and storage I/O. It also expands constant-time operations and zeroization in sensitive paths, adds stricter rollback and flash-protection behavior, and fixes a range of regressions across supported architectures and simulator targets.

Updated modules

  • wolfSSL: latest stable

  • wolfTPM: latest

  • wolfPKCS11: latest stable

  • wolfHSM: latest

With 2.8.0, wolfBoot continues to grow as a practical, production-ready secure bootloader for embedded systems that need strong authentication, reliable updates, and portability across a rapidly expanding hardware landscape.

To learn more about wolfBoot, or to discuss secure boot and firmware update strategies for your platform, contact us.

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

Go to forum: Announcements

21 Topic by shizuka

(0 replies, posted in Announcements)

wolfSSH v1.5.0 is now available! This release brings additional post-quantum hybrid key exchange algorithms, a broad hardening pass across the code base, and a large number of bug fixes. There is also one low-severity vulnerability fix in this release affecting wolfSSHd on Windows when handling an edge case in terminal resize messages received from an authenticated connection.

Please see the ChangeLog.md for full details.

New Features
The headline addition in v1.5.0 is post-quantum key exchange via ML-KEM hybrid algorithms — mlkem1024nistp384-sha384 and mlkem768x25519-sha256 — based on draft-ietf-sshm-mlkem-hybrid-kex, with interoperability testing against OpenSSH running in CI. This brings wolfSSH in line with the industry direction toward quantum-resistant SSH.

On the algorithm side, client-side rsa-sha2-512 signature support has been added. The key type is now separated from the signature type, so ssh-rsa keys can be used with ssh-rsa, rsa-sha2-256, or rsa-sha2-512 signatures, improving compatibility with modern SSH servers that have deprecated the older scheme.

Two handy SFTP client usability improvements also landed: lcd and lls commands for managing the local working directory without leaving an SFTP session.

Improvements
Several handlers that previously lacked proper callback validation have been tightened: host key acceptance, channel open requests, TCP/IP forwarding, and DH group exchange parameters are all now gated and validated. Additional defensive constant-time comparisons were also applied.

Beyond hardening, SFTP reliability saw meaningful attention – better non-blocking behavior, improved error path handling, and more robust multi-byte password support. CI coverage was expanded significantly with new sanitizer builds, multi-compiler testing, and automated Coverity scanning.

Fixes
This release contains a large number of bug fixes driven by static analysis and code review. Highlights include a non-blocking SFTP server hang on WS_WANT_WRITE, Windows authentication issues, missing hash cleanup in RSA/ECC paths, and a variety of null-dereference, bounds-check, and memory-leak fixes throughout the codebase.

Download wolfSSH v1.5.0 from our download page, or clone it from GitHub.

If you have questions about wolfSSH or any of our other products, feel free to reach out at facts@wolfssl.com or support@wolfssl.com, or give us a call at +1 425 245 8247.

Download wolfSSL Now

Go to forum: Announcements

22 Topic by shizuka

(0 replies, posted in Announcements)

wolfSSL 5.9.1 is available with new features, post-quantum cryptography improvements, broad bug fixes, and a number of vulnerability fixes. Users are always recommended to stay up to date with wolfSSL releases. In this release, use cases that are affected by high severity reports are: PKCS7 with ORI callback set or AuthEnvelopedData with AES-GCM (–enable-pkcs7), ECDSA certificate verification with EdDSA or ML-DSA enabled, URI nameConstraints enforcement with intermediate CAs, X.509 certificate conversion via CertFromX509 with AuthorityKeyIdentifier, DTLS 1.3 (–enable-dtls13), ECH (–enable-ech), ECCSI signature verification (–enable-eccsi), AES-EAX/CMAC with large messages, and ChaCha20-Poly1305 via EVP or X509_verify_cert via the OpenSSL compatibility layer (–enable-opensslextra).

Security Vulnerabilities Addressed
This release addresses 22 CVEs across critical, high, medium, and low severity levels. Notably, we have received many quality AI-assisted vulnerability reports this cycle. Thanks to all the researchers who responsibly disclosed issues, including teams from Anthropic, KENTECH, Calif.io, eWalker Consulting, and several independent contributors.

For the full list of vulnerabilities addressed, visit the wolfSSL Vulnerability Page.

Default Build Changes

  • ML-KEM (FIPS 203) enabled by default — Post-quantum key encapsulation is now on by default, making it easier than ever to adopt quantum-resistant cryptography.

  • ECC curve validation is now enabled unconditionally in default builds, removing the previous dependency on USE_ECC_B_PARAM.

New Features

  • Brainpool curve support added to wolfSSL_CTX_set1_sigalgs_list for broader European cryptographic standard compatibility.

  • DTLS 1.3 / TLS 1.3 write-dup support — Duplicate SSL functionality allows read-side delegation of post-handshake tasks (KeyUpdate, ACK, post-handshake auth) to the write-side.

Post-Quantum Cryptography Updates

  • The context-aware FIPS 204 ML-DSA (Dilithium) API is now the default, with the legacy non-context API gated behind WOLFSSL_DILITHIUM_NO_CTX.

  • Sensitive memory buffers in the ML-DSA implementation are now zeroized to prevent leakage of cryptographic material.

  • Private key validation checks added for Ed25519, Ed448, ML-DSA, and ML-KEM operations.

  • Buffer size and callback validation added to wc_LmsKey_Sign.

  • Fixed out-of-bounds shift and undefined behavior issues in ML-DSA and SLH-DSA implementations.

TLS and DTLS Improvements

  • Fixed DTLS 1.3 ServerHello to comply with the specification by not echoing legacy_session_id.

  • Fixed TLS 1.3 server to correctly reject mismatched ciphersuites in second ClientHello after HelloRetryRequest.

  • Resolved multiple correctness issues in DTLS 1.3 and TLS 1.3 including missing bounds checks, PSK identity buffer overreads, and resource leaks.

  • HPKE implementation fixes and refactoring with tests for all 24 algorithm combination variants.

Hardware and Embedded Ports

  • SE050 hardware security module integration fixes for RSA-PSS and persistent key slot management.

  • Broad correctness improvements across Espressif, Renesas, Silicon Labs, NXP, STM32, TI, Xilinx, and other hardware targets.

  • Fixed buffer overflows, key material exposure, mutex leaks, and logic errors across hardware crypto backends.

Rust Wrapper

  • Released version 1.2.0 of the wolfssl-wolfcrypt Rust crate.

  • Updated build script to support cross-compiling and bare-metal targets including RISC-V architectures.

Get the Update
We recommend all wolfSSL users update to version 5.9.1. Dive into the full ChangeLog for a complete list of changes.

Download wolfSSL 5.9.1

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Go to forum: Announcements

23 Topic by shizuka

(0 replies, posted in Announcements)

We are excited to announce the release of wolfIP 1.0.0, the first public release of wolfSSL’s lightweight TCP/IP stack for embedded, real-time, and safety-critical systems. wolfIP is built around a simple idea: networking behavior should be defined before runtime, not discovered during it. With no dynamic memory allocation, fixed socket tables, pre-allocated packet buffers, and a deterministic execution model, wolfIP gives developers a compact and analyzable network stack for systems where predictability matters. Version 1.0.0 is listed on the official wolfIP product page and changelog dated March 31, 2026.

Why wolfIP
Traditional TCP/IP stacks often bring in dynamic allocation, background processing, and broader feature sets than many embedded endpoints actually need. That flexibility can be useful in general-purpose systems, but it also makes worst-case timing, memory usage, and verification harder to bound. wolfIP takes a different approach. It is designed as a tiny, deterministic stack with compile-time configured resources, a fixed socket count, static RX/TX packet buffers, and no hidden runtime allocation. That makes it a strong fit for constrained devices, controlled deployments, and projects with demanding review, testing, or certification workflows.

What is included in 1.0.0
The 1.0.0 release delivers a solid IPv4 networking foundation for embedded endpoints. Core support includes Ethernet II, ARP, IPv4, ICMP, UDP, TCP, DHCP client, and DNS client, along with modern TCP capabilities such as MSS, timestamps, PAWS, window scaling, retransmission timeout handling, SACK, slow start, congestion avoidance, and fast retransmit. wolfIP 1.0.0 also includes HTTP/HTTPS server support, IPsec ESP transport mode, IP filtering with wolfSentry integration, native wolfGuard support, and optional IPv4 forwarding for multi-interface builds.

That combination is important because it gives developers more than just a packet pipe. wolfIP 1.0 starts with the network services many connected devices actually need, then adds security-focused integration points across the wolfSSL ecosystem. Developers can combine wolfIP with wolfSSL for TLS 1.3-protected applications, wolfSentry for filtering and policy enforcement, and wolfGuard where a tightly integrated secure tunnel model is needed. For teams building secure connected products, that means a more cohesive networking and security story from a single vendor and codebase family.

Small footprint, practical deployment model
wolfIP is positioned as a small embedded-first stack, and the official product material describes the core as roughly 4× smaller than lwIP’s core. Just as important, wolfIP’s architecture is intentionally narrow and easier to analyze: deterministic memory usage by default, fixed compile-time resources, and an endpoint-focused design rather than a broad general-purpose routing stack. For organizations thinking about code review effort, qualification scope, or long-term maintenance, reducing moving parts matters.

From POSIX testing to embedded targets
One of the most useful aspects of wolfIP 1.0 is its portability across development and deployment environments. The release includes integration layers for wolfSSL, wolfSSH, wolfMQTT, a POSIX LD_PRELOAD socket interception path via libwolfip.so, and a FreeRTOS BSD socket wrapper. The repo also documents host-side testing through TAP-style interfaces and lists host link driver support for Linux TAP/TUN, Darwin utun, FreeBSD TAP, and VDE2, alongside embedded ports for targets including STM32H753ZI, STM32H563, STM32N6, VA416xx, and Raspberry Pi Pico USB networking demos. That is a practical release story: developers can exercise the stack on desktop-class environments, then carry the same architecture into embedded deployment.

Built to Work Naturally with wolfSSL
wolfIP is especially compelling when paired with the rest of the wolfSSL portfolio. The product page highlights seamless TLS 1.3 integration with wolfSSL, and the repository documents HTTPS server support with wolfSSL TLS backing. For engineering teams that already trust wolfSSL in embedded and RTOS environments, wolfIP extends that same design philosophy down into the transport layer: compact code, explicit resource control, and predictable behavior. Instead of stitching together unrelated networking and crypto components, developers can build on a tightly aligned stack designed for constrained and security-conscious systems.

Available Now
wolfIP 1.0.0 is available now under the GPLv3 open source license. If you are building connected embedded devices and need a TCP/IP stack with bounded memory usage, deterministic behavior, and straightforward integration with wolfSSL security products, wolfIP is well worth a look. Download the latest release, review the changelog, and contact us to discuss commercial licensing, support, or how wolfIP fits into your next embedded networking design.

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

Go to forum: Announcements

24 Topic by shizuka

(0 replies, posted in Announcements)

We are excited to announce the release of wolfMQTT v2.0.0, a major milestone that introduces a brand-new lightweight MQTT broker as its headline feature. This release represents a significant evolution of the wolfMQTT library, expanding it from a client-only library into a complete MQTT solution for embedded systems, IoT gateways, and edge computing applications.

Lightweight MQTT Broker
The centerpiece of wolfMQTT v2.0.0 is a fully featured, production-ready MQTT broker built right into the library. Designed with the same embedded-first philosophy that drives all wolfSSL products, the broker delivers a rich feature set while maintaining a small footprint suitable for resource-constrained environments.

Broker Highlights

  • Full MQTT v3.1.1 and v5 Protocol Support — The broker handles both protocol versions, ensuring compatibility with a wide range of MQTT clients and devices.

  • Retained Messages — The broker stores retained messages and automatically delivers them to new subscribers matching the topic filter. Message expiry intervals (MQTT v5) are supported, and retained messages can be cleared by publishing an empty payload with the retain flag set.

  • Session Persistence — When clients connect with clean_session=0, subscriptions are preserved across disconnections. Reconnecting clients with the same client ID will have their previous subscriptions restored automatically.

  • QoS 0, 1, and 2 — Full quality-of-service support with proper packet ID management, effective QoS calculation (minimum of publish QoS and subscription QoS), and complete PUBREC/PUBREL/PUBCOMP handling for QoS 2 flows.

  • Last Will and Testament (LWT) — Clients can register will messages that are published automatically upon unexpected disconnection. The broker supports will delay intervals (MQTT v5) and will retain flags.

  • Wildcard Topic Matching — Full support for MQTT single-level (+) and multi-level (#) wildcard subscriptions, with proper handling of $-prefixed system topics per the MQTT specification.

  • Authentication — Username/password authentication with constant-time string comparison to prevent timing attacks. Credentials are securely wiped from memory using wc_ForceZero().

TLS and Dual-Port Listening
The broker supports simultaneous plain-text and TLS-encrypted listeners on separate ports (default 1883 and 8883). TLS configuration includes support for TLS 1.2 and 1.3, server certificates, and mutual TLS authentication with client certificate verification. A TLS-only mode is also available for environments that require encrypted connections exclusively.

WebSocket Transport
wolfMQTT v2.0.0 adds WebSocket transport support to the broker, enabling browser-based and web clients to connect using MQTT over WebSockets. This opens up new use cases for real-time dashboards, web-based device management, and hybrid IoT architectures.

wolfIP Integration
For deeply embedded systems, the broker integrates with wolfIP, wolfSSL’s lightweight embedded TCP/IP stack. This combination allows wolfMQTT to run on bare-metal systems without a full operating system or third-party networking stack. The broker provides a cooperative MqttBroker_Step() API for single-iteration execution, making it ideal for super-loop and RTOS-based embedded architectures.

Designed for Embedded Systems
The broker was built with embedded constraints in mind:

  • Static Memory Mode — Pre-allocated arrays eliminate the need for dynamic memory allocation, with configurable limits for clients, subscriptions, retained messages, and buffer sizes.

  • Dynamic Allocation Mode — For systems with more resources, dynamic allocation provides flexible sizing.

  • Pluggable Network Backend — A callback-based network abstraction supports POSIX sockets, wolfIP, and custom implementations.

  • Two Execution Models — Choose between a blocking MqttBroker_Run() main loop or a non-blocking MqttBroker_Step() for cooperative multitasking.

Easy to Configure
The broker includes a command-line interface for quick setup:

-p       Plain port (default: 1883)
-s       TLS port (default: 8883)
-t             Enable TLS support
-V        TLS version (12 or 13)
-c       Server certificate (PEM)
-K       Server private key (PEM)
-A       CA certificate for mutual TLS
-u       Username for authentication
-P       Password for authentication
-w       WebSocket listen port
-v      Log level: 1=error, 2=info, 3=debug

Build-time configuration is equally flexible, with granular feature toggles:

--enable-broker                    # Enable broker
--disable-broker-retained          # Disable retained messages
--disable-broker-will              # Disable LWT support
--disable-broker-wildcards         # Disable wildcard subscriptions
--disable-broker-auth              # Disable authentication
--disable-broker-insecure          # Disable plain-text listener

Security Hardening
This release includes significant security improvements across the entire library:

  • Added overflow checks in network and socket IO

  • Added validation checks for negative return values in decode functions

  • Added encoding error checks throughout the packet processing pipeline

  • Added remaining length validation

  • Static analysis fixes across MQTT and MQTT-SN code paths

  • Added a debug warning when using VERIFY_NONE for TLS

  • Race condition fix in wm_SemLock

  • Fuzzing Infrastructure

wolfMQTT v2.0.0 introduces a libFuzzer-based fuzzing infrastructure for the broker, enabling automated discovery of edge cases and potential security issues. This infrastructure was used during development to identify and fix multiple issues before release.

Additional Improvements

  • wolfIP Client Support — In addition to the broker, wolfIP support has been added for the MQTT client, enabling client connections on bare-metal embedded systems.

  • lastError Field — A new lastError field in the network context preserves TLS error codes for improved diagnostics.

  • Bug Fixes — Numerous fixes for MQTT-SN encode/decode, wildcard matching, LWT handling, curl transport, and more.

  • CI Enhancements — New CI workflows for codespell, multi-compiler testing, and sanitizer tests, plus expanded broker edge case testing.

About wolfMQTT
The wolfMQTT library is a client and broker implementation of the MQTT protocol, written in C and optimized for embedded and RTOS environments. It supports MQTT v3.1.1 and v5, MQTT Sensor Network (MQTT-SN), TLS encryption via wolfSSL, QoS levels 0–2, and a wide range of platforms including FreeRTOS, ThreadX/NetX, Zephyr, ChibiOS, MQX/RTCS, Harmony, and more.\

Download
wolfMQTT v2.0.0 is available now:
GitHub — Show us some love and give the wolfMQTT project a Star!
wolfSSL Downloads

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

Go to forum: Announcements

25 Topic by shizuka

(0 replies, posted in Announcements)

We are excited to announce that wolfSSL version 5.9.0 is now available! wolfSSL 5.9.0 brings a strong focus on advancing post-quantum cryptography support, an expanded Rust wrapper, new hardware platform integrations, and a number of security vulnerability fixes.

Security Fixes
wolfSSL 5.9.0 includes fixes for 15 security vulnerabilities spanning a range of severity levels, covering areas including CRL parsing, TLS 1.3 ECH extension handling, ALPN parsing, PKCS7 encoding, the packet sniffer, and side channel hardening of post-quantum implementations on ARM Cortex-M. We would like to thank all external researchers who responsibly disclosed issues to us. For full details on each vulnerability please visit the wolfSSL Security Vulnerabilities page.

Post-Quantum Cryptography: SLH-DSA and More
Post-quantum cryptography continues to be a major area of focus in the security industry. In this release there is an addition of SLH-DSA (FIPS 205) — the Stateless Hash-Based Digital Signature Standard — rounding out wolfSSL’s coverage of all three NIST post-quantum digital signature standards alongside ML-DSA and FALCON.

SLH-DSA is a stateless, hash-based signature scheme that provides strong security guarantees without relying on the hardness of lattice problems. It offers an alternative signature foundation for deployments that want to diversify their post-quantum strategy beyond lattice-based approaches. With this addition wolfSSL now supports the full NIST PQC signature portfolio: ML-DSA (FIPS 204), FALCON, and SLH-DSA (FIPS 205), as well as the stateful hash-based schemes LMS/HSS and XMSS/XMSS^MT for specialized use cases.

Beyond SLH-DSA, this release also brings a range of improvements across the existing PQC stack:

  • ML-DSA improvements — Several bug fixes including a fix for ML-DSA verification when using WOLFSSL_DILITHIUM_SMALL, improved no-malloc build support, and PKCS#11 integration for ML-DSA key operations.

  • ML-KEM improvements — Bug fixes and hardening across no-malloc builds, static memory handling, DTLS 1.3 cookie and ClientHello fragment handling, and expanded hybrid/individual ML-KEM level test coverage.

  • Fault injection hardening for PQC on Cortex-M — New protection for ML-KEM and ML-DSA implementations on ARM Cortex-M, specifically guarding against fault injection attacks targeting Keccak-based seed expansion.

  • General WOLFSSL_NO_MALLOC PQC support — Broader no-malloc improvements make PQC algorithms more accessible in deeply embedded environments.

  • SLH-DSA and FALCON key-type detection fixes — Corrected the key variant identification logic in both the SLH-DSA (SPHINCS+) and FALCON signature algorithm implementations.

New Features

  • OCSP Responder API — wolfSSL can now act as an OCSP responder. A new API and supporting infrastructure have been added to serve certificate status responses, enabling wolfSSL to be used in PKI infrastructure roles beyond the TLS client and server. (PR 9761)

  • AES CryptoCB Key Import — Added AES key import support via the crypto callback interface, making it easier to use externally managed AES keys through wolfSSL’s callback framework. (PR 9658)

  • RNG Bank Facility — New wc_rng_new_bankref() API allows multiple wolfCrypt contexts to share a seeded RNG pool, reducing the overhead of repeated seeding at runtime — particularly useful in resource-constrained embedded systems. (PR 9616)

Rust Wrapper Expansion
The wolfSSL Rust wrapper received significant expansion in this release, gaining FIPS support and coverage for a large number of new cryptographic primitives. New modules were added for Dilithium/ML-DSA, ChaCha20-Poly1305, Curve25519, BLAKE2, LMS, and ML-KEM. Improvements were also made for RSA, ECC, HASH-DRBG, HMAC-BLAKE2, and XChaCha20-Poly1305, along with support for optional heap and device ID parameters and conditional compilation based on underlying C build options.

TLS/DTLS Improvements
TLS 1.3 now supports Brainpool curves for key exchange (PR 9701). DTLS retransmission handling has been improved and TLS message order checking has been hardened on both client and server sides. The MAC and hash comparisons in the TLS 1.3 and TLS 1.2 Finished messages were also strengthened. Additional improvements include an extended AIA (Authority Information Access) interface, better ECH (Encrypted Client Hello) handling, and a range of smaller robustness fixes across fragmentation, session ticket lifetime validation, and QUIC transport parameter handling.

Kernel Module Updates
The Linux kernel module received various fixes and enhancements for Tegra kernels, including support for offline FIPS hash calculation. The FreeBSD kernel module gained both FIPS support and x86 hardware crypto acceleration in this release, broadening wolfCrypt’s kernel-mode footprint across operating environments.

Ports and Hardware Integration
New platform support in 5.9.0 includes the Renesas SK-S7G2 board, STM32 HMAC hardware acceleration, and STM32G0 hardware crypto. Various Thumb2 AES and SP assembly optimizations were added or fixed, and Zephyr 4.1+ compatibility was added for the wolfssl_tls_sock sample application.

PKCS Improvements
This release adds PKCS7 ECC raw sign callback support, RSA-PSS support for SignedData, and RSA-PSS certificate support for PKCS7 EnvelopedData KTRI. Several PKCS7 parsing fixes were also included, along with expanded ML-DSA support via PKCS#11.

Testing and CI Improvements
Test coverage was expanded with a particular focus on PQC and CMake builds. The CI test matrix grew to include rng-tools 6.17, openldap 2.6.9, and bind 9.20.11. A new TLS Anvil interoperability test workflow was added, and a stateful port-tracking mechanism was implemented to eliminate test port collisions during high-concurrency CI runs.

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 any questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

Go to forum: Announcements