In a server response, the data is transmitted in separate chunks. When processing these data chunks, the size of the next chunk appears interspersed with the data itself. Is this expected behavior? Is there a setting to hide this within the data stream? The application is developed in the Arduino IDE for STM32 using a W5500 Ethernet interface and utilizes wolfSSL 5.8.4.

              <Point>
                <position>45</position>
                  <price.amount>145.69</price.amount>
              </Point>
              <Point>
                <position>46</position>
         <price.amount>146.02</price.a
1b70
mount>
              </Point>
              <Point>
                <position>47</position>
                  <price.amount>142.13</price.amount>
              </Point>

The 0x1b70 is the size of the next chunk.

The data is read into 256-byte buffers. This part works correctly, but the chunk size appearing in the middle of the stream makes interpretation difficult.

And I want to integrate WoolfMQTT without WolfSSL as the tianocore codebase already have existing SSL.

So I would appreciate help:
(1) Step by step to integrate WolfMQTT into UEFI BIOS EDK2 codebase
(2) To build without WolfSSL integration
(3) Since, I skip WolfSSL integration, how to supply with custom SSL into WolfMQTT library?

Thank you!

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

• 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

• Release notes: github.com/wolfSSL/wolfTPM/releases/tag/v4.1.0

• Changelog: ChangeLog.md

• 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

I compiled the latest versions of wolfssl and wolfCLU, on two systems - my laptop running archlinux and a raspberry pi running raspbian (a debian-based distro), and ran ldconfig on both of them.

On my pi the wolfssl library runs as expected. I run the example server code given here https://www.wolfssl.com/docs/quickstart/ and compile it using

gcc server.c -lwolfssl -o server

and run server. It gives me

 listening on port 11111

as expected.

But if I run it on my archlinux laptop, I get,

./server: error while loading shared libraries: libwolfssl.so.45: cannot open shared object file: No such file or directory

I guess this is happening because the compiled program looks for libraries in /usr/lib but libwolfssl.so.45 gets installed in /usr/local/lib. So one easy fix is to create a symbolic link in /usr/lib that points to /usr/local/lib/libwolfssl.so.45. Another fix would be to provide the correct install prefix /usr/lib while building wolfssl (I haven't tried this though).

My question is not about how to fix this or how to get `server` to run, but rather why is this happening. I am trying to understand the compilation process for programs that use wolfssl. What is different on my laptop from my pi that is making this happen? The libwolfssl.so.45 is in /usr/local/lib in both cases.

Here is the output of gcc -v on both my machines, if that helps:

On laptop:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/16/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues --with-build-config=bootstrap-lto --with-gcc-major-version-only --with-linker-hash-style=gnu --with-system-zlib --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-fixincludes --disable-libssp --disable-libstdcxx-pch --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.1.1 20260625 (GCC) 

and on pi:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/12/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14+deb12u1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14+deb12u1)

The environment variable $LD_LIBRARY_PATH is not set in both cases.

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

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

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).

• wolfCrypt SHE (Secure Hardware Extension) support for the SHE key management standard.

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.

• RSA-PSS decoding was hardened to better conform to RFC 8017 A.2.3 guidance on trailer bits.

Crypto Callbacks

• Added WOLF_CRYPTO_CB_SETKEY and WOLF_CRYPTO_CB_EXPORT_KEY generic crypto callback utilities.

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

• Added WOLF_CRYPTO_CB_ONLY_SHA512 support.

• Added CryptoCb support for SLH-DSA.

• Added crypto callback support for LMS and XMSS (crucial to their stateful management!).

• Added support for zeroizing AES session keys in TLS 1.3 with WOLF_CRYPTO_CB_AES_SETKEY.

Post Quantum Cryptography

• Added SHA-512 DRBG and FIPS module-boundary wrappers for ML-KEM, ML-DSA, LMS, XMSS, and SLH-DSA as part of the upcoming post-quantum FIPS submission.

• Added support for RFC 9802 LMSS / XMSS in X.509 certificate and CSR generation.

• Added ML-KEM support for PKCS11.

Hardware and Embedded Ports

• Added NXP LPC55S69 hardware crypto support.

• Added STM32U3 hardware crypto support.

• Added Zephyr 4.3 default TLS-socket support.

Rust Wrapper

• Added Rust crate trait implementations for: rand_core, aead, and cipher, digest and signature, and password-hash, kem, and mac.

• Added scrypt KDF and RSA-OAEPsupport.

Pruning / Cleanup

• The liboqs integrations for ML-KEM and ML-DSA were removed.

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

• The external liblms / libxmss integrations were removed (we’ve had our own more performant implementations for a while).

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

I'm testing wolfMQTT on an embedded device that uses a cellular connection. When the network drops briefly and the client reconnects, I occasionally receive duplicate MQTT messages that were originally published with QoS 1.

My application stores packet IDs and acknowledges messages correctly, but duplicates still appear after reconnection in some cases.

Does wolfMQTT provide any built-in mechanism or recommended approach for tracking and filtering duplicate QoS 1 messages across reconnect events, especially when using persistent sessions (clean session disabled)?

If anyone has implemented this successfully on resource-constrained devices, I'd appreciate hearing about your experience.

Thanks!

I can see this is something to do with wolfSSL_SetIOWriteCTX(), but I'm not entirely sure what value to use - I'm a novice with wolfSSL.

Are there specific values I should set to link the two components together?

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

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

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

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