RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

wolfSSL 5.8.2 Now Available

wolfSSL 5.8.2 is now available! We are excited to announce the release of wolfSSL 5.8.2, packed with significant enhancements, introducing new functionalities, and refining existing features!

Important Notes for this Release

  • GPLv3 Licensing: wolfSSL has transitioned from GPLv2 to GPLv3.
  • Deprecated Feature: `–enable-heapmath` is now deprecated.
  • MD5 Disabled by Default: For enhanced security, MD5 is now disabled by default.

Key Highlights of wolfSSL 5.8.2

Vulnerability Mitigations:

  • ECC and Ed25519 Fault Injection Mitigation (Low): (Thanks to Kevin from Fraunhofer AISEC)
  • Apple Native Cert Validation Override (High – CVE-2025-7395): (Thanks to Thomas Leong from ExpressVPN)
  • Predictable `RAND_bytes()` after `fork()` (Medium – CVE-2025-7394): (Thanks to Per Allansson from Appgate)
  • Curve25519 Blinding Enabled by Default (Low – CVE-2025-7396): (Thanks to Arnaud Varillon, Laurent Sauvage, and Allan Delautre from Telecom Paris)

New Features:

  • Sniffer Enhancements: Support for multiple sessions and a new `ssl_RemoveSession()` API for cleanup.
  • New ASN.1 X509 API: `wc_GetSubjectPubKeyInfoDerFromCert` for retrieving public key information.
  • PKCS#12 Improvements: `wc_PKCS12_create()` now supports PBE_AES(256|128)_CBC key and certificate encryptions.
  • PKCS#7 Decoding: Added `wc_PKCS7_DecodeEncryptedKeyPackage()` for decoding encrypted key packages.
  • Linux Kernel Module Expansion: All AES, SHA, and HMAC functionality now implemented within the Linux Kernel Module.
  • OpenSSL Compatibility Layer Additions: New APIs for X.509 extensions and RSA PSS: `i2d_PrivateKey_bio`, `BN_ucmp`, and `X509v3_get_ext_by_NID`.
  • Platform Support: Added support for STM32N6.
  • Assembly Optimizations: Implemented SHA-256 for PPC 32 assembly.

Improvements & Optimizations:

This release includes a wide range of improvements across various categories, including:

  • Extensive Linux Kernel Module (LinuxKM) Enhancements: Numerous minor fixes, registrations, and optimizations for cryptography operations within the Linux Kernel Module.
  • Post-Quantum Cryptography (PQC) & Asymmetric Algorithms: Updates to Kyber, backward compatibility for ML_KEM IDs, fixes for LMS building and parameters, and OpenSSL format support for ML-DSA/Dilithium.
  • Build System & Portability: General build configuration fixes, improvements for older GCC versions, new CMakePresets, and default MD5 disabling.
  • Testing & Debugging: Enhanced debugging output, additional unit tests for increased code coverage, and improved benchmark help options.
  • Certificates & ASN.1: Improved handling of X509 extensions, fixed printing of empty names, and better error handling.
  • TLS/DTLS & Handshake: Corrected group handling, improved DTLS record processing, and refined TLS 1.3 key derivation.
  • Memory Management & Optimizations: Stack refactors, improved stack size with MLKEM and Dilithium, and heap math improvements.
  • Cryptography & Hash Functions: Added options to disable assembly optimizations for SipHash and SHA3, and improved Aarch64 XFENCE.
  • Platform-Specific & Hardware Integration: Explicit support for ESP32P4, public `wc_tsip_*` APIs, and enhanced PlatformIO certificate bundle support.
  • General Improvements & Refactoring: Updated libspdm, fixed PEM key formatting, and improved API accessibility for certificate failure callbacks.

wolfSSL 5.8.2 also includes some nice bug fixes, addressing issues across various modules, ensuring greater stability and reliability. For a complete and detailed list of all changes, please refer to the full release notes.

We encourage all users to upgrade to wolfSSL 5.8.2 to take advantage of these important security updates, new features, and performance enhancements. Download the latest release.

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

Download wolfSSL Now

Keystores and Secure Elements supported by wolfSSL

When looking to store your cryptographic secrets, it is important to have a good platform to store them on. Even more important is the ease of accessing and using those secrets.

