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 Advances FIPS Leadership with New Certificate #5041 and Evergreen FIPS 140 Strategy

wolfSSL Inc., a globally renowned leader in cryptography and network security solutions, announces the latest milestone in its FIPS strategy with the issuance of FIPS 140-3 Validated Certificate #5041 for the wolfCrypt cryptographic module. This marks yet another step forward in wolfSSL’s long-term strategy to deliver agile, secure, and compliant cryptography across embedded and enterprise environments.

EDMONDS, Wash., Aug. 4, 2025 /PRNewswire-PRWeb/ — wolfSSL Inc., a globally renowned leader in cryptography and network security solutions, announces the latest milestone in its FIPS strategy with the issuance of FIPS 140-3 Validated Certificate #5041 for the wolfCrypt cryptographic module. This marks yet another step forward in wolfSSL’s long-term strategy to deliver agile, secure, and compliant cryptography across embedded and enterprise environments.

Evergreen FIPS 140-3 Subscription Program

FIPS 140-3 Validated Certificate #5041, effective through July 2030, extends the life cycle of wolfSSL’s industry-first SP800-140Br1 FIPS 140-3 Validated Certificate #4718, providing customers with flexibility, long-term assurance, and uninterrupted compliance under evolving FIPS 140-3 requirements.

This new certificate represents more than just continuity, it’s a reflection of our unwavering commitment to security leadership and customer success, said Todd Ouska, wolfSSL CTO. With our Evergreen Certificate Subscription, organizations using wolfSSL maintain continuous compliance, seamlessly transitioning to the latest validations without disruption or compliance gaps.

wolfSSL’s Evergreen Certificate Subscription eliminates expiration gaps for FIPS 140-3 validations. Customers purchasing an Evergreen FIPS Subscription automatically transition from Certificate #4718 to #5041 upon #4718’s expiration. With three more certificates already in the queue, each with rolling expiration dates, wolfSSL’s customers can easily maintain continuous FIPS coverage at an economic price.

wolfSSL’s Evergreen Certificate Subscription eliminates expiration gaps for FIPS 140-3 validations. Customers purchasing an Evergreen FIPS Subscription automatically transition from Certificate #4718 to #5041 upon #4718’s expiration. With three more certificates already in the queue, each with rolling expiration dates, wolfSSL’s customers can easily maintain continuous FIPS coverage at an economic price.

Full Linux FIPS 140-3

wolfSSL’s Full Linux FIPS offering simplifies FIPS compliance for operating systems that host a variety of cryptography libraries. This solution is for NVIDIA Open GPU, Alpine, Dynebolic, Debian, Alma, Yocto, Rocky,Gentoo, KALI and other Linux distributions that don’t have a current FIPS solution. By patching key libraries, including GnuTLS, OpenSSL, NSS, libgcrypt, and the Linux kernel, wolfSSL enables FIPS 140-3 compliance without modifying application code. This solution can also be made available for BSD. Linux consumers will no longer be burdened with leaving their favorite distro to go to an expensive per cpu subscription to get to FIPS compliance.

This integration simplifies the lives of maintainers that need to get to FIPS 140-3 for government use. It provides immediate access to wolfCrypt’s validated algorithms, cutting down the time and complexity of certification from years to months.

Post Quantum FIPS 140-3 support

wolfSSL stays ahead of FIPS 140-3 certification with two additional certifications in process:

  • Our next cert adds SRTP and XTS to support secure real-time communications and encrypted storage
  • Post-Quantum FIPS 140-3 Certification: Aligned with CNSA 2.0 guidance and kicking off this year, this certification will feature quantum-resistant algorithms such as ML-KEM ML-DSA, LMS, and XMSS

These upcoming certifications reinforce wolfSSL’s reputation as the most agile and forward-compatible cryptographic provider on the market.

Contact us at: fips@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

LMS Versus XMSS Versus SLH-DSA

Here at wolfSSL, we don’t just love coding! We love telling the world about what we code. To that end, we want you to understand the differences between LMS, XMSS, and SLH-DSA. Here are their official standard specifications:

The most important similarity of these three algorithms is that they are all hash-based signature schemes. Being hash-based, they are all quantum-safe signature schemes that rely on the tried and true security properties of proven battle-hardened hashing algorithms. They all use Merkle Trees to combine many data structure instances into a single public key.

These instances form the leaf nodes of the Merkle tree and are called WOTS (Winternitz One-Time Signature) in LMS and WOTS+ in XMSS. WOTS uses a “prefix construction” while WOTS+ uses a “prefix and bitmask construction” with random bitmasks to give it stronger security assumptions.

