wolfPKCS11 Supercharged: 42 New Mechanisms and Full NSS Backend Support Unleashes FIPS Crypto
The wolfSSL team is thrilled to announce a monumental update to wolfPKCS11, now available in the master branch on GitHub. This release transforms wolfPKCS11 into a premier, high-performance PKCS#11 provider by incorporating an incredible 42 new cryptographic mechanisms and 8 new API functions. This focused engineering effort enables wolfPKCS11 to serve as a complete and robust backend for Mozilla’s Network Security Services (NSS).
This achievement makes our vision from the “Firefox Gets FIPS 140-3 Power” post a production-ready reality. Now, any application using NSS—including Firefox, Thunderbird, and Linux server products—can be powered by our FIPS 140-3 validated wolfCrypt engine, bringing federally certified security and our signature performance and efficiency to the entire NSS ecosystem.
The Strategic Advantage: FIPS-Powered NSS
PKCS#11 is the industry-standard API for communicating with cryptographic hardware and software modules. NSS uses a PKCS#11 module to perform all its cryptographic operations. Our update provides the comprehensive support NSS requires, allowing wolfPKCS11 to act as a “drop-in” bridge to our wolfCrypt engine.
This integration provides a simple and efficient pathway to FIPS compliance for organizations in regulated industries. Instead of complex and costly application overhauls, using wolfPKCS11 with a FIPS-validated wolfCrypt backend becomes a straightforward configuration change, saving immense time and resources.
Feature Highlights: A New Level of Capability
The 42 new mechanisms expand wolfPKCS11’s capabilities to cover the full spectrum of modern cryptographic needs. Key additions include:
- Modern Signatures: Support for the modern and provably secure RSA-PSS signature schemes (CKM_SHA256_RSA_PKCS_PSS, etc.), which are more resilient against cryptographic attacks than older standards.
- Advanced Key Derivation: The inclusion of the HMAC-based Key Derivation Function (HKDF) and specific TLS and NSS mechanisms allows applications to offload their entire TLS key schedule to a FIPS-certified boundary.
- Comprehensive Algorithm Support: A full suite of SHA-2 and SHA-3 hashing algorithms, along with advanced AES capabilities like CKM_AES_KEY_WRAP_PAD for secure key management, ensures broad compatibility and robust security.
In addition to new mechanisms, the 8 new API functions provide developers with advanced control for sophisticated applications. Functions like C_GetOperationState and C_SetOperationState allow for saving and restoring the progress of cryptographic operations, which is critical for resilience in embedded systems. Others, like C_VerifyRecover, add support for specialized signature schemes, ensuring comprehensive standards compliance.
Quality, Reliability, and Getting Started
This release is reinforced by significant under-the-hood improvements. A new –enable-nss compile-time option streamlines integration, and our vastly improved CI pipeline now includes extensive regression testing against the NSS suite, static analysis, and dynamic sanitizers to guarantee stability. We’ve also included numerous fixes for TPM users and improved the handling of object attributes for greater security and reliability.
The latest updates transform wolfPKCS11 into a fully-featured, highly reliable, and FIPS-capable PKCS#11 implementation. It is now uniquely positioned to bring the industry-leading performance and certified security of wolfCrypt to the entire ecosystem of applications built on NSS.
Developers are encouraged to explore these powerful new features, which are available now on the master branch of the official wolfPKCS11 GitHub repository. For hands-on examples of how to use wolfPKCS11 with NSS, please see our dedicated examples repository.
For any technical questions, please reach out to us at support@wolfssl.com. For inquiries related to FIPS 140-3 validation, commercial licensing, or questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
Meet wolfSSL at Black Hat USA 2025
Join wolfSSL at Black Hat USA 2025 – August 6–7 in Las Vegas, Nevada!
Visit us at Booth #2561 to explore high-performance cryptographic solutions trusted in embedded, enterprise, and cloud systems.
As a leader in cryptography and protocols, wolfSSL delivers the most tested, most portable, and standards-compliant cryptography, securing over 5 billion connections across RTOS, embedded, and traditional platforms.
What You’ll See at Black Hat
- wolfCrypt FIPS 140-3: Certified encryption for regulated industries, securing data at rest and in transit.
- Post-Quantum Cryptography (PQC): CNSA 2.0-ready support for ML-KEM, ML-DSA, LMS, and XMSS. FIPS 140-3 PQC certificate in process.
- (D)TLS 1.3 Library: Up to 20x smaller than OpenSSL with full compatibility and simple API—perfect for constrained systems.
- Hardware Security Module (HSM) Integration: Solutions for seamless integration with enterprise HSMs, ensuring secure key storage and cryptographic operations.
- wolfBoot Secure Boot: Authenticated firmware updates and trusted execution, including support for automotive-grade HSMs.
Use code WOLFSSL to redeem:
Stop by Booth #2561 and see why leading organizations trust wolfSSL for certified, future-ready cryptography.
Contact us today to schedule a meeting with wolfSSL Team!
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
ML-KEM Versus HQC KEM
ML-KEM (Module-Lattice Key Encapsulation Mechanism) and HQC (Hamming Quasi-Cyclic) are both post-quantum cryptographic key encapsulation mechanisms (KEMs) designed to provide secure key exchange in the presence of CRQCs (Cryptographically Relevant Quantum Computers).
ML-KEM is based on the (M-LWE) Module Learning With Errors problem, which involves finding a short vector between two points in a high dimensional vector-space with special points called a lattice. HQC is based on the hardness of decoding random quasi-cyclic codes. This means matrices with columns that are shifts of the first column with some modifications. These domains of mathematics are both considered to be well studied in our modern times.
In terms of numbers, ML-KEM has smaller key sizes and ciphertext sizes when compared to HQC at the same security levels. ML-KEM is generally faster than HQC for all the KEM operations (key generation, encapsulation, decapsulation).
In terms of the status of the algorithms, ML-KEM has already been standardized by NIST, and code points for TLS 1.3 are already in draft standards at the IETF. HQC was recently picked for standardization by NIST, but NIST has yet to issue a FIPS document specifying and standardizing it.
wolfSSL’s perspective is that you should start your post-quantum migration journey today and use algorithms that are already standardized such as ML-KEM. That said, if anyone out there wants to take HQC for a spin, please let us know!! As always, wolfSSL is a customer driven organization and when we hear enough interest, we will make it happen!
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
Coming soon: HQC KEM
Hello there! You! We know you are out there. You learned about Hamming codes in college or university, and maybe even use them in your professional career in consumer electronics or telecommunications. Now you are wondering how simple error correcting codes can be transformed into a KEM (Key Encapsulation Mechanism) for doing secure key transport. To you, we present the quantum-safe HQC (Hamming Quasi-Cyclic) KEM.
Are you hoping to see a professional production level implementation of HQC KEM? You are in luck. We want to make one! Make sure to register your interest in a wolfCrypt implementation of HQC KEM by sending a feature request for it to facts@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
Live Webinar: Everything You Need to Know About Automotive Cybersecurity
Strengthen your vehicle’s defenses with proven cybersecurity solutions.
Join us on July 23 at 9 AM PT for a live automotive cybersecurity webinar, “Everything You Need to Know About Automotive Cybersecurity,” presented by Senior Software Engineer Eric Blankenhorn. This session explores the growing need for secure, connected, and software-defined vehicles. You’ll learn about wolfSSL’s approach to automotive cybersecurity, backed by real-world examples and practical integration strategies.
Register Now: Everything You Need to Know About Automotive Cybersecurity
Date: July 23 | 9 AM PT
wolfSSL is a trusted provider of automotive-grade cybersecurity used by leading OEMs and Tier 1 suppliers. A key focus of this webinar is wolfHSM, our Hardware Security Module framework. Designed to support automotive-grade requirements, including AUTOSAR, PKCS11, and SHE, wolfHSM enables secure key storage, cryptographic operations, and secure boot, all while meeting the strict performance and safety demands of embedded automotive systems.
This webinar will cover:
- How wolfSSL supports modern automotive cybersecurity across global markets
- What sets wolfHSM apart, and why it’s ideal for embedded applications
- Best practices for implementing secure firmware updates in vehicles
- How TLS 1.3 enables safe communication from the vehicle to the cloud
- Approaches to securing ADAS and autonomous driving systems
- Real-world guidance on running TLS over CAN
- How wolfSSL ensures the highest code quality through industry-leading test coverage and validation
Register now to gain practical insights into securing next-generation automotive systems with wolfSSL!
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 +1 425 245 8247.
Download wolfSSL Now
ML-KEM Versus ML-DSA
ML-KEM (Module Lattice Key Encapsulation Mechanism) is for secure key exchange. ML-KEM enables two parties to establish a shared secret key over an insecure channel.
ML-DSA (Module Lattice Digital Signature Algorithm) is for authentication. ML-DSA allows a signer to generate a digital signature that can be verified by others, ensuring the authenticity and integrity of a message.
Both ML-KEM and ML-DSA are public key algorithms; that is to say, both have a key generation operation that generates a public key and private key.
For ML-KEM, an encapsulation operation uses the public key to generate a secret and ciphertext. The decapsulation operation uses the private key and ciphertext to get the same secret.
For ML-DSA, the private key and a message are used to generate a signature. The public key, message, and signature are used in an operation to verify that the signature of the message was generated by the corresponding private key.
The most important thing they have in common is that they are both post-quantum algorithms that have already been standardized by NIST and can be used TODAY!
In summary, ML-KEM and ML-DSA serve different purposes in cryptography, with ML-KEM focused on secure key transport and ML-DSA focused on digital signatures and authentication, but both protecting against a CRQC (Cryptographically Relevant Quantum Computer).
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
Using ECH with curl and wolfSSL
The Server Name Indication (SNI) extension to TLS allows the client to specify the name of the server it is trying to connect to, which allows the server to select between multiple virtual servers and present the appropriate certificate for the connection. The client sends the server name as a part of a Client Hello message. This Client Hello data is transmitted before encryption is set up for the connection so it can be observed by a third party.
The Encrypted Client Hello (ECH) extension to TLS 1.3 allows the inner Client Hello message that a TLS client sends to be encrypted. This inner Client Hello contains the actual server to be reached, while the outer Client Hello uses a generic public name that could be the same for many servers hosted by a company, for example. ECH is a much newer extension and currently is not deployed on most servers.
curl and wolfSSL both include support for ECH.
Install wolfSSL
First, the wolfssl library must be installed with ECH support.
Download the wolfSSL release and install with:
$ ./configure --enable-ech --enable-curl $ make $ sudo make instal
Install curl
Next, curl must be built with wolfSSL support. Example if wolfSSL was installed to /usr/local (the default):
$ ./configure --enable-ech --with-wolfssl=/usr/local $ make $ sudo make install
Enabling ECH
The –ech argument to curl can be used to enable ECH. It accepts a few different values such as false to not use ECH (the default), true to attempt ECH but fall back to not using it if not available, and hard to force using ECH and fail if the server does not support it.
Additionally, the –doh-url option should be supplied to curl to provide a DNS-over-HTTPS URL to use for DNS lookup.
Example Use
curl –ech hard –doh-url
https://one.one.one.one/dns-query
https://defo.ie/ech-check.php
This example uses –ech hard which will cause curl to fail if ECH cannot be used. In the returned payload, these lines are observed:
<p>SSL_ECH_OUTER_SNI: cover.defo.ie <br /> SSL_ECH_INNER_SNI: defo.ie <br /> SSL_ECH_STATUS: success <img src="greentick-small.png" alt="good" /> <br /> </p>
If we capture the traffic with Wireshark, we observe the following:
In this capture, we can see that the outer Client Hello message uses an unencrypted public server name (in this case “cover.defo.ie“) while the inner Client Hello containing the actual server name we’re trying to reach is encrypted.
In contrast, if we capture without ECH being enabled, we see the following:
Here we see that the entire Client Hello is unencrypted and the SNI server name can be observed as “defo.ie“.
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
Trusted by Design: How wolfSSL and Dark Sky Technology Came Together
How wolfSSL and Dark Sky Technology Secure Embedded Systems
When defense systems run open-source code touched by foreign adversaries, it’s not just risky—it’s a national security threat. That’s why wolfSSL and Dark Sky Technology teamed up: to combine certifiable cryptography with provable trust.
wolfSSL builds the most trusted cryptography on the market. Our lightweight, FIPS 140-3 validated wolfCrypt library secures everything from satellites to submarines—where performance, footprint, and reliability are non-negotiable. We support secure boot, secure firmware updates, and full (D)TLS 1.3, all engineered to meet the toughest standards like DO-178C DAL A and CNSA 2.0.
Dark Sky Technology defends America’s most critical systems from hidden threats in open-source software. Their platform, Bulletproof Trust, gives defense contractors and government agencies confidence in the integrity of their code by analyzing every risk vector:
- Contributors (who touched it)
- Vulnerabilities (what’s exposed)
- Licenses (what’s legal)
- Maintainability, code quality, and hygiene (what’s operationally dangerous)
Why We Partnered
Trust needs proof. Dark Sky independently evaluated wolfSSL using their TrustScore engine. Results:
- 0 sanctioned contributors
- No license conflicts or IP landmines
- Clean, maintainable code
- No embedded secrets or repo risk
You can view our TrustScore and full transparency report here: Dark Sky TrustScore for wolfSSL.
Why It Matters
For defense, software trust is mandatory. You must know what your code does—and who touched it.
wolfSSL delivers certifiable crypto.
Dark Sky proves its provenance.
No guesswork. No compromise. Just trusted software—by design.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
802.1AE-MACsec with wolfCrypt
What is 802.1AE?
802.1AE (MACsec) is a network layer 2 protocol for protecting ethernet frames with encryption and authentication across ethernet links. It introduces a new MACsec ethernet frame format, which carries an additional security tag (SecTAG) field inserted between the ethernet header and payload, as well as an integrity check value (ICV) trailer field at the end.
MACsec is built on the Galois/Counter Mode (GCM) construction, and uses AES-GCM to encrypt and integrity check ethernet payloads. It also supports an integrity-only mode of operation, where payloads are sent cleartext and GMAC is used for the ICV. It should be noted there is no “encrypt-only” MACsec mode, as integrity checks and origin authentication are fundamental to its design and choice of AES-GCM/GMAC.
Hop-by-hop vs end-to-end
The network topology of MACsec is fundamentally different from that of TLS or IPsec. MACsec protects data “hop-by-hop” along individual ethernet links, and does not have a concept of larger scale “end-to-end” protection as is the case between IP addresses in IPsec, or between network sockets in TLS.
There are benefits to this narrower scope. By protecting data only along individual ethernet links, there is no need to manage connection or session state across an entire network, which means latency is low. Also, the hop-by-hop scope allows for incremental deployment of MACsec, and utilization of device hardware acceleration along individual links.
This difference in scope means that MACsec is purely complementary to TLS and IPsec, and typically will be used in layered topologies (IPsec over MACsec, TLS over MACsec, etc). Furthermore, 802.1AE specifies nothing about key management and establishing MACsec, and typically will rely on higher level constructions such as EAP over TLS for provisioning.
Because MACsec happens hop-by-hop along ethernet links, it is typically implemented at a lower level by specialized devices and drivers: e.g. MACsec PHY hardware, or in the linux kernel as a specialized MACsec network driver. These will utilize hardware acceleration, and will have the added benefit of isolating key material to the device or kernel. The linux kernel is an especially interesting case that we’ll consider next.
MACsec in the linux kernel with wolfCrypt
The kernel MACsec driver itself does not contain any cryptographic implementations. Instead, it utilizes the kernel crypto API to allocate transforms for performing AES-GCM and GMAC on ethernet payloads. The kernel crypto API functions similar to a provider framework: different kernel modules register their cryptographic drivers, which in turn are used by device drivers for e.g. filesystem and network encryption. This makes sense, as cryptography in kernel-space has a number of strong advantages over user-space.
wolfSSL’s kernel module now supports registering wolfCrypt algorithms in the kernel crypto API (e.g. they will become listed in /proc/crypto). This means when kernel device drivers allocate cryptographic transforms for e.g. encrypted filesystems, IPsec, or MACsec, they are getting wolfCrypt’s registered implementations! In the case of wolfCrypt FIPS, one now has a very simple recipe for getting FIPS crypto into the linux kernel.
There are interesting possibilities with this. One could hypothetically have triple-layered network protection (TLS over IPsec over MACsec), with each utilizing wolfCrypt FIPS at different OSI layers!
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
Benchmarking wolfCrypt on the Frontgrade Gaisler GR740: A Glimpse into Performance
In the context of the recent collaboration between wolfSSL and Frontgrade Gaisler, we are excited to share some benchmark results of the wolfCrypt library running on the Gaisler GR740-MINI board.
The GR740, designed as ESA’s Next Generation Microprocessor (NGMP), is a radiation-hardened System-on-Chip (SoC) featuring a quad-core fault-tolerant LEON4 SPARC V8 processor.
WolfSSL and Gaisler aim to enhance security solutions for space-grade applications, leveraging the robust capabilities of the GR740 processor and the cryptographic know-how of wolfSSL.
Benchmark for wolfCrypt running on Baremetal:
------------------------------------------------------------------------------
wolfSSL version 5.8.0
------------------------------------------------------------------------------
Math: Multi-Precision: Wolf(SP) word-size=32 bits=4096 sp_int.c
Single Precision: ecc 256 384 rsa/dh 2048 3072 4096 sp_c32.c small
wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
AES-128-CBC-enc 3 MiB took 1.003 seconds, 3.432 MiB/s
AES-128-CBC-dec 3 MiB took 1.002 seconds, 3.411 MiB/s
AES-192-CBC-enc 3 MiB took 1.007 seconds, 2.958 MiB/s
AES-192-CBC-dec 3 MiB took 1.005 seconds, 2.940 MiB/s
AES-256-CBC-enc 3 MiB took 1.005 seconds, 2.601 MiB/s
AES-256-CBC-dec 3 MiB took 1.001 seconds, 2.585 MiB/s
AES-128-GCM-enc 475 KiB took 1.014 seconds, 468.300 KiB/s
AES-128-GCM-dec 475 KiB took 1.015 seconds, 468.142 KiB/s
AES-192-GCM-enc 475 KiB took 1.036 seconds, 458.356 KiB/s
AES-192-GCM-dec 475 KiB took 1.037 seconds, 458.202 KiB/s
AES-256-GCM-enc 450 KiB took 1.003 seconds, 448.872 KiB/s
AES-256-GCM-dec 450 KiB took 1.003 seconds, 448.724 KiB/s
GMAC Table 4-bit 546 KiB took 1.001 seconds, 545.432 KiB/s
CHACHA 7 MiB took 1.002 seconds, 6.945 MiB/s
CHA-POLY 4 MiB took 1.000 seconds, 4.466 MiB/s
POLY1305 17 MiB took 1.001 seconds, 17.076 MiB/s
SHA 10 MiB took 1.002 seconds, 9.675 MiB/s
SHA-256 3 MiB took 1.003 seconds, 2.581 MiB/s
SHA3-224 2 MiB took 1.011 seconds, 1.907 MiB/s
SHA3-256 2 MiB took 1.003 seconds, 1.801 MiB/s
SHA3-384 1 MiB took 1.014 seconds, 1.397 MiB/s
SHA3-512 1 MiB took 1.021 seconds, 0.980 MiB/s
HMAC-SHA 10 MiB took 1.001 seconds, 9.585 MiB/s
HMAC-SHA256 3 MiB took 1.001 seconds, 2.561 MiB/s
RSA 2048 public 78 ops took 1.017 sec, avg 13.035 ms, 76.715 ops/sec
RSA 2048 private 2 ops took 1.480 sec, avg 739.794 ms, 1.352 ops/sec
DH 2048 key gen 4 ops took 1.283 sec, avg 320.709 ms, 3.118 ops/sec
DH 2048 agree 4 ops took 1.282 sec, avg 320.625 ms, 3.119 ops/sec
ECC [ SECP256R1] 256 key gen 18 ops took 1.028 sec, avg 57.084 ms, 17.518 ops/sec
ECDHE [ SECP256R1] 256 agree 18 ops took 1.025 sec, avg 56.947 ms, 17.560 ops/sec
ECDSA [ SECP256R1] 256 sign 16 ops took 1.010 sec, avg 63.136 ms, 15.839 ops/sec
ECDSA [ SECP256R1] 256 verify 10 ops took 1.145 sec, avg 114.465 ms, 8.736 ops/sec
Benchmark of wolfCrypt running in Linux Environment:
------------------------------------------------------------------------------
wolfSSL version 5.8.0
------------------------------------------------------------------------------
Math: Multi-Precision: Wolf(SP) word-size=32 bits=4096 sp_int.c
Single Precision: ecc 256 384 rsa/dh 2048 3072 4096 sp_c32.c small
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
AES-128-CBC-enc 5 MiB took 1.502 seconds, 3.330 MiB/s
AES-128-CBC-dec 5 MiB took 1.542 seconds, 3.242 MiB/s
AES-192-CBC-enc 5 MiB took 1.737 seconds, 2.879 MiB/s
AES-192-CBC-dec 5 MiB took 1.780 seconds, 2.810 MiB/s
AES-256-CBC-enc 5 MiB took 1.971 seconds, 2.536 MiB/s
AES-256-CBC-dec 5 MiB took 2.015 seconds, 2.481 MiB/s
AES-128-GCM-enc 5 MiB took 10.777 seconds, 0.464 MiB/s
AES-128-GCM-dec 5 MiB took 10.744 seconds, 0.465 MiB/s
AES-192-GCM-enc 5 MiB took 10.983 seconds, 0.455 MiB/s
AES-192-GCM-dec 5 MiB took 10.980 seconds, 0.455 MiB/s
AES-256-GCM-enc 5 MiB took 11.218 seconds, 0.446 MiB/s
AES-256-GCM-dec 5 MiB took 11.215 seconds, 0.446 MiB/s
GMAC Table 4-bit 1024 KiB took 1.863 seconds, 549.684 KiB/s
CHACHA 10 MiB took 1.483 seconds, 6.742 MiB/s
CHA-POLY 5 MiB took 1.031 seconds, 4.852 MiB/s
POLY1305 20 MiB took 1.158 seconds, 17.270 MiB/s
SHA 10 MiB took 1.063 seconds, 9.410 MiB/s
SHA-256 5 MiB took 1.494 seconds, 3.346 MiB/s
SHA3-224 5 MiB took 2.609 seconds, 1.917 MiB/s
SHA3-256 5 MiB took 2.757 seconds, 1.814 MiB/s
SHA3-384 5 MiB took 3.578 seconds, 1.398 MiB/s
SHA3-512 5 MiB took 5.126 seconds, 0.975 MiB/s
HMAC-SHA 10 MiB took 1.062 seconds, 9.412 MiB/s
HMAC-SHA256 5 MiB took 1.494 seconds, 3.346 MiB/s
RSA 2048 public 100 ops took 1.309 sec, avg 13.094 ms, 76.373 ops/sec
RSA 2048 private 100 ops took 74.411 sec, avg 744.114 ms, 1.344 ops/sec
DH 2048 key gen 4 ops took 1.291 sec, avg 322.812 ms, 3.098 ops/sec
DH 2048 agree 100 ops took 32.274 sec, avg 322.741 ms, 3.098 ops/sec
ECC [ SECP256R1] 256 key gen 100 ops took 5.748 sec, avg 57.484 ms, 17.396 ops/sec
ECDHE [ SECP256R1] 256 agree 100 ops took 5.737 sec, avg 57.371 ms, 17.431 ops/sec
ECDSA [ SECP256R1] 256 sign 100 ops took 6.360 sec, avg 63.599 ms, 15.723 ops/sec
ECDSA [ SECP256R1] 256 verify 100 ops took 11.532 sec, avg 115.318 ms, 8.672 ops/sec
These results underscore the potential of integrating wolfSSL’s cryptographic solutions with Gaisler’s advanced hardware, paving the way for secure high-performance cryptography that comply with latest industry standards, including DO-178C Level A, FIPS 140-3 and MISRA-C.
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