With wolfTPM, we have support for all TPM 2.0 APIs. Additionally we provide the following wrappers:

  • Key Generation/Loading
  • RSA encrypt/decrypt
  • ECC sign/verify
  • ECDH
  • NV storage
  • Hashing/HMAC
  • AES
  • Sealing/Unsealing
  • Attestation
  • PCR Extend/Quote
  • Secure Root of Trust

Supported Platforms

In wolfTPM we already added support for the following platforms:

  • Raspberry Pi (Linux)
  • MMIO (Memory mapped IO)
  • MMIO (Memory mapped IO)
  • Atmel ASF
  • Xilinx (Ultrascale+ / Microblaze)
  • QNX
  • Infineon TriCore (TC2xx/TC3xx)
  • Barebox
  • Zephyr Project RTOS
  • U-Boot Bootloader
  • Microchip Harmony (MPLABX)

TPM 2.0 Modules

These TPM (Trusted Platform Module) 2.0 modules are tested and running in the field:

  • STM ST33TP* SPI/I2C
  • Infineon OPTIGA SLB9670/SLB9672/SLB9673
  • Microchip ATTPM20
  • Nations Tech Z32H330TC
  • Nuvoton NPCT650/NPCT750
  • Nations NS350

PKCS#11 Support

We have our own wolfPKCS11 with support for TPM 2.0 using wolfTPM. We also offer support for PKCS11 to interface to various HSMs like:

  • Infineon TriCore Aurix
  • Renesas RH850
  • ST SPC58

Direct Secure Element Access

For direct Secure Element access, we have ports in wolfSSL for:

Hardware Cryptographic Acceleration

Wolfcrypt has support for the following:

NXP Platforms

  • NXP CAAM (Cryptographic Acceleration and Assurance Module) on i.MX6 (QNX), i.MX8 (QNX/Linux), RT1170 FreeRTOS

Intel & ARM Security

Maxim Integrated

STM32 Platform Support

  • STM32MP135F – Complete hardware acceleration suite with STM32CubeIDE support, HAL support for SHA-2/SHA-3/AES/RNG/ECC optimizations
  • STM32H5 – Advanced performance microcontroller support
  • STM32WBA – Wireless connectivity focused platform
  • STM32G4 – General purpose microcontroller series
  • STM32U575xx – Ultra-low-power microcontroller boards
  • STM32 Cube Expansion Pack – Enhanced development support

Renesas Hardware Acceleration

  • Renesas TSIP – RSA Public Encrypt/Private Decrypt operations, AES-CTR mode support
  • Renesas SCE – RSA crypto-only support

Infineon Security Solutions

  • Infineon TriCore (TC2XX/TC3XX) – Hardware security module with TPM support
  • Infineon SLB9672/SLB9673 – Advanced TPM modules with firmware update capabilities
  • Infineon Modus Toolbox – Development environment integration
  • Infineon CyHal I2C/SPI – Hardware abstraction layer support

Development Board Support

  • Raspberry Pi RP2350 – Latest generation with enhanced RNG optimizations
  • Raspberry Pi RP2040 – Improved support with RNG optimizations
  • SiFive HiFive Unleashed Board – RISC-V development board support

Bootloader and OS Integration

  • U-Boot Bootloader – Secure boot integration with TPM support
  • Zephyr Project RTOS – Real-time operating system with TPM integration
  • Microchip Harmony (MPLABX) – Complete development ecosystem support

Advanced Features

  • Memory Mapped I/O (MMIO) TPMs – Direct memory access to TPM modules
  • Pre-provisioned Device Identity Keys – Support for manufacturer-provisioned security credentials
  • Firmware Update Support – Secure firmware update capabilities for supported TPM modules

For more detailed information on our supported hardware take a look at our Hardware Support list.

PSA (Platform Security Architecture)

Wolfcrypt also can make use of PSA (Platform Security Architecture). This includes the following algorithms:

  • Hashes: SHA-1, SHA-224, SHA-256
  • AES: AES-ECB, AES-CBC, AES-CTR, AES-GCM, AES-CCM
  • ECDH PK callbacks (P-256)
  • ECDSA PK callbacks (P-256)
  • RNG

wolfBoot Integration

Another product of interest could be wolfBoot, which – as the name suggests – is a bootloader that can use an HSM (Hardware Security Module) for validation and verification. It also provides secure vaults accessible via PKCS#11 API and secured through the ARM TrustZone technology. WolfBoot also supports all of the TPMs and secure elements listed above, as it inherits all of wolfCrypt’s capabilities. WolfBoot can also be combined with wolfTPM to implement measured boot.

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