XMSS uses “L-trees” for compression, requiring more hashing operations. LMS does not have a corresponding compression scheme.

From the perspective of performance, LMS is consistently better (fewer clock cycles) for key generation, signing, and verification.

Generally speaking, XMSS has higher memory consumption, mostly during signing and verification.

While XMSS has various theoretical optimizations that would hamper interoperability, LMS remains more efficient in practice, but the difference is quite negligible. If security assurance via the bitmask constructions are important to you, then you should go with XMSS, but LMS is a better default.

The thing that LMS and XMSS both have in common is that they have a state and a limited number of available signatures; once that limit is hit, the private key must be discarded. The state is very important because if it is mismanaged, the signer might reuse a WOTS or WOTS+ which would then allow an attacker to forge signatures. With this formidable problem in mind, SLH-DSA was designed to eliminate this pitfall by not requiring state. SLH-DSA takes a randomized approach and makes conjectures on the probability of collisions. Note that the SLH-DSA equivalent of WOTS is a “few time signature”.

With the elimination of state, SLH-DSA opens the door to parallelization and distributed usage while LMS and XMSS would have signing operations tightly coupled to a single instance of the private key limiting it to serial signing operations.

Finally, one of the most important distinctions is that all three algorithms are standardized and recognized by NIST while only LMS and XMSS are approved for use under CNSA 2.0.

This concludes our comparison of LMS, XMSS and SLH-DSA. That said, this has only touched on the surface of these algorithms. Want deeper technical details? Looking to know which is most appropriate for your use-case? Have some more questions? Let us know by sending a message to facts@wolfSSL.com; we are always happy to continue the conversation!

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

Empowering Space Missions with NASA-STD-1006A Compliance

Space missions require strong security to guard against cyber threats. The wolfCrypt cryptography library meets all encryption requirements in NASA’s Space System Protection Standard (NASA-STD-1006A), providing lightweight cryptography suited for resource-constrained secure command communications.

Understanding NASA-STD-1006A

NASA-STD-1006A, titled “Space System Protection Requirements,” establishes agency-level guidelines to make NASA missions resilient against cyber threats. Approved in 2019 and updated as needed, the standard focuses on safeguarding command stacks, backup links, and critical program information (CPI). Key encryption mandates include protecting command paths with cryptography that meets or exceeds Federal Information Processing Standard (FIPS) 140 Level 1.

You can access the full standard on NASA’s official standards portal: NASA-STD-1006A.

How wolfCrypt Meets These Requirements

wolfCrypt is a lightweight, ANSI C-based crypto library designed for embedded and RTOS environments, making it ideal for space applications where size, speed, and power efficiency are critical. With a small footprint and royalty-free licensing, it’s deployed in millions of devices worldwide.

