Post-Quantum Kyber Benchmarks (MacOS)
You may be aware that wolfSSL has our own implementation of NIST’s ML-KEM, also known as Kyber. ML-KEM is the post-quantum KEM that is slated for standardization by NIST. While the standard is not complete yet, and we have not yet released our implementation into open source, we do have some benchmarking results to share.
Additionally, we should note some things about our implementation that make it unique and useful:
- It will be fully integrated with our other products, including wolfSSL, wolfBoot, curl, etc.
- It is a consumer of our highly optimized SP Math library, with more ML-KEM optimizations to come!
- Because our products are well integrated with many other open source packages, those packages can inherit Kyber/ML-KEM support.
- It supports bare metal, as well as all of the other operating systems we support, including FreeRTOS, VxWorks, Integrity, Zephyr, Itron, LynxOS, etc.
- It also supports all of the silicon targets we support, including ARM, RISCV, DSPs, FPGAs, intel, etc.
The benchmarks results follow:
Math: Multi-Precision: Wolf(SP) no-dyn-stack word-size=64 bits=4096 sp_int.c Single Precision: ecc 256 384 521 rsa/dh 2048 3072 4096 asm sp_arm64.c wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) DH 2048 key gen 3997 ops took 1.000 sec, avg 0.250 ms, 3996.812 ops/sec DH 2048 agree 4100 ops took 1.001 sec, avg 0.244 ms, 4097.522 ops/sec KYBER512 128 key gen 96100 ops took 1.001 sec, avg 0.010 ms, 96037.765 ops/sec KYBER512 128 encap 78000 ops took 1.000 sec, avg 0.013 ms, 77970.220 ops/sec KYBER512 128 decap 58900 ops took 1.001 sec, avg 0.017 ms, 58867.158 ops/sec KYBER768 192 key gen 58200 ops took 1.000 sec, avg 0.017 ms, 58192.314 ops/sec KYBER768 192 encap 48700 ops took 1.001 sec, avg 0.021 ms, 48664.334 ops/sec KYBER768 192 decap 38100 ops took 1.001 sec, avg 0.026 ms, 38059.656 ops/sec KYBER1024 256 key gen 37800 ops took 1.003 sec, avg 0.027 ms, 37704.299 ops/sec KYBER1024 256 encap 32600 ops took 1.001 sec, avg 0.031 ms, 32566.427 ops/sec KYBER1024 256 decap 26000 ops took 1.001 sec, avg 0.039 ms, 25967.020 ops/sec ECC [ SECP256R1] 256 key gen 84100 ops took 1.001 sec, avg 0.012 ms, 84013.469 ops/sec ECDHE [ SECP256R1] 256 agree 24400 ops took 1.004 sec, avg 0.041 ms, 24300.995 ops/sec
The benchmarks were run on an Apple MacBook Pro 18,3 with an Apple M1 Pro, 3.09 GHz processor. Only 1 core was used. If you want to get the benchmark harness code, then ping us at facts@wolfSSL.com.
This data shows that for Kyber/ML-KEM, algorithm execution performance is rock solid. If you compare Kyber/ML-KEM’s numbers against DH and ECDHE, Kyber holds its own. To understand how to analyze and compare these number, see https://www.wolfssl.com/benchmarks-kyber-level-1-pqm4-integration-stm32-arm-cortex-m4/.
Interested in learning more about our post-quantum efforts? Want to understand how Kyber fits into different protocols and how it might affect your use case? Contact us at wolfSSL by emailing facts@wolfSSL.com or calling us at +1 425 245 8247 to reach out to your regional wolfSSL business director
Download wolfSSL Now
Live Webinar: DTLS 1.3 Training
Join us for an exclusive webinar “DTLS 1.3 Training”, scheduled for March 7th at 10am PT. Presented by wolfSSL Software Developer, Marco, this session is your gateway to mastering DTLS 1.3, a groundbreaking protocol adopted by wolfSSL.
As pioneers in TLS technology, wolfSSL is proud to stand as the first library to implement DTLS 1.3. Our webinar is the perfect opportunity to delve into what DTLS 1.3 entails and discover its real-world applications.
Watch the webinar now! : DTLS 1.3 Training
Sneak Peek of the Webinar:
- Dive into fundamental concepts of DTLS
- Discover enhancements in DTLS version 1.3
- Engage in hands-on exploration of DTLS in UDP applications using wolfSSL DTLS 1.3
Don’t miss out on this opportunity to deepen your understanding of DTLS and leverage the power of DTLS 1.3 with wolfSSL. Watch now!
As always, our webinars will include Q&A sessions 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
CPU-Accelerated Cryptography on OpenWRT Using wolfSSL
OpenWRT is a customizable open-source firmware for wireless routers and embedded devices, offering extensive flexibility and control over network configurations. For those looking to enhance their device’s security capabilities with efficient cryptographic operations, integrating wolfSSL with CPU acceleration presents an excellent option. This setup is optimized for devices compatible with x86 and armv8 architectures, ensuring enhanced performance where it matters most.
Setting Up wolfSSL with CPU Acceleration
When configuring OpenWRT, incorporating wolfSSL with CPU acceleration is straightforward.
- Initiate the Configuration Process: Begin with the make menuconfig command to open the OpenWRT configuration menu and select a compatible target device. This assumes you have already met all prerequisites, such as having the correct version of OpenWRT and necessary development tools installed on your system.
- Navigate to wolfSSL Options: From the top menu of the OpenWRT Configuration, make your way to wolfSSL by selecting Libraries → SSL. Here, you will encounter two options: libwolfssl and libwolfsslcpu-crypto. For CPU-accelerated cryptography, select libwolfsslcpu-crypto and ensure that libwolfssl is deselected (See Image). If you do not see libwolfsslcpu-crypto your target device may be incompatible or set up wrong in OpenWRT.
- Configure wolfSSL Library Settings: Proceed to the wolfSSL Library Configuration submenu to customize the options compatible with the libwolfsslcpu-crypto package.
- Save Your Configuration: This will make sure your OpenWRT build environment will compile with wolfSSL’s CPU-accelerated cryptography enabled, enhancing the performance capabilities of your device.
Why CPU Acceleration?
Leveraging CPU acceleration for cryptographic functions with wolfSSL not only improves encryption and decryption speeds but also optimizes processor load, making your device more efficient. To see the advantages of using your compatible device with wolfSSL’s CPU acceleration consider enabling the benchmark package seen in the figure above, and run it when you are in the final image for the device via a call on the command line for wolfssl-benchmark. Share your results with us on X @wolfSSL!
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: Migrating from OpenSSL to wolfSSL in 2024
Join us for an informative webinar “Migrating from OpenSSL to wolfSSL” led by wolfSSL Software Developer, Jacob, on February 29th at 10am PT. Jacob will guide you through the seamless transition from OpenSSL to wolfSSL, introducing the wolfCrypt FIPS 140-3 module to meet OpenSSL FIPS requirements, along with the revolutionary wolfEngine and wolfProvider technologies tailored to fulfill specific requirements for OpenSSL 1.x and 3.x.
Watch the webinar here: Migrating from OpenSSL to wolfSSL
Sneak Peek of the webinar:
- Exploring wolfSSL compatibility layer
- Implementing wolfSSL to replace OpenSSL
- Live demonstration of a simple application migration
- Showcasing major projects successfully migrated to wolfSSL
- Insights into the future of the compatibility layer
And much more!
This webinar offers a unique opportunity to discover how wolfSSL can unleash the full potential of your projects. Jacob will elaborate on leveraging wolfSSL products to seamlessly meet OpenSSL requirements, including FIPS compliance and compatibility with OpenSSL 1.x and 3.x. Don’t miss out on this chance to learn why migrating to wolfSSL is advantageous and how we can simplify your journey.
As always, our webinars will include Q&A sessions 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
Comparing wolfSSL vs OpenSSL
How does OpenSSL Compare with wolfSSL?
There are a lot of different metrics to compare when choosing between two TLS libraries. Some of those include heap usage and performance.
Heap Usage:
For heap usage wolfSSL can be significantly smaller — using 100’s of kilobytes less to handle an incoming TLS connection. The following is comparisons collected using a simple server example that was unaltered and linked against the two different TLS libraries. The same cipher suite ECDHE-RSA-AES256-GCM-SHA384 was used for all connections. The graphs were generated using Valgrinds massif tool.
OpenSSL 3.0.0 Used 800+Kb
OpenSSL 1.1.1 Used 200+ Kb
wolfSSL 5.2.0 Used 38.1 Kb
./configure –enable-opensslextra
wolfSSL 5.2.0 configured for a smaller build used 27.1 Kb
./configure –enable-opensslextra –enable-sp-math-all=small –enable-sp=small
Performance:
Both TLS implementations have assembly optimizations done for hardware commonly used in desktops. Such as Intel’s AVX or AESNI instructions and ARMv8’s crypto extensions. In many cases wolfSSL is slightly faster on those platforms. With embedded platforms like STM32F7 and PIC32MZ, only wolfSSL has hardware acceleration support. Independently done webserver stress tests making use of available optimizations in each of the TLS implementations have shown that wolfSSL can more than double the number of connections per second achieved when compared with OpenSSL version 1.1.1.
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 SSL/TLS Support for NXP SE050
The wolfSSL lightweight SSL/TLS library and underlying wolfCrypt cryptography library have included support for the NXP SE050 module since November 2021. Since that time we have been increasing compatibility with SE050 along with usage of SCP03 (Secure Channel Protocol 03) authentication. To help users get started with TLS usage, we also have two example client applications available for use and reference.
wolfSSL TLS users can use the wolfSSL_CTX_use_PrivateKey_Id() API to instruct wolfSSL to use a private key located in the SE050 at a specific key ID. This would replace calls to wolfSSL_CTX_use_PrivateKey_file() or wolfSSL_CTX_use_PrivateKey_buffer(), giving applications enhanced security by allowing the private key to be stored (and optionally generated) inside the SE050 module.
#include <wolfssl/ssl.h>
int wolfSSL_CTX_use_PrivateKey_Id(WOLFSSL_CTX* ctx, const unsigned char* id,
long sz, int devId);
For access to wolfSSL_CTX_use_PrivateKey_Id(), wolfSSL needs to be compiled with WOLF_PRIVATE_KEY_ID defined. This can be passed through configure via CFLAGS, for example:
cd wolfssl-X.X.X ./configure <options> CFLAGS=”-DWOLF_PRIVATE_KEY_ID” make sudo make install
TLS Client Demos Using SE050
wolfSSL has two example SSL/TLS client applications that demonstrate how users can leverage SE050 underneath wolfSSL’s SSL/TLS implementation. These examples are set up to be easily run on a Raspberry Pi environment with attached NXP EdgeLock SE050 Development Kit.
Available examples are included in the “wolfssl-examples” GitHub repository under the SE050 subdirectory and include:
- wolfSSL SSL/TLS Client Example
This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers. For a more advanced demo which uses the private key directly from the SE050, see the following example. For details, see the example README.md, or wolfssl_client.c file.
- wolfSSL SSL/TLS Client Example with Cert and Private Key in SE050
This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers into the SE050, then does all private key operations inside the SE050 for the TLS private key, based on a key ID. For details, see the example README.md or wolfssl_client_cert_key.c.
Resources
For more details on using wolfSSL or wolfCrypt with the NXP SE050, see one of the following links or email us at facts@wolfSSL.com. The wolfSSL embedded SSL/TLS library supports up to the most current TLS 1.3 and DTLS 1.3 protocol standards, has been optimized for performance and footprint size, and also provides easy paths forward for validation and certification requirements (FIPS 140-3, FIPS 140-3 (in progress), CAVP, DO-178C).
Blog: wolfSSL NXP SE050 Support and Benchmarks
Blog: wolfSSL Support for NXP SE050 with SCP03
Documentation: wolfSSL NXP SE050 Support (README_SE050.md)
Examples: wolfSSL NXP SE050 Examples (README.md)
Dev Kits: NXP EdgeLock SE050 Development Kits
SE050 Product Page: EdgeLock SE050: Plug & Trust Secure Element Family
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 support for the Xilinx Zynq UltraScale+ MPSoC
wolfBoot support for the Xilinx UltraScale+ was added in 2020 and is a direct U-Boot replacement for improved security.
wolfBoot provides enhanced features compared to U-Boot such as:
- Firmware integrity and signature verification on each boot
- Image integrity checking SHA2-256 or SHA3-384.
- Validation of the signature using ECC P256/P384, RSA (2048-bit or 3072-bit), ED25519 and LMS or XMSS.
- Multiple boot partition support
- Rollback to last known working or fail-safe “golden” image on failure
- TPM 2.0 Support
- Measured Boot (PCR’s)
- Sealing secret to unlock or decrypt a storage device
- Root of trust options
- Onboard eFUSES
- Public key embedded in wolfBoot partition
- TPM 2.0 NV (supported with wolfTPM)
- Delta/Differential updates using bentley-mcilroy scheme
- Encrypted updates using AES CFB or ChaCha20/Poly1305
Additional wolfBoot Features:
- QSPI, SDMC and eMMC boot support
- ELF (32 and 64) loader support
- FDT (Flattened Device Tree) support for fixups
- AARCH64 EL1/EL3 support
We have included a full example for building with Xilinx SDK and integrating into the FSBL chain of trust. Also creation of the flash boot.bin image with boot.bif and bootgen.
Tested support with bare-metal, QNX, GreenHills Integrity OS and Linux/Fedora.
24×7 support available
Links:
- https://github.com/wolfSSL/wolfBoot/tree/master/IDE/XilinxSDK
- https://github.com/wolfSSL/wolfBoot/blob/master/docs/Targets.md#xilinx-zynq-ultrascale
- https://github.com/dgarske/UltraZed-EG-wolf
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 bare-metal and non-blocking cryptography in 2024
One of the unique wolfSSL features is the ability to run wolfSSL on bare-metal without any Real-Time Operating System (RTOS). Supporting bare-metal has always been a requirement for our libraries from initial development. Having a pure C code base, no external dependencies, portable design and modular build options enables this feature and provides a tiny build size. This is a huge differentiator compared to libraries like OpenSSL that won’t even build without a POSIX layer. The build options to enable bare-metal are (–disable-filesystem –enable-singlethreaded) or (SINGLE_THREADED and NO_FILESYSTEM).
Another unique feature of wolfSSL is our support for managing and handling longer asymmetric math computations, which may have non-deterministic execution times. We achieve this by dividing the workload into smaller chunks, allowing the CPU time to perform other tasks concurrently. We call this feature non-blocking cryptography. We support it for RSA, ECC (256/384/521) and Curve25519. Our goal is to limit any blocking on an embedded target to a maximum of 1ms. We used a generic Cortex M4 at 100MHz as our reference. This functionality, for example, allows you to service real-time events while performing a TLS handshake or signature validation. We take pride in being the only open source TLS/Cryptographic library supporting this non-blocking cryptography feature.
From the caller’s perspective, non-blocking cryptography appears much like a non-blocking socket, where the API will return a FP_WOULDBLOCK status and requires being called again. This capability is supported both through the TLS API’s and wolfCrypt directly.
For additional information, please consult the related documentation links and pull request provided below:
- ECC (–enable-ecc=nonblock or WC_ECC_NONBLOCK):
- RSA (WC_RSA_NONBLOCK):
- Curve25519 (WC_X25519_NONBLOCK):
If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: wolfHSM – wolfSSL and Automotive Hardware Security Modules (HSMs)
Welcome! Join us for one of our most popular wolfSSL webinars, “wolfHSM: wolfSSL and Automotive Hardware Security Modules (HSMs)” scheduled for February 22nd at 10am PT, presented by wolfSSL Software Engineer, Bill. As vehicles have evolved into digital systems over the years, evaluating automotive cybersecurity has become a key aspect of automotive safety.
Watch the webinar here: wolfHSM: wolfSSL and Automotive Hardware Security Modules (HSMs)
Sneak peek of the webinar:
-
- Automotive HSM Features
- wolfHSM Functional Design
- wolfHSM Applicability to Standards
- wolfHSM Hardware Ports and Plans
- wolfHSM Demo
- wolfHSM Future Targets
And much more
If you are seeking solutions to enhance your automotive security system, seize this opportunity to delve into the fundamental and advanced features of wolfHSMs. Discover the comprehensive capabilities that wolfSSL products can offer. Bring all your questions related to Automotive HSMs, as Bill is ready to address your questions!
As always, our webinars will include Q&A sessions throughout the webinar. 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
Post-Quantum Hybrid Solutions
Here at wolfSSL, when it comes to post-quantum algorithms, we are careful to provide conservative approaches. We are aware that these algorithms are new and developments are still on-going as cryptographers continue analyzing these algorithms. As such, we always encourage hybridizing with conventional algorithms. Here are the hybrids we offer:
Hybrid Key exchange via concatenation in TLS 1.3 and DTLS 1.3
- ECDHE P-256 Kyber Level 1
- ECDHE P-384 Kyber Level 3
- ECDHE P-521 Kyber Level 5
Hybrid authentication via dual key/sig certificates in TLS 1.3
- ECDSA P-256 and Dilithium Level 2
- ECDSA P-384 and Dilithium Level 3
- ECDSA P-521 and Dilithium Level 5
- ECDSA P-256 and Falcon Level 1
- ECDSA P-521 and Falcon Level 5
- RSA-3072 and Dilithium Level 2
- RSA-3072 and Falcon Level 1
MQTT protocol relies on TLS, so wolfMQTT has support for everything above.
ECDHE P-256 hybridized with Kyber Level 1 in wolfSSH
- ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org
Go ahead and try them out today!
And finally, we are also developing support for X25519 in wolfSSH. Soon to come after that will be X25519 hybridized with Kyber in wolfSSH. Let your voice be heard! Let us know if you want to try this out. The more interest there is out there, the higher it will rise in priority!
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