Deprecation Notice: TLS 1.3 Draft 18

The wolfSSL team is deprecating the following:

  • WOLFSSL_TLS13_DRAFT preprocessor macro
  • –enable-tls13-draft18 configure option

These components were originally introduced during the TLS 1.3 standardization process to support interoperability with implementations based on Draft 18 of the TLS 1.3 specification. During the multi-year standardization process (2014-2018), multiple draft versions were published before the final RFC 8446 was released in August 2018.

The –enable-tls13-draft18 configure option currently has no functional effect in the codebase and serves no purpose.

The WOLFSSL_TLS13_DRAFT macro, when defined, modifies version number handling in TLS handshakes to use draft-specific version numbers (TLS_DRAFT_MAJOR = 0x7f) instead of the final TLS 1.3 version numbers. This was designed to maintain compatibility with implementations during the transition period which ended long ago.

Maintaining compatibility with obsolete specifications introduces unnecessary complexity. The TLS ecosystem has fully migrated to the TLS 1.3 standard. For these reasons, we are eliminating draft compatibility.

This decision is not yet final. If you think you need these configuration flags to be available, please reach out to us at support@wolfssl.com and let us know.

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

SLIM: Securing AI Agent Communication with MLS

As artificial intelligence continues to evolve and transform industries, here at wolfSSL we are closely monitoring developments in Agent to Agent communication protocols such as A2A and SLIM. We recently wrote our blog post “A2A and wolfSSL” talking about how it is secured via TLS.

One particularly interesting development in this space is SLIM (Secure Low-Latency Interactive Messaging), a communication framework designed specifically for AI agents. What makes SLIM especially noteworthy from a security perspective is its choice of security protocol: Message Layer Security (MLS).

SLIM represents a new approach to AI agent communication, built on the gRPC framework and designed to provide secure, scalable messaging between multiple AI agents. SLIM addresses the unique challenges of group-based AI interactions where multiple agents need to communicate securely and efficiently.