At the heart of its compliance is wolfCrypt’s FIPS 140-3 validation (Certificate #4718), which meets the standard’s FIPS 140 Level 1 requirement. This validation confirms that wolfCrypt’s implementations are secure and reliable. wolfCrypt’s validated algorithms can be directly used to address NASA-STD-1006A’s core requirements, such as encrypting command stacks (SSPR 1) and supporting authentication for backups (SSPR 2). For CPI protection (SSPR 3), wolfCrypt integrates seamlessly with NIST SP 800-171 practices, ensuring data confidentiality at rest and in transit.

Additionally, wolfCrypt supports progressive ciphers, post-quantum options (ML-KEM, ML-DSA, LMS, XMSS), and assembly optimizations for a variety of architectures.

If needed, wolfSSL also offers a secure bootloader for microcontrollers (wolfBoot), a software HSM library (wolfHSM), a secure SSL/TLS implementation (wolfSSL), and more!

wolfCrypt in Space: Real-World Applications

wolfSSL has a proven track record in high-stakes environments, including aerospace and defense. Our recent collaboration with Frontgrade Gaisler enhances cybersecurity for space applications by integrating wolfCrypt into radiation-hardened processors, ensuring secure communications in harsh orbital conditions. Read more about this partnership: Frontgrade Gaisler and wolfSSL Collaboration.

wolfCrypt’s modular design also supports DO-178C DAL A certification for avionics, further demonstrating its suitability for space systems. If you’re working on NASA-compliant projects, wolfCrypt provides the tools to build resilient, threat-resistant architectures.

Why Choose wolfCrypt for Your Space System?

  • Lightweight and Efficient: Minimal runtime memory and build size, perfect for embedded space hardware.
  • Comprehensive Support: Backed by wolfSSL’s expert team, with resources like benchmarks, hardware integration guides, and an OpenSSL compatibility layer.
  • Future-Proof Security: Includes post-quantum cryptography to guard against emerging threats.
  • Easy Integration: Simple API, extensive documentation, and examples available in our GitHub repository: wolfSSL Examples.

Ready to Secure Your Mission?

If you’re ready to integrate wolfCrypt into your space system, need support, or have questions about any of the above, please contact our team at facts@wolfssl.com, call +1 425 245 8247, or visit our support page: wolfSSL Support.

Download wolfSSL Now

Live Webinar: Post-Quantum TLS 1.3 Over UART

Learn how to build an app for the STM32-U5 using TLS 1.3 over UART with a hybrid key exchange combining ECC and post-quantum ML-KEM!

The STM32U5 series features advanced power-saving, high-performance microcontrollers based on the Arm® Cortex®-M33, designed for demanding applications that require both performance and low power consumption. It provides greater integration and memory capabilities to maximize performance.

wolfSSL supports post-quantum cryptography solutions, including ML-KEM (Kyber) and ML-DSA (Dilithium). Migrating to post-quantum algorithms protects your data long-term (harvest now, decrypt later) and aligns with the CNSA 2.0 timeline, which requires post-quantum cryptography for software/firmware signing by 2025.

Register Today: Post-Quantum TLS 1.3 Over UART
Date: August 14th | 9 AM PT

In this webinar, we will guide you through installing wolfSSL via STM32CubeIDE, enabling post-quantum algorithms, and discuss the benefits and challenges of using ML-KEM for post-quantum security. Learn how to future-proof your security on the STM32U5 with post-quantum cryptography.

What you’ll learn:

  • Install wolfSSL via the STM32CubeIDE
  • Configure and enable the post-quantum algorithms in wolfSSL
  • Understand the motivation behind enabling ML-KEM
  • Explore the benefits and challenges of ML-KEM integration

Register now to secure your spot!

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.

Note: This session is a replay of a partner webinar originally presented with STMicroelectronics and will include a live Q&A.

Download wolfSSL Now

Updated Post-Quantum Benchmarks for ML-KEM and ML-DSA on STM32

A long, long time ago, we took some benchmarks for Kyber on STM32 NUCLEO-F446ZE. Back then, it was the NIST Submission of Kyber, and we were using the implementation from PQM4 as integration in wolfCrypt. Now, Kyber has evolved into ML-KEM, and we have our implementation! We decided to take some benchmarks on a newer STM32 hardware platform as well. Note that we now also have our implementation of ML-DSA which evolved from Dilithium so we also took benchmarking numbers for it as well.

Here are the numbers (some formatting changes have been made for readability):

RSA    2048  public        112 ops took 1.012 sec, avg   9.036 ms, 110.672 ops/sec
RSA    2048  private         4 ops took 1.298 sec, avg 324.500 ms,   3.082 ops/sec
DH     2048  key gen         7 ops took 1.150 sec, avg 164.286 ms,   6.087 ops/sec
DH     2048  agree           8 ops took 1.310 sec, avg 163.750 ms,   6.107 ops/sec
ML-KEM 512   key gen       248 ops took 1.000 sec, avg   4.032 ms, 248.000 ops/sec
ML-KEM 512   encap         262 ops took 1.000 sec, avg   3.817 ms, 262.000 ops/sec
ML-KEM 512   decap         198 ops took 1.000 sec, avg   5.051 ms, 198.000 ops/sec
ML-KEM 768   key gen       154 ops took 1.004 sec, avg   6.519 ms, 153.386 ops/sec
ML-KEM 768   encap         154 ops took 1.012 sec, avg   6.571 ms, 152.174 ops/sec
ML-KEM 768   decap         120 ops took 1.000 sec, avg   8.333 ms, 120.000 ops/sec
ML-KEM 1024  key gen        94 ops took 1.008 sec, avg  10.723 ms,  93.254 ops/sec
ML-KEM 1024  encap          94 ops took 1.016 sec, avg  10.809 ms,  92.520 ops/sec
ML-KEM 1024  decap          78 ops took 1.024 sec, avg  13.128 ms,  76.172 ops/sec
ECC   [SECP256R1] key gen  180 ops took 1.007 sec, avg   5.594 ms, 178.749 ops/sec
ECDH  [SECP256R1] agree     86 ops took 1.016 sec, avg  11.814 ms,  84.646 ops/sec
ECDSA [SECP256R1] sign     106 ops took 1.000 sec, avg   9.434 ms, 106.000 ops/sec
ECDSA [SECP256R1] verify    60 ops took 1.012 sec, avg  16.867 ms,  59.289 ops/sec
ML-DSA    44  key gen       52 ops took 1.011 sec, avg  19.442 ms,  51.434 ops/sec
ML-DSA    44  sign          18 ops took 1.086 sec, avg  60.333 ms,  16.575 ops/sec
ML-DSA    44  verify        46 ops took 1.008 sec, avg  21.913 ms,  45.635 ops/sec
ML-DSA    65  key gen       30 ops took 1.035 sec, avg  34.500 ms,  28.986 ops/sec
ML-DSA    65  sign          12 ops took 1.008 sec, avg  84.000 ms,  11.905 ops/sec
ML-DSA    65  verify        28 ops took 1.027 sec, avg  36.679 ms,  27.264 ops/sec
ML-DSA    87  key gen       18 ops took 1.047 sec, avg  58.167 ms,  17.192 ops/sec
ML-DSA    87  sign          10 ops took 1.255 sec, avg 125.500 ms,   7.968 ops/sec
ML-DSA    87  verify        16 ops took 1.003 sec, avg  62.687 ms,  15.952 ops/sec

This was done on an STM32 NUCLEO-F439ZI ARM Cortex M4 running at 168 MHz. The wolfSSL library was built with assembly optimizations, but does not use any hardware accelerated cryptography. Note: At the time of this writing the ML-DSA (Dilithium) is not using assembly optimizations, just well constructed C code.

  • ML-DSA beats RSA quite nicely and is within an order of magnitude against ECDSA.
  • ML-KEM beats DH and ECDH by a wide margin (thanks to assembly code for Thumb2).

Here are some special macro flags that were defined:

#define WOLFSSL_SP_ARM_CORTEX_M_ASM
#define WOLFSSL_HAVE_SP_RSA
#define WOLFSSL_HAVE_SP_ECC
#define WOLFSSL_SP_SMALL
#define SP_WORD_SIZE 32
#define GCM_TABLE_4BIT

#define HAVE_DILITHIUM
#define WOLFSSL_WC_DILITHIUM
#define WOLFSSL_DILITHIUM_SMALL

#define WOLFSSL_ARMASM
#define WOLFSSL_ARMASM_INLINE
#define WOLFSSL_ARMASM_NO_HW_CRYPTO
#define WOLFSSL_ARMASM_NO_NEON
#define WOLFSSL_ARMASM_THUMB2
#define WOLFSSL_ARM_ARCH 7

We support assembly optimizations on most algorithms and key sizes with Intel x86/x64, ARM Cortex-A/M/R, RISC-V and PowerPC.

If you are interested in seeing other algorithms benchmarked, or have questions about any of the above, please reach out to us at facts@wolfssl.com or call us at +1 425 245 8247 to let us know which ones!

Download wolfSSL Now

Optimizing Post-Quantum Algorithm Memory Usage on Embedded Systems

Here at wolfSSL, we are intimately aware of the needs of our embedded customers. It is always about the tradeoffs and optimizations that fit their unique use cases and needs. The tradeoffs are typically between speed, footprint size, and memory usage. In many of our blog posts, we like to focus on our speed performance, but in this post, we look at options around memory usage. This is especially important for our post-quantum algorithms, ML-KEM and ML-DSA, as they are generally faster or on par with their conventional counterparts, such as ECDSA and ECDH, but do use more memory.

We are going to focus on some experiments we did on a Raspberry Pi5. We built and ran wolfSSL’s testwolfcrypt and got some statistics. Here are the results:

Configuration Algorithm Stack (bytes) Heap (bytes) Total (bytes) Heap Allocs
Small code MLKEM-512 23,568 7,552 31,120 3
MLKEM-768 32,672 11,968 44,640 3
MLKEM-1024 42,400 17,568 59,968 3
MLDSA-44 15,904 50,304 66,208 2
MLDSA-65 17,440 77,952 95,392 2
MLDSA-87 19,376 120,960 140,336 2
Small code with small mem MLKEM-512 23,696 3,968 27,664 3
MLKEM-768 32,928 5,824 38,752 3
MLKEM-1024 42,656 7,840 50,496 3
MLDSA-44 15,856 15,656 31,512 2
MLDSA-65 17,392 20,776 38,168 2
MLDSA-87 19,328 26,920 46,248 2
Small code with small mem + stack MLKEM-512 2,112 19,306 21,418 17
MLKEM-768 2,112 27,306 29,418 17
MLKEM-1024 2,112 35,786 37,898 17
MLDSA-44 2,112 28,211 30,323 7
MLDSA-65 2,112 33,331 35,443 7
MLDSA-87 2,160 39,475 41,635 7

Here are some interesting points we noticed in the data:

  • Stack vs Heap Trade-off: WOLFSSL_SMALL_STACK configuration dramatically reduces stack usage (from ~23K-42K to 2,112 bytes)
  • ML-KEM Memory Scaling: Memory usage scales predictably with security levels – ML-KEM-512 uses ~31K total, ML-KEM-768 uses ~44K, and ML-KEM-1024 uses ~59K in default configuration
  • ML-DSA Higher Heap Usage: ML-DSA algorithms use significantly more heap memory (50K-120K) compared to MLKEM (7K-17K) in small code configuration
  • Small Memory Optimization: Adding the small mem configuration flags reduces memory usage by 10 to 15 percent for ML-KEM and 50 to 65 percent for ML-DSA. Quite impressive!

If you’re wondering whether you will be able to use post-quantum algorithms on your system then these numbers should help you get an idea of the resource you will need to allocate.

Here are the configurations and commands used:

Configuration Name Configurations and Command
Small code
$ ./configure –enable-dilithium=all,44,small –enable-mlkem=all,512,small –enable-trackmemory=verbose –enable-stacksize=verbose
$ make
$ ./wolfcrypt/test/testwolfcrypt
Small code with small memory
$ ./configure –enable-dilithium=all,44,small –enable-mlkem=all,512,small CFLAGS=”-DWOLFSSL_DILITHIUM_VERIFY_SMALL_MEM -DWOLFSSL_DILITHIUM_SIGN_SMALL_MEM -DWOLFSSL_DILITHIUM_MAKE_KEY_SMALL_MEM -DWOLFSSL_MLKEM_ENCAPSULATE_SMALL_MEM -DWOLFSSL_MLKEM_MAKEKEY_SMALL_MEM” –enable-trackmemory=verbose –enable-stacksize=verbose
$ make
$ ./wolfcrypt/test/testwolfcrypt
Small code with small mem and small stack
$ ./configure –enable-dilithium=all,44,small –enable-mlkem=all,512,small CFLAGS=”-DWOLFSSL_DILITHIUM_VERIFY_SMALL_MEM -DWOLFSSL_DILITHIUM_SIGN_SMALL_MEM -DWOLFSSL_DILITHIUM_MAKE_KEY_SMALL_MEM -DWOLFSSL_MLKEM_ENCAPSULATE_SMALL_MEM -DWOLFSSL_MLKEM_MAKEKEY_SMALL_MEM” –enable-trackmemory=verbose –enable-stacksize=verbose –enable-smallstack
$ make
$ ./wolfcrypt/test/testwolfcrypt

Let us know if you need us to get even tighter in terms of memory usage. Our cryptographers are wizards when it comes to exploiting tradeoffs!

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

wolfCrypt Examples for Renesas RH850

The RH850 Family of 32-bit automotive microcontrollers (MCUs) is an automotive microcontroller equipped with an integrated Hardware Security Module (HSM). It ensures fast and secure key management, cryptographic processing, and authentication at the hardware level. Designed for next-generation ECUs, it combines functional safety with advanced security.

wolfSSL has now provided a wolfCrypt use case on Renesas RH850 using Renesas CS+ in our wolfSSL Examples GitHub repository. The Github repository contains client and server examples that set up and test various types of connections. In addition to these clients/servers, we have included examples that demonstrate how to build wolfSSL with specific real time operating systems and TCP/IP stacks for embedded systems and devices, and how to use some features of the library like the certificate manager or wolfCrypt’s public-key functionality.

This time, we added the RSAPSS-Sign-Verify program to the repository. You can find <wolfssl-examples>/Renesas/cs+/RH850/rsapss_sign_verify in the repository. The program is a ready-to-run Renesas CS+ program for RH850. Please follow REAME in <wolfssl-examples>/Renesas/cs+/RH850/, then you can easily enjoy RSA Sign/Verify on your device. We will add more examples in the future.

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

MD5 Disabled by Default in wolfSSL: What You Need to Know

As part of our ongoing effort to deliver secure-by-default cryptography, wolfSSL has disabled the MD5 hash algorithm by default in the latest release. Don’t worry, it isn’t going away completely, but just disabled at compile time, by default.

Why Disable MD5?

MD5 has been considered cryptographically broken for many years due to known collision attacks. While it’s still used in legacy systems for non-security-critical purposes, it no longer meets modern security standards. Disabling MD5 by default aligns wolfSSL with best practices and further hardens applications that rely on us for secure communications, and has already been done in FIPS builds of wolfSSL.

What Changed?

MD5 is now disabled by default in the master branch of wolfSSL. We expect this default behavior to be in release 5.8.2 and up. If your application or any third-party dependency attempts to use MD5 without explicitly enabling it, you may encounter build or runtime issues such as:

  • Compilation errors involving wc_InitMd5() or other MD5 functions
  • Protocol negotiation failures if MD5 is assumed as a supported digest (e.g., in TLS 1.0/1.1 or some legacy certificate chains)
  • Unexpected behavior in libraries that rely on MD5 internally but don’t check if it’s available

You can check if MD5 is disabled in your configuration by seeing if NO_MD5 is set at compile time.

How to Re-Enable MD5 (If Needed)

If you’re working in a legacy environment or need MD5 for interoperability reasons, you can explicitly re-enable MD5 support by doing the following.

Builds using autotools:

./configure --enable-md5

Builds using cmake:

mkdir -p build
cd build
cmake .. -DNO_MD5=OFF

We strongly encourage you to audit any use of MD5 in your project before re-enabling it. If it’s being used for digital signatures or certificate verification, consider updating to SHA-256 or stronger algorithms.

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: How to Determine FIPS Compliance for Government Buyers

Cut through the confusion of FIPS 140-3 compliance and learn how to verify it with confidence.

Join us on August 6th at 9 AM PT for a focused webinar presented by wolfSSL Senior Software Engineer Kaleb Himes. This session will break down the complexity of FIPS?140?3 compliance and help government buyers and contributors accurately evaluate solutions.

Register today: How to Determine FIPS Compliance for Government Buyers
Date: August 6th | 9 AM PT

wolfSSL maintains FIPS 140-3 validated certificate #4718 and #5401 and brings unmatched portability, running on everything and well optimized for dozens of Hardware targets. In this webinar, we will walk through exactly how to verify FIPS compliance and avoid common mistakes when reviewing vendor claims.

This webinar will cover:

  • Key FIPS terms and why FIPS matters
  • Why it’s important for your Operating Environment (OE) to appear on the certificate
  • How to looking up and interpret a FIPS certificate (SP800-140Br1 automated FIPS certs vs traditional FIPS certs included)
  • How to locate and read the module’s Security Policy
  • How to determine if an OE was actually tested or only vendor affirmed (SP800-140Br1 vs traditional included)
  • How to check algorithm (CAVP) certificates
  • How to spot fake or misleading FIPS claims

Register today and gain a clear understanding of how to assess FIPS compliance before making procurement decisions.

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

A2A and wolfSSL

Here at wolfSSL, we are seeing a lot of interest in AI. Some of the most fascinating developments that are happening are around letting different AI agents communicate with each other. Do those communications need to be secured, authenticated, and integrity checked? Of course!

Enter the A2A (Agent2Agent) protocol, which uses HTTPS as its primary transport layer.

Check out the official A2A protocol implementation links:

How can wolfSSL help in this endeavor? Well, it is looking like the government is going to be one of the biggest consumers of AI technology, with a fast and agile uptake of AI technology. If they are going to need cryptography to protect this protocol, it had better be FIPS 140-3 certified! Did we mention our FIPS 140-3 certificate #4718?

This shows the chain of dependencies from the A2A reference library down to the OpenSSL library, which provides the underlying cryptographic functionality:

A2A Reference Library → httpx → httpcore → ssl (Python module) → OpenSSL

We can add wolfProvider and wolfCrypt FIPS to that to bring it into compliance so the government can use it! It would look like this:

A2A Reference Library → httpx → httpcore → ssl (Python module) → OpenSSL → wolfProvider → wolfCrypt FIPS

For extra performance, another option would be to do an integration with wolfssl-py; our python wrapper for wolfSSL.

Interested in seeing this happen? We are! Let us know if you’re interested!

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

Posts navigation

1 2 3 4 5 … 208 209 210

Weekly updates

Archives