Live Webinar: World’s first SP800-140Br1 FIPS 140-3 validated certificate #4718
We are thrilled to announce a landmark achievement in cybersecurity! wolfSSL has obtained the world’s first SP800-140Br1 FIPS 140-3 validated certificate #4718. This milestone is a testament to our commitment to providing top-notch security solutions. To celebrate, wolfSSL Senior Software Engineer, Kaleb Himes, is hosting an exciting webinar, “World’s first SP800-140Br1 FIPS 140-3 validated certificate #4718”, on July 18th at 10am PT!
Register today for “World’s first SP800-140Br1 FIPS 140-3 validated certificate #4718”
This Webinar Will Cover:
- World’s first SP800-140Br1 FIPS 140-3 validated certificate #4718: Understand the significance of this groundbreaking achievement.
- OpenSSL compatibility: Learn about the integration and benefits of our solutions with OpenSSL, including Provider and Engine support.
- Java JSSE/JCE provider: Discover how our FIPS-validated solutions work seamlessly with Java security frameworks.
- Commercial FIPS offering: Explore the only embedded general-purpose commercial FIPS solution available in the market.
- Expert Team: Connect with industry experts at wolfSSL who make all this possible. We are here to help you navigate the complexities of FIPS certification and implementation.
Don’t miss out on this opportunity to be a part of cybersecurity history. Kaleb will provide valuable insights, practical knowledge, and a chance to interact with industry experts. Register now and secure your spot in this exciting event.
As always, our webinars include Q&A sessions. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
wolfSSL 5.7.2 Now Available!
wolfSSL release 5.7.2 is now available! This release includes an implementation of Dilithium, optimizations for RISC-V use, AES-XTS streaming capabilities, and quantum safe algorithm support with the Linux kernel module, to name a few of the recent additions. There have also been other enhancements, such as STM32 AES hardware support for STM32H5 and SHA-3 ARM thumb assembly implementations. Along with these amazing features and enhancements, some great fixes and additional sanity checks were added. One of the additional sanity checks limits the maximum number of alternate names parsed with certificates. This defaults to 128 but can be changed by defining the macro WOLFSSL_MAX_ALT_NAMES to any desired value. A full list of vulnerability fixes, feature additions, and general changes can be found in the ChangeLog.md bundled with wolfSSL or in the main README.md.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
Integrating lwIP with wolfCrypt and IPSec
The lwIP project is a great, lightweight TCP/IP stack implementation, with widespread use in the embedded world. Users of lwIP and wolfSSL know that we have long supported an lwIP integration, which allows wolfSSL to handle the TLS layer while lwIP handles network input/output.
Similarly, we support a wolfSentry integration with lwIP, that allows wolfSentry to function as a dynamic firewall and IDPS for lwIP.
But what if you wanted to combine lwIP with IPSec? Furthermore, what if you wanted wolfCrypt to handle the IPSec cryptographic operations in such a combination?
If you’re curious about lwIP, wolfCrypt, and IPSec, or have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
wolfBoot 2.1.0 released
wolfBoot is our secure bootloader designed to provide safety-oriented secure boot for any embedded device. Its success lies in its ability to offer security, efficiency and adaptability to many different use cases, while keeping a simple and safe design. wolfBoot is a solid choice made by many developers securing the boot mechanism on a wide range of embedded devices from every industry.
A new version of wolfBoot (v2.1.0) has been released, which introduces new features, support for more cryptography, ports to new embedded targets and improvements to existing code.
Download wofBoot 2.1.0 from our download page or clone it from github.
Support for custom fields in the manifest header
One of the most requested features by our users consisted in allowing extra parameters in the manifest header of the firmware/software images to be verified.
wolfBoot manifest header consists in a sequence of “TLV” (table-length-value) fields. By default, a signed image’s manifest header contains a SHA digest, the public-key signature itself, and a few extra fields containing metadata relative to the image and the sign process. These fields include a 32-bit version number (used to prevent rollback attacks), a 64-bit timestamp, a digest of the public key needed to verify the signature, a ‘type’ field, used by the bootloader to identify and confirm the algorithms used and the destination partition for the update.
All these fields in the manifest headers, except for the digest and the signature itself, are included in the calculation of the signed digest, which means that their values cannot be altered without compromising the validity of the signature.
The new feature introduced in wolfBoot 2.1.0 consists in three new mechanism that can be used to add new TLVs to the header:
- –custom-tlv tag len val
Adds a TLV entry to the manifest header, corresponding to the type identified by “tag”, with length “len“ bytes, and assigns the value “val”.Values can be decimal or hex numbers (prefixed by ‘0x’). This is useful to add numeric values (e.g. with length 1, 2, 4, or 8). - –custom-tlv-buffer tag len buffer
Adds a TLV entry with a buffer in hex format,
e.g. –custom-tlv-buffer 0x31 6 CCBBAA998877 - –custom-tlv tag string
Adds a TLV containing a string of bytes read as ASCII characters from the “string” argument. In this case the length is implicit as the argument is null-terminated.
As usual, these fields can be accessed from wolfBoot custom modules, using the wolfBoot_find_header() parser. This function is included in libwolfboot, which means that the same parser can be invoked on any stored signed image by applications integrating the library.
New signature verification algorithm
ECC521 support has been added, further expanding the range of cryptographic algorithms available for signature verification, bolstering security for a broader spectrum of applications (and did you know that since v2.0 wolfBoot also supports post-quantum signature verification algorithms too?).
Support for new embedded platforms
We facilitate the process to integrate new ports of wolfBoot, which includes the integration of an example application to demonstrate secure boot and update out-of-the-box, with a single build command. This version introduces support for new embedded targets:
- Renesas RZ2NL
- Microchip SAM E51
- NXP MCXA-153
- NXP i.MX-RT1040
Improvements and enhancements
Version 2.1.0 addresses various bugs and introduces enhancements for existing platforms and target-specific mechanisms.
For targets supporting the DUALBANK option, i.e. the ability to swap the mapping of two “banks” inside the same flash memory support, we added some additional checks to ensure that wolfBoot copies (or “forks”) itself to the second bank only once in the lifetime of the bootloader.
For those use-cases with backup disabled, we have simplified the update mechanism, which also improved the reliability of the update across power-failures.
We have fixed an issue in the wolfTPM integration code, which was preventing the policy from being properly sealed. This issue is only affecting those configurations including the `WOLFBOOT_TPM_SEAL` option introduced in version 2.0.0.
Contacts Us
Let us know what features you value the most, what platforms you would like to see our code running on, or just tell us your story about secure-boot in your embedded systems.
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
Don’t Miss Out: wolfBoot security on the STM32H5 with PQC Webinar
Learn about the advanced security features of the STM32H5 microcontroller and how wolfBoot enhances these capabilities, including support for Post Quantum Cryptography.
Register today for “wolfBoot security on the STM32H5 with PQC.”
Date: July 10th | 9 am PT
wolfSSL is excited to announce that wolfBoot, our secure bootloader, now supports the STM32H5 microcontroller series. This integration brings robust secure boot features and efficient update mechanisms to the STM32H5, following RFC9019 guidelines for a reliable secure boot solution.
The STM32H5 series excels within the STM32 family with superior performance and security. Built around the Arm Cortex-M33 core, it provides a notable boost in computational power and efficiency. Featuring TrustZone-M technology, it offers hardware-assisted isolation between secure and non-secure domains, enhancing security and simplifying secure application development. The series includes up to 2 MB of flash memory and 640 KB of SRAM, ideal for complex applications. Its dual-bank flash architecture enables quick firmware updates. Equipped with advanced cryptographic accelerators and a cryptographic-grade TRNG, the STM32H5 series is perfect for secure, high-performance embedded applications.
wolfBoot extends its support within the STM32 family by including target-specific security features offered by the STM32H5 series. Explore these features and their role in a system secured using wolfBoot, wolfCrypt, and wolfPKCS11.
During this webinar, attendees will learn about:
- STM32H5 Security Features
- wolfBoot Secure Boot Solution
- TrustZone with PKCS11
- Post Quantum Cryptography
- Dual Bank Swap, OTP for RoT, HW TRNG
- Live Demonstration
As always, our webinar includes 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
Dilithium vs. Falcon
Recently, more and more attention has been focused on post-quantum key encapsulation mechanism (KEM) algorithms due to the “Harvest Now, Decrypt Later” threat model. But we here at wolfSSL know that post-quantum signature schemes also deserve a lot of attention as there is a tendency for signing keys to have long lifetimes. As such, today we’d like to delve a bit deeper by comparing Dilithium (also known as ML-DSA) and Falcon (also known as NL-DSA); 2 signature schemes slated for standardization.
Both algorithms are based on lattice-based cryptography and depend on the hardness of finding short vectors in a lattice. The difference is that Dilithium uses module vector spaces while Falcon uses NTRU lattices. The math gets very complicated very quickly; please see the webpage for the algorithms for further details:
Implementing them is very different. For example, Dilithium can be implemented with only integer arithmetic whereas falcon requires floating point arithmetic. This difference in difficulty has resulted in a delay in Falcon’s standardization process. While Dilithium is slated for standardization in the summer of 2024, the draft standard for Falcon hasn’t even been published yet as NIST wants to be very cautious writing it.
Finally, the cryptographic artifact sizes are significantly different.
| Dilithium-2 | Falcon-1 | Dilithium-3 | Dilithium-5 | Falcon-5 | |
|---|---|---|---|---|---|
| Private Key | 2528 | 1281 | 4000 | 4864 | 2305 |
| Public Key | 1312 | 897 | 1952 | 2592 | 1793 |
| Signature | 2420 | 752 | 3293 | 4595 | 1462 |
Note that the units listed here are in bytes and the number after the algorithm name on the top row denotes the claimed security levels.
As you can see, Falcon’s artifact sizes are all smaller than Dilithium’s, but are still fairly large compared to ECDSA artifacts. This is why we suggest our customers get started early integrating these algorithms into their systems. You need to know how these larger artifact sizes are going to affect data transmission times and network throughput. How with this cascade into user experience and resource requirements?
Get started by having a conversation with us! If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfBoot on STM32H5: Enhancing secure boot with TrustZone-M
WolfSSL is excited to announce that WolfBoot, our secure bootloader, now supports the STM32H5 microcontroller series. This new integration brings robust secure boot features and efficient update mechanisms to the STM32H5, following the guidelines of RFC9019 for a safe and reliable secure boot solution.
wolfBoot already offers several unique features compared to the SBSFU expansion for STM32Cube, or other open-source secure bootloaders designed uniquely for microcontrollers, like mcuboot.
This includes:
-
A wider selection of cryptographic algorithms for signature verification to choose from
(RSA, ECC, ed25519, ed448). including a few recently added post-quantum algorithms (LMS, XMSS) -
FIPS 140-2 and FIPS 140-3 certified cryptographic engine
-
Support for bootloader’s self-updates
-
Customizable trust anchor storage, as the keystore containing the public keys can be placed virtually anywhere in the system
-
Support for a large number of secure elements including full support for TPM to implement measured boot
-
Multiple keys allowed to authenticate different components in multiple partitions through a partition access control bitmask
-
The possibility of receiving incremental binary patches to perform delta updates
-
A safety-oriented design, facilitating safety certifications such as ASIL or DO-178C
-
Independence from the update transport mechanism, allowing remote updates over any channel or protocol
-
Flexible and portable keytools command line applications, easy to integrate with any provisioning strategy including third party signing actors and continuous deployment
-
A solid and proven set of countermeasures against specific attacks targeting secure boot mechanisms, such as fault injections and glitch attacks inducing instruction skipping
The STM32H5 series stands out within the STM32 family for its advanced performance and security features. These microcontrollers are built around the Arm Cortex-M33 core, which offers a significant boost in computational power and efficiency compared to previous generations. The STM32H5 series integrates TrustZone-M technology, providing hardware-assisted isolation between secure and non-secure executing domains, which enhances security and simplifies the development of secure applications. The STM32H5 series also offer extensive memory options, with up to 2 MB of flash memory and 640 KB of SRAM, supporting complex and memory-intensive applications. The dual-bank flash memory architecture allows for instant firmware updates by swapping the logical mapping of the two banks. Its advanced cryptographic hardware accelerators, cryptographic grade TRNG complete the picture, making the STM32H5 series an excellent choice for high-performance and secure embedded applications.
wolfBoot extends its support within the STM32 family by including some target-specific security features offered by the STM32H5 series. Let’s explore these features and their role in a system secured using wolfBoot, wolfCrypt and wolfPKCS11.
Secure boot and public key storage in OTP FLASH
The main requirement to secure the boot process consists in a so-called “trust anchor”. RFC6024 specifies the requirements for the management and the storage of the anchor, which must be immutable and immune to tampering, suggesting the use of hardware assisted mechanisms to provide strong protection against tampering and unauthorized access.
STM32H5 provides 2KB of OTP FLASH memory that meets the requirements to properly store the trust anchor. Once the keys are provisioned, the OTP FLASH memory cannot be erased, and can also be explicitly protected against further write access. wolfBoot uses the OTP memory to store the “keystore” structure containing the trust anchors. During the boot process, wolfBoot verifies the firmware’s authenticity against the stored trust anchors. By storing these anchors in OTP memory, wolfBoot ensures that the verification process is based on a reliable and tamper-proof reference.
Once provisioned, the OTP FLASH memory is available for read-only access on STM32H5 at address 0x08FFF000 : 0x08FFF7FF. The memory can be accessed in read-only mode also from the application so the same trust anchors can be also reused for other purposes.
Firmware update via dual bank swapping
STM32H5 FLASH is organized in two banks of the same size, mapped at 0x08000000 and 0x08100000 in non-secure mode and at 0x0C000000 and 0x0C100000 in secure mode. The microcontroller exposes one bit in the configuration registers to swap the mapping of the two banks in the bootloader stage. This feature ensures that the updated firmware can be installed instantly to match its hardcoded boot address. In the example configuration provided in the repository, wolfBoot reserves 256KB of FLASH memory on both banks for the bootloader code and the secure supervisor, so the boot partition has a fixed address after 0x08040000.
Support for TrustZone-M: wolfCrypt in secure world
TrustZone creates a secure execution environment, separating secure and non-secure code. wolfBoot uses this technology to implement a hypervisor that supports the PKCS#11 standard interface. This allows applications in the non-secure world to perform cryptographic operations without direct access to the cryptographic keys.
In this setup, wolfCrypt and wolfPKCS11 run as the cryptographic engine within the secure domain. The PKCS#11 interface provides a standardized API for cryptographic operations, ensuring that sensitive keys remain protected within the secure world. Applications can thus perform necessary cryptographic tasks while keeping the keys and secrets hidden from non-secure code, enhancing overall security.
wolfBoot configures the Global TrustZone Controller (GTZC) and the Security Attribution Unit (SAU) to separate the FLASH and the RAM available on the system into the two TrustZone domains. The lower half of the total RAM available is reserved for the cryptographic engine to store secret keys and other sensitive data that must not be accessible from the applications, while the upper 320KB are available for the other tasks executing in the non-secure domain.
Each Bank on FLASH memory is divided into secure and non-secure areas. After verifying the integrity and the authenticity of the selected firmware image and swapping the banks accordingly, the selected application or RTOS is executed in the non-secure domain. This basically means that the executing software has limited access to the resources available on the system, including FLASH.
Software running in the non-secure domain cannot access secrets contained in the key vault, which are in the secure-domain portion of the FLASH. Instead, an application will unlock the vault then call TrustZone Non-Secure Callable (NSC) functions through its PKCS11 standard interface, which will then use those secret keys. Each key is referred to as a slot number in the vault. wolfBoot reserves the necessary space to contain the implementation of those PKCS11 API functions in a specific area, marked as NSC in the SAU.
Support for TrustZone-M: wolfCrypt in secure world
The integration of WolfBoot with STM32H5 significantly enhances the security and reliability of an embedded system based on this series. By leveraging TrustZone technology for secure cryptographic operations, utilizing OTP memory for tamper-resistant key storage, and implementing dual bank swapping for seamless firmware updates, wolfBoot provides a robust and efficient, ready to use secure boot solution.
In addition to these features, WolfBoot offers unique capabilities such as support for post-quantum cryptographic (PQC) authentication methods like LMS and XMSS, and protection against glitching attacks, further enhancing its security profile. These features make wolfBoot an ideal choice for developers seeking a secure and reliable bootloader solution for their STM32H5-based projects.
Do you want to know more about secure boot and embedded security? Let’s talk! Send us an email to facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Top 5 Build Options To Improve wolfCrypt/wolfSSL Performance
The wolfSSL embedded TLS library and its crypto engine wolfCrypt are both highly configurable to give users the best cryptographic performance. Our users appreciate that they’re able to customize their builds to suit their specific needs. If your needs are a crypto or SSL/TLS solution optimized for performance, we’ve compiled a list of the top 5 wolfSSL build options that you should consider.
Intel Assembly
For use with Intel/AMD processors, enabling the intelasm option for wolfSSL will utilize enhanced assembly instructions of the processor that can dramatically enhance cryptographic performance for most algorithms. The instruction sets leveraged when the configure option is enabled include AVX1, AVX2, BMI2, RDRAND, RDSEED, AESNI, and ADX. This option also automatically enables our Intel AES-NI support, which on its own can lead to direct AES encryption that’s over 3.3 times faster than using software-based AES. Performance increases in total can be as large as 5,800% when intelasm is used.
Enabled with: ./configure –enable-intelasm
Macro: WOLFSSL_ARMASM
ARM Assembly
Whether you’re doing cryptography on an ARMv8, ARMv7 or even an ARM64, armasm is the quickest way to speedup your cryptographic operations, and by doing so speedup your TLS that makes use of these algorithms. By using the cryptographic instructions built into the chips, we get a significant boost in performance over straight C. We recently did another round of tuning on our ARM64 code and got the crypto running up to 9.5 times faster than it already was.
Enabled with: ./configure –enable-armasm
Macro: WOLFSSL_ARMASM
RISC-V Assembly
The newest addition on this list, wolfSSL now has support for RISC-V hardware acceleration. The RISC-V assembly implementation of AES includes standard/scalar cryptography/vector cryptographic instructions for ECB/CBC/CTR/GCM/CCM and can be up to 50 times faster than the software implementation.
Enabled with: ./configure –enable-riscv-asm
Macro: WOLFSSL_RISCV_ASM
Single Precision Math Assembly
Unlike some of the other build options on this list, SP ASM is hardware agnostic. SP is Single Precision Math and it is a wolfSSL developed math library that is extremely well optimized for cryptographic math calculations. SP ASM is the assembly component of the SP math library. Enabling this option leads to faster RSA, ECC and DH operations.
Enabled with: ./configure –enable-sp –enable-sp-asm
Macros: WOLFSSL_SP_ASM (along with WOLFSSL_SP_HAVE_RSA/ECC/DH)
AES GCM (4-bit Table)
A hardware agnostic feature for AES GCM (authenticated cipher) to improve the symmetric performance of the GHASH authentication calculation. The performance gain is about a 3x speedup.
Enabled with: ./configure –enable-asmgcm=4bit
Macros: WOLFSSL_SP_ASM (along with WOLFSSL_SP_HAVE_RSA/ECC/DH)
For more information on the wolfSSL library and its performance, please visit our benchmarks page or contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
Partner Webinar: wolfBoot security on the STM32H5 with PQC
Learn about the advanced security features of the STM32H5 microcontroller and how wolfBoot enhances these capabilities, including support for Post Quantum Cryptography.
Register today for “wolfBoot security on the STM32H5 with PQC.”
Date: July 10th | 9 am PT
wolfSSL is excited to announce that wolfBoot, our secure bootloader, now supports the STM32H5 microcontroller series. This integration brings robust secure boot features and efficient update mechanisms to the STM32H5, following RFC9019 guidelines for a reliable secure boot solution.
The STM32H5 series excels within the STM32 family with superior performance and security. Built around the Arm Cortex-M33 core, it provides a notable boost in computational power and efficiency. Featuring TrustZone-M technology, it offers hardware-assisted isolation between secure and non-secure domains, enhancing security and simplifying secure application development. The series includes up to 2 MB of flash memory and 640 KB of SRAM, ideal for complex applications. Its dual-bank flash architecture enables quick firmware updates. Equipped with advanced cryptographic accelerators and a cryptographic-grade TRNG, the STM32H5 series is perfect for secure, high-performance embedded applications.
wolfBoot extends its support within the STM32 family by including target-specific security features offered by the STM32H5 series. Explore these features and their role in a system secured using wolfBoot, wolfCrypt, and wolfPKCS11.
During this webinar, attendees will learn about:
- STM32H5 Security Features
- wolfBoot Secure Boot Solution
- TrustZone with PKCS11
- Post Quantum Cryptography
- Dual Bank Swap, OTP for RoT, HW TRNG
- Live Demonstration
As always, our webinar includes 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
wolfSSL on RISC-V Benchmarks (HiFive Unleashed)
We are excited to share the latest benchmark results of wolfSSL v5.7.0 running on the HiFive Unleashed at 1.4GHz. We implemented AES for ECB, CBC, CTR, GCM, and CCM using assembly for RISC-V. This benchmark demonstrates the performance capabilities of wolfSSL on RISC-V architecture, highlighting our commitment to providing high-performance, lightweight, and secure SSL/TLS solutions across diverse platforms.
The benchmark results prove that the new assembly optimizations are much faster.
With RISC-V assembly optimizations:
./configure --enable-riscv-asm && make root@HiFiveU:~/wolfssl-riscv# ./wolfcrypt/benchmark/benchmark -aes-cbc -aes-gcm------------------------------------------------------------------------------ wolfSSL version 5.7.0 ------------------------------------------------------------------------------ Math: Multi-Precision: Wolf(SP) word-size=64 bits=3072 sp_int.c wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) AES-128-CBC-enc 20 MiB took 1.076 seconds, 18.588 MiB/s AES-128-CBC-dec 20 MiB took 1.083 seconds, 18.473 MiB/s AES-192-CBC-enc 20 MiB took 1.245 seconds, 16.062 MiB/s AES-192-CBC-dec 20 MiB took 1.246 seconds, 16.047 MiB/s AES-256-CBC-enc 15 MiB took 1.057 seconds, 14.189 MiB/s AES-256-CBC-dec 15 MiB took 1.055 seconds, 14.212 MiB/s AES-128-GCM-enc 15 MiB took 1.300 seconds, 11.543 MiB/s AES-128-GCM-dec 15 MiB took 1.300 seconds, 11.535 MiB/s AES-192-GCM-enc 15 MiB took 1.425 seconds, 10.526 MiB/s AES-192-GCM-dec 15 MiB took 1.425 seconds, 10.523 MiB/s AES-256-GCM-enc 10 MiB took 1.032 seconds, 9.687 MiB/s AES-256-GCM-dec 10 MiB took 1.032 seconds, 9.691 MiB/s GMAC Table 4-bit 31 MiB took 1.025 seconds, 30.251 MiB/s Benchmark complete
Without RISC-V assembly optimizations:
./configure —enable-all && make root@HiFiveU:~/wolfssl# ./wolfcrypt/benchmark/benchmark -aes-cbc -aes-gcm ------------------------------------------------------------------------------ wolfSSL version 5.7.0 ------------------------------------------------------------------------------ Math: Multi-Precision: Wolf(SP) word-size=64 bits=4096 sp_int.c wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) AES-128-CBC-enc 5 MiB took 12.798 seconds, 0.391 MiB/s AES-128-CBC-dec 5 MiB took 12.672 seconds, 0.395 MiB/s AES-192-CBC-enc 5 MiB took 15.301 seconds, 0.327 MiB/s AES-192-CBC-dec 5 MiB took 15.181 seconds, 0.329 MiB/s AES-256-CBC-enc 5 MiB took 17.820 seconds, 0.281 MiB/s AES-256-CBC-dec 5 MiB took 17.669 seconds, 0.283 MiB/s AES-128-GCM-enc 5 MiB took 12.870 seconds, 0.388 MiB/s AES-128-GCM-dec 5 MiB took 12.870 seconds, 0.388 MiB/s AES-192-GCM-enc 5 MiB took 15.375 seconds, 0.325 MiB/s AES-192-GCM-dec 5 MiB took 15.376 seconds, 0.325 MiB/s AES-256-GCM-enc 5 MiB took 17.878 seconds, 0.280 MiB/s AES-256-GCM-dec 5 MiB took 17.896 seconds, 0.279 MiB/s AES-128-GCM-STREAM-enc 5 MiB took 12.878 seconds, 0.388 MiB/s AES-128-GCM-STREAM-dec 5 MiB took 12.878 seconds, 0.388 MiB/s AES-192-GCM-STREAM-enc 5 MiB took 15.379 seconds, 0.325 MiB/s AES-192-GCM-STREAM-dec 5 MiB took 15.385 seconds, 0.325 MiB/s AES-256-GCM-STREAM-enc 5 MiB took 17.881 seconds, 0.280 MiB/s AES-256-GCM-STREAM-dec 5 MiB took 17.888 seconds, 0.280 MiB/s GMAC Table 4-bit 30 MiB took 1.006 seconds, 29.831 MiB/s Benchmark complete
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now