MLS (Message Layer Security) is a relatively new cryptographic protocol standardized in RFC 9420 (https://datatracker.ietf.org/doc/rfc9420/). MLS is specifically designed for secure group messaging scenarios, making it an ideal choice for AI agent communication where multiple participants need to exchange information securely.

MLS provides several key security features that make it well-suited for AI agent communication:

  • Quantum-safe end-to-end encryption ensures that communications between AI agents remain secure even against future quantum computing threats. MLS already incorporates ML-KEM and ML-DSA; NIST standardized post-quantum algorithms for key establishment and authentication.
  • Dynamic group membership management allows AI agents to join and leave communication groups seamlessly. This is particularly important in distributed AI systems where agents may come online and offline dynamically based on computational needs or system requirements.
  • The scalable key management system in MLS uses a tree-based structure that efficiently handles groups ranging from just a few agents to thousands of participants. This scalability is essential for large-scale AI deployments where numerous agents need to coordinate their activities.
  • Allows the use of FIPS 140-3 approved algorithms such as AES-GCM, ECDSA and ECDHE; well-established, modern cryptographic primitives.

At wolfSSL, we recognize the importance of MLS in the evolving landscape of secure communications. We are actively working on an MLS implementation and have detailed our progress in our recent blog post about how MLS is on track for broader adoption (https://www.wolfssl.com/mls-messaging-layer-security-is-on-track/). Notably, wolfSSL will be the first to bring post-quantum algorithm implementations to MLS and therefore to SLIM, ensuring that AI agent communication remains secure even in the face of future quantum computing threats. Our commitment to supporting emerging security protocols ensures that developers building the next generation of secure applications, including AI agent communication systems like SLIM, have access to robust, well-tested cryptographic implementations. Moreover, with our multiple FIPS 140-3 certificates, we can provide cryptographic implementations that are tested and trusted within the federal government.

While wolfSSL does not currently implement MLS itself, our ongoing work continues to move forward. Want to see this effort accelerated? The best way to raise the priority is to let us know you’re interested. Send a message to facts@wolfssl.com to register your interest in SLIM and MLS.

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

DICE Boot Chain Via wolfCrypt’s Minimal Binary Footprint

Device Identifier Composition Engine (DICE) represents a fairly simple approach to hardware-based device identity and secure boot. DICE creates Cryptographic Device Identities (CDIs) through a blockchain-like verification process, where each boot stage measures the next component and derives unique Compound Device Identifiers using the following formula:

CDI_n = HMAC(CDI_n-1, Hash(program))

CDI_0 = UDS

The formulas mean that each element of the bootchain cryptographically verifies the previous CDI and then generates its new CDI to be passed on to the next stage boot loader. Of course the initial CDI is not a CDI at all, but a UDS (Unique Device Secret). This could be supplied by a PUF (Physically Unclonable Function) but does not need to be; as long as it is unique. wolfHSM is an excellent platform to securely store and sign this secret data. The same process is recursively repeated up the bootchain.

This creates an immutable chain of trust from hardware root secrets through firmware verification, enabling remote attestation and secure key provisioning for IoT devices. The observant reader will note that this differs from a conventional boot chain in that it allows for firmware later in the bootchain to verify the integrity of all the entities in the bootchain before it. Normally, entities in the boot chain only verify software images AFTER them in the boot process.

The specification supports and allows for a plethora of algorithms, notably DICE-compatible algorithms including ECDSA P-256, SHA-256, and Hash DRBG, making it ideal for resource-constrained embedded systems. For system integrators who have minimal binary footprint requirements, wolfCrypt can be built for Bare Metal ARM to support these algorithms within 30KB.

wolfBoot serves as an ideal secure bootloader for DICE-enabled systems, providing memory-efficient firmware authentication and update capabilities. The bootloader’s minimalist design and tiny HAL API also provides secure firmware update mechanisms.

Beyond wolfBoot, custom bootloaders can leverage the same optimized cryptographic implementations to build DICE-compatible secure boot solutions tailored to specific hardware platforms and security requirements.

Are you interested in seeing this work as part of your DICE bootchain? There is no need to wait any longer! Send a message to facts@wolfssl.com to register your interest in DICE with our team and raise the priority in our roadmap for wolfBoot and wolfHSM!

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

Download wolfSSL Now

Live Webinar: Everything You Need to Know About Medical Device Cybersecurity – Tailored for the Asia-Pacific Time Zone

Elevate your cybersecurity strategy with proven solutions built for connected care.

Join us on September 4th at 5 PM PT / September 5th at 9 AM JST for a live webinar led by wolfSSL Senior Software Engineer Eric Blankenhorn. We’ll cover how to strengthen cybersecurity across the entire medical device ecosystem from implantables and patient monitors to bedside devices and cloud platforms. This session will highlight regulatory requirements, key security challenges, and how wolfSSL’s embedded solutions can help you address them.

Register now: Everything You Need to Know About Medical Device Cybersecurity
This webinar is tailored for the Asia-Pacific Time Zone
Date: September 4th | 5 PM PT / September 5th | 9 AM JST

In this webinar, Eric will dive into current cybersecurity threats in healthcare, industry trends, and the growing regulatory pressure on connected devices. Learn how wolfSSL’s lightweight, FIPS 140-3 validated cryptography and secure boot technology can help prevent tampering, conserve power, and support compliance with HIPAA, VA, and other mandates.

Register now to strengthen your security posture in connected healthcare.

As always, our webinar will include Q&A throughout. If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

Top 15 FIPS Terms You Should Know – The Full Breakdown

We recently shared our top 15 FIPS acronyms and terms to help you get familiar with the basics. Now, let’s dive deeper into what each of these means and why they matter in the FIPS 140-3 certification process.

  1. FIPS – Federal Information Processing Standards

    FIPS are standards published by the U.S. federal government that specify security requirements for cryptographic modules. FIPS 140-3 is the current standard for validating cryptographic modules, ensuring they meet strict security and implementation guidelines for use in government and regulated industries.

  2. NIST – National Institute of Standards and Technology

    NIST develops and maintains FIPS standards. It also oversees the Cryptographic Module Validation Program (CMVP), coordinating with testing labs and vendors to ensure modules meet FIPS 140-3 requirements.

  3. CMVP – Cryptographic Module Validation Program

    This is the official program, jointly run by NIST and Canada’s CCCS, that validates cryptographic modules against the FIPS 140-3 standard. Vendors submit their modules to CMVP-accredited labs, which test and verify compliance before issuing certificates.

  4. CAVP – Cryptographic Algorithm Validation Program

    Before a cryptographic module can be validated, each cryptographic algorithm it uses (such as AES, SHA, ML-KEM, ML-DSA, RSA, ED25519, KDF’s for various protocols… etc.) must be validated under CAVP. This ensures the algorithms are correctly implemented and function as intended and guarantees interoperability with any other validated module(s).

  5. ESV – Entropy Source Validation

    Entropy Source Validation is a separate validation process that verifies the quality and reliability of the randomness source used by the cryptographic module, crucial for secure key generation and other cryptographic operations that depend on high quality entropy to guarantee certain levels of bit-strength.

  6. ACVP – Automated Cryptographic Validation Protocol

    ACVP is the automated system that facilitates cryptographic algorithm testing within the CAVP framework. It allows machine-to-machine communication between vendors and validation servers (DEMO), and labs and validation servers (PRODUCTION) speeding up the testing process and reducing errors.

  7. NVLAP – National Voluntary Lab Accreditation Program

    NVLAP accredits independent labs authorized to perform FIPS 140-3 testing. Only NVLAP-accredited labs can conduct the official testing required for CMVP certification.

  8. SP – Security Policy

    The Security Policy is a detailed document that describes the cryptographic module’s security features, intended use, and operational modes. It defines how the module should be configured and used to remain compliant and in the approved mode of operation.

  9. UG – User Guide

    The User Guide provides instructions for deploying and operating the cryptographic module securely and in compliance with FIPS requirements. It ensures end users configure and use the module correctly so it is running the FIPS 140-3 approved mode of operation.

  10. OE – Operational Environment

    The Operational Environment refers to the specific combination of hardware (chipset), operating system, and cryptographic module configuration used during testing. Different OEs require separate validation to ensure proper validation/certification.

  11. Tested Configuration

    The Tested Configuration specifies the exact hardware and software setup (including form factor, OS version, chipset details) that was used during testing. Users must match this configuration to maintain FIPS 140-3 validation.

  12. OEUP – Operational Environment Update

    An OEUP is a process to add a new Operational Environment (new chipset or OS) to an existing FIPS certificate without undergoing full revalidation. This allows validated modules to support more platforms efficiently over time.

  13. UPDT – Module Update

    A Module Update (UPDT) applies when there are security-relevant changes to the cryptographic module, such as updates to code, algorithms, or key management. It requires a new certificate and resets the module’s sunset date.

  14. PAA – Processor Algorithm Acceleration

    Processor Algorithm Acceleration refers to hardware-assisted cryptographic acceleration features, like AES-NI or Arm Crypto Extensions, which improve performance and efficiency of cryptographic operations within validated modules.

  15. RBND – Rebrand

    Rebranding (RBND) lets a company apply its own branding and logo to an existing FIPS 140-3 certified module, often referred to as white-labeling. This helps companies market validated products without needing to repeat the entire certification process or point to a third-party certificate for their products.

Understanding these terms is critical whether you’re developing, integrating, or managing FIPS 140-3 validated cryptographic modules. At wolfSSL, we leverage this knowledge to help customers navigate complex validation requirements and deliver secure, compliant solutions.

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

Top 15 FIPS Terms You Should Know

Working with FIPS 140-3 can get confusing fast, especially with all the acronyms involved. To help cut through the noise, here are our top 15 FIPS-related terms:

  • FIPS – Federal Information Processing Standards
  • NIST – National Institute of Standards and Technology
  • CMVP – Cryptographic Module Validation Program
  • CAVP – Cryptographic Algorithm Validation Program
  • ESV – Entropy Source Validation (separate from but complimentary to a FIPS certificate)
  • ACVP – Automated Cryptographic Validation Protocol
  • NVLAP – National Voluntary Lab Accreditation Program
  • SP – Security Policy
  • UG – User Guide
  • OE – Operational Environment (Chipset + OS + Cryptographic module)
  • Tested Configuration – OE description including form factor used for testing
  • OEUP – Operational Environment Update (add an OE to an existing FIPS certificate)
  • UPDT – Module Update (Security relevant changes to an existing FIPS module, results in a new certificate # and new sunset date)
  • PAA – Processor Algorithm Acceleration (Hardware assisted cryptographic acceleration)
  • RBND – Rebrand an existing FIPS certificate into your company’s own letter/logo-head for marketing purposes (often referred to as a white-label)

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

wolfMQTT: Using wolfCrypts implementation of ML-KEM and ML-DSA

A long time ago, we added support for Kyber and Falcon in wolfMQTT. That support used an integration into liboqs for the Kyber and Falcon implementation.

Things have changed since then! Kyber is no longer Kyber, it is now ML-KEM. Falcon will soon become FN-DSA, but since then rock solid standards for ML-DSA have been released so a strong focus within the industry has been put on it. And now, wolfCrypt has its very own implementations of ML-KEM and ML-DSA.

As such, very recently, we updated our instructions for wolfMQTT to show how to do an interoperability demo against the OQS’s port of Mosquitto on top of OpenSSL3 and the OQS provider. The interoperability demo shows the Mosquitto broker and subscriber listening to the wolfMQTT publisher. Check out the the very simple and easy to follow instructions.

Please go ahead and try it out for yourself!

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

OpenSSL Compatibility Layer Additions in wolfSSL 5.8.2

The wolfSSL’s repo pull request #8897 adds significant OpenSSL compatibility layer enhancements across four key areas: RSA operations, big number mathematics, X.509 certificate extensions, and private key serialization.

RSA API Enhancements:

The PR introduces comprehensive RSA-PSS (Probabilistic Signature Scheme) support with enhanced OpenSSL compatibility. Key additions include:

  • wolfSSL_EVP_PKEY_CTX_set_rsa_pss_saltlen() for configuring salt lengths
  • wolfSSL_EVP_PKEY_CTX_set_rsa_mgf1_md() for setting MGF1 hash algorithms
  • wolfSSL_EVP_PKEY_CTX_set_rsa_oaep_md() for RSA-OAEP padding configuration
  • The existing wolfSSL_RSA_sign and wolfSSL_RSA_verify functions have been enhanced to support RSA-PSS with custom salt lengths and MGF1 hash types.
  • Additional functions include wolfSSL_RSA_padding_add_PKCS1_PSS_mgf1() and wolfSSL_RSA_verify_PKCS1_PSS_mgf1() for advanced PSS padding operations with MGF1 support.

Bignum API Additions:

A new wolfSSL_BN_ucmp() function has been added that compares the absolute values of two WOLFSSL_BIGNUM structures. This function provides OpenSSL-compatible behavior identical to BN_ucmp(). The implementation uses internal duplication to avoid modifying const input parameters, making the implementation compliant with the API.

X.509 Extensions API Additions:

Two X.509 certificate extension handling functions have been added. The wolfSSL_X509v3_get_ext_by_NID() function searches for extensions by their Numeric Identifier (NID) within a stack of extensions, supporting iterative searching with a “lastpos” parameter. The wolfSSL_X509v3_get_ext() function retrieves extensions by index position from an extension stack. Both functions enable programmatic certificate extension processing for PKI applications, policy enforcement, and extension data extraction.

Private Key DER Output API Additions:

The new wolfSSL_i2d_PrivateKey_bio() function provides private key serialization to DER format through BIO objects. This function performs a two-pass operation to determine buffer size and encode the key.

These additions collectively enhance wolfSSL’s OpenSSL compatibility layer, providing essential functionality for RSA-PSS operations, mathematical computations, certificate processing, and key management operations required by modern cryptographic applications.

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

Download wolfSSL Now

Live Webinar: WolfGuard: FIPS 140-3 Enabled WireGuard

WireGuard is known for its simplicity, speed, and modern cryptography, but what if your deployment requires FIPS 140-3 validated security? That’s where WolfGuard comes in.

Join wolfSSL Software Engineer Lealem Amedie as he introduces WolfGuard, a FIPS 140-3 enabled WireGuard solution optimized for speed and cryptographic agility. Built on the FIPS-certified wolfCrypt library, WolfGuard delivers all of WireGuard’s functionality with the assurance of FIPS-approved algorithms.

Register now: WolfGuard: FIPS 140-3 Enabled WireGuard
Date: August 27th | 9 AM PT

This webinar will cover:

  • WireGuard fundamentals and implementations (Linux, GO, BoringTun)
  • How WireGuard secures tunnels and encrypts data
  • FIPS 140-3, FedRAMP, and CMMC 2.0 compliance needs
  • How WolfGuard integrates FIPS into WireGuard with zero architectural changes
  • Real-world use cases + live demo with WolfGuard Go

If you need WireGuard with FIPS 140-3 compliance and zero complexity trade-offs, WolfGuard is your solution.

Register now to see WolfGuard in action and achieve compliance in your VPN deployments.

As always, our webinar will include Q&A throughout. If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 425 8247.

Download wolfSSL Now

Posts navigation

1 2 3 4 … 208 209 210

Weekly updates

Archives