The Top 5 Build Options for Security in wolfSSL
Here at wolfSSL, we love giving the community and our customers lots of choices and options. That said, for the vast majority of our user base, all the options we are discussing in this post should be enabled to maximize your security and minimize your adversary’s opportunities.
#define WOLFSSL_HARDEN_TLS 112 or –enable-harden-tls=112
enables the following algorithms at the following key lengths
DH: at least 2048 bit keys
RSA: at least 2048 bit keys
ECC: at least 224 bit keys
#define WOLFSSL_HARDEN_TLS 128 or –enable-harden-tls=128
Disables 3DES ciphersuites
DH: at least 3072 bit keys
RSA: at least 3072 bit keys
ECC: at least 256 bit keys
#define NO_OLD_TLS or –diable-oldtls
This disables older protocols that are inherently insecure. The only protocols that are built are (D)TLS 1.2 and 1.3.
#define HAVE_ALPN or –enable-alpn
This helps to ensure that the right application is processing the connection. Please see RFC document for more details about how to use this TLS extension.
#define WOLFSSL_CIPHER_TEXT_CHECK or –enable-maxstrength
Add in extra checks after the processing of ciphertext input in order to mitigate glitching attacks.
#define WC_RSA_BLINDING or –enable-harden
RSA blinding involves transforming the input just before the RSA private key operations using some random data. After the operation, the reverse of the transform is performed giving the desired output. This prevents an adversary from gaining knowledge about the private key as they don’t know the random data that was used to determine the transform and therefore do not know the true input into the RSA private key operation.
#define TFM_TIMING_RESISTANT #define ECC_TIMING_RESISTANT or –enable-harden
These allow for constant time implementations of the math used in private key operations to mitigate timing attacks.
Oops, looks like we went a bit over 5! Want even more? Thinking about turning some of these off to get performance gains or reduce memory usage? Send a message to support@wolfSSL.com to start a conversation about it!
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 Supports Nucleus Legacy Customers
wolfSSL has partnered with Siemens to provide cyber-security solutions in the Nucleus RTOS stack for over a decade. Now that Nucleus ReadyStart has been discontinued, wolfSSL will continue to provide support and software updates for the wolfSSL, wolfCrypt, wolfMQTT, and wolfSSH components. This will help ensure that Nucleus customers’ applications are safe and secure.
wolfSSL supports the latest versions of TLS and DTLS for newer and older versions of Nucleus. wolfCrypt also supports the latest cryptography standards, including post quantum cryptography.
Direct support plans are available for our security tools, so please contact us with any questions about keeping your Nucleus project secure!
Check out our Support and Maintenance
Lastly, if you are considering migrating to another RTOS solution, wolfSSL can continue to provide the optimized security you have been accustomed to when using Nucleus. The wolfSSL projects are highly portable, and we would be happy to assist you with the migration process.
If you have any questions about keeping your Nucleus ReadyStart up to date with the latest wolfSSL code, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
TLS and Secure Boot in the EU Cyber Resilience Act
As of June 2024, the EU Cyber Resilience Act (CRA) is a pending piece of legislation that has been approved by the European Parliament and is waiting on adoption by the Council of the European Union. Once the act comes into force, manufacturers will have 36 months to apply the rules. It aims to tackle the challenges of cyber security in the EU and “safeguard consumers and businesses buying or using products or software with a digital component”. The act will require that any product sold in the EU with a digital component will adhere to stricter cyber security regulations. Products will have to be secure by default, have a way to apply security updates, have a clear vulnerability process, and define a product life cycle among other requirements.
The CRA requires that all communications are secure. We recommend using secure protocols such as SSL/TLS and SSH instead of trying to develop your own solution. These protocols provide privacy, integrity, and authentication across unsecure networks. They protect against unauthorized access and protect the confidentiality of the transmitted information.
To provide security updates to devices in the field, we recommend using wolfBoot’s Over-The-Air (OTA) update feature. This allows you to provide security updates in compliance with the CRA. wolfBoot provides a highly reliable, transport-agnostic firmware update mechanism.
Over at wolfSSL we take vulnerabilities very seriously. We investigate them immediately and fixes are always developed within days of an initial report. We implement rigorous security testing and code review to ensure the best quality releases possible.
With wolfSSL you can be sure that your products will meet the CRA requirements. For more questions about how to comply with the CRA, or if you have questions about any of the above, please write to us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: Post-Quantum Algorithms in cURL
Join us for our upcoming webinar, “Post-Quantum Algorithms in cURL,” on June 26th at 10 AM PT. The session will be led by wolfSSL Senior Software Developer Anthony Hu.
In this session, Anthony will cover a wide range of topics, from the fundamental concepts of post-quantum algorithms, including the CNSA 2.0 timelines and the concept of “Harvest Now, Decrypt Later,” to a demonstration on how to make cURL transfers quantum-safe.
Register Here: Post-Quantum Algorithms in cURL
During this webinar, we will cover:
- Motivation: CNSA 2.0
- Demo Architecture
- Getting and Building the Code
- Demo Time!
- Post-Quantum Connection Explained
Gain an understanding of the importance of investing in post-quantum algorithms and learn how to create a quantum-safe security environment for cURL transfers in the future.
Register now to secure your spot. Time is ticking until post-quantum algorithm requirements become mandatory, so start preparing to secure your data using cURL with quantum-safe methods.
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 +1 425 245 8247.
Download wolfSSL Now
TLS Session ID vs Tickets
All versions of the Transport Layer Security (TLS) protocol support resuming previously established connections. The keying material previously negotiated is re-used in the new connection. The major benefits of resuming sessions are the much shorter handshake and not having to recompute session keys. In embedded systems, both of these advantages are critical to decrease the latency of a connection. TLS session resumption uses much less bandwidth and fewer clock cycles than a full handshake. There are two methods to resume a TLS session: using the session ID or a session ticket.
The TLS session ID can be used to resume TLS <= 1.2 sessions. It has been deprecated in TLS 1.3 in favor of only tickets. The session ID is sent to the client from the server in the ServerHello message when performing a full handshake. When a client wants to resume a session, it sends the session ID in the ClientHello. The server then needs to find the session matching the ID in its cache and restore the keying material. This requires both sides to store the keying material. This means that servers need to have a cache that grows linearly with the number of peers that it intends to resume with.
TLS session resumption tickets are available in all versions of TLS, although TLS version 1.3 has introduced a few changes. The general idea is that a server can issue an encrypted ticket to the client that contains all of the data necessary to resume a session. The client has to store the ticket and the keying material to be able to resume the session while the server does not have to store anything (apart from the encryption key used to encrypt the ticket). This removes the cache burden on the server entirely. In TLS <= 1.2 the session ticket is sent as part of the handshake while in 1.3 it is a post-handshake message. This means that the server can actually issue multiple tickets in one connection but the client needs to wait until after the handshake for the server to send the ticket before it can resume a session. TLS 1.3 servers usually send the ticket as the first message right after the handshake.
To perform session resumption in wolfSSL, please see the documentation about the wolfSSL_get1_session API.
For more information about session resumption in wolfSSL, or if you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
Announcing wolfSSL TPM support for the Espressif ESP32
Infineon and wolfSSL recently announced their collaborative Commitment to Trusted Computing.
wolfTPM is designed for embedded use and leverages all features in the TPM 2.0 specification. wolfTPM is ideal for resource constrained devices and runs on Windows, Linux, RTOS, and bare metal environments.
The Infineon OPTIGA TPM SLB 9672 supports Microsoft Windows and Linux environments. Infineon also offers software and tools to facilitate firmware updates for the TPM.
Today we add the Espressif ESP32 to the long list of devices with wolfTPM support. With the merge of the open source PR #351, our TPM library can now be used in the ESP-IDF for the Infineon 9673 I²C TPM 2.0 module, taking up only about 5×5 mm footprint for a PG-UQFN-32-1,-2 package.
In recent years, TPM gained more attention due to the requirement of Windows 11 machines to have a TPM module present to meet Microsoft’s Security Recommendations. In fact, many other[*1] devices have long taken advantage[*2] of the security features available in a TPM module.
Key features[*3] include :
- Optimized TPM device for IoT and ICT applications
- PQC-protected firmware update mechanism
- Compliant to TPM Main Specification, Family “2.0”, Level 00, Revision 01.59
- Certifications:
- CC, Version 3.1 Rev.5, level EAL4+, AVA_VAN.4 (moderate) according to TCG PC Client TPM Protection Profile (targeted)
- FIPS 140-2 level 2 (physical security level 3) (targeted)
- I2C interface
- Random Number Generator (RNG) implemented according to NIST SP800-90A using entropy source according to NIST SP800-90B
- Full personalization with 4 Endorsement Keys (EK) and 4 EK certificates (RSA 2048, RSA3072, ECC NIST P256, ECC NIST P384)
- Standard temperature range (-40°C .. +85°C) or enhanced temperature range (-40°C .. +105°C)
- PG-UQFN-32-1,-2 package
- Optimized for battery operated devices: low standby power consumption (typ. 120 µA)
- 24 PCRs (SHA-1, SHA-256 or SHA384)
- 51 kByte NV memory [*4]
- Unlimited amount of NV counters (only depending on NV memory utilization)
- Up to 3 loaded sessions (TPM_PT_HR_LOADED_MIN)
- Up to 64 active sessions (TPM_PT_ACTIVE_SESSIONS_MAX)
- Up to 3 loaded transient Objects (TPM_PT_HR_TRANSIENT_MIN)
- Up to 7 loaded persistent Objects (TPM_PT_HR_PERSISTENT_MIN)
- Pre-generation of up to 7 RSA key pairs
- RSA (1024, 2048, 3072 and 4096 bit)
- ECC (NIST P256, BN P256, NIST P384)
- SHA-1, SHA-256, SHA-384
- AES-128, AES-192, AES-256
Why use wolfTPM?
The perfect companion to the Infineon Hardware is the wolfTPM software library, making it easier than ever to easily use the hardware features in your project. Of particular interest is our ability to update the SLB9672 and SLB9673 firmware! See the related blog: Infineon wolfSSL Modus Toolbox Support and wolfTPM Firmware upgrade support,
Security Enhancement: Adding wolfTPM to your Espressif ESP32 projects brings a crucial layer of hardware-based security. By using a Trusted Platform Module (TPM), wolfTPM ensures that all cryptographic operations are handled within a secure chip away from the prying eyes of software attackers. This setup is ideal for maintaining the confidentiality and integrity of your data.
Open Source and Community-Driven: As with all other open-source wolfSSL libraries, wolfTPM thrives on community input and collaboration. This transparency not only helps in enhancing its security capabilities but also keeps it at the forefront of technological and security advancements.
Broad Platform Support: The new support for Espressif ESP32 is another example of wolfTPM’s commitment to versatility across different platforms. This is especially valuable for those working on IoT devices or embedded systems that demand secure, flexible hardware integration options.
Ease of Integration: wolfTPM is designed with developers in mind, offering an intuitive API that makes it easy to add security features into your applications. Whether you’re highly experienced or just getting started in the world of hardware security, wolfTPM comes with all the documentation and support you’ll need to get up and running quickly.
Performance and Efficiency: wolfTPM is both economical and powerful in terms of resource use, making it ideal for the resource-limited environments that are typical of devices such as the ESP32. The library ensures your cryptographic operations are efficient and fast.
Real-World Use Cases: wolfTPM is built to secure a wide variety of applications – from smart home devices ensuring your privacy, to industrial machines that need to operate under stringent security and safety measures. The introduction of wolfTPM to the ESP32 allows for even more applications to benefit from trusted computing technologies.
Compliance and Certification: Using TPM technology with wolfTPM can ease the path to meeting rigorous security standards and compliance demands, critical for many businesses and industries.
Learn more about wolfTPM
Stay tuned for more announcements, as we’ll be also supplying wolfTPM support for the ESP32 as an Espressif Registry Managed Component, along with our existing wolfSSL, wolfSSH, and wolfMQTT components.
Do you want to take security to the next level on your ESP32 project? Let us help you take advantage of all the capabilities of TPM.
Find out more
If you have any feedback, questions, or require support, please don’t hesitate to reach out to us at facts@wolfSSL.com, +1 425 245 8247, or open an issue on GitHub.
[*1] – See https://github.com/wolfSSL/wolfTPM?tab=readme-ov-file#hardware
[*2] – Governments recognize the importance of TPM 2.0 through ISO adoption (June 29. 2015)
[*3] – Copied from the Infineon OPTIGA™ TPM SLB 9673 TPM2.0 Data Sheet
[*4] – Actual usable NV memory slightly less.
Download wolfSSL Now
Yocto vs Buildroot: Build Systems to Tailor an Embedded Linux Solution
Yocto and Buildroot are powerful solutions designed to manage the complexities of deploying embedded products. Unlike general-purpose distributions such as Ubuntu or Red Hat Enterprise Linux, these systems allow for highly targeted deployments tailored specifically for embedded devices.
General Functionality of Both:
- Compiling from Source: They both handle compiling the kernel, system libraries, bootloader, and user applications, doing everything that is needed for the target environment.
- Cross-Compilation: They allow builds on a host machine (often of a different architecture) to compile software for the target device’s architecture.
- Package Customization: They provide mechanisms to apply custom configuration files and patches, enabling modifications and optimizations of packages to suit specific needs more effectively
Yocto Specific Features:
- Meta-layers and Recipes: Yocto uses meta-layers and recipes (.bb files), which are maintained by the community and offer detailed configuration options, sourcing, and build specifications.
- Toolchain Building: Specializes in creating custom toolchains, enabling the development of environments specifically tailored for the hardware’s architecture and project requirements.
- Complexity and Flexibility: Yocto’s complexity allows for extensive flexibility, supporting multiple development streams and detailed configuration options, suitable for large-scale industrial applications.
- Community and Documentation: Yocto is supported by a vast network of developers and offers robust documentation for complex, industrial-scale deployments.
- Petalinux: Xilinx’s petalinux is based on a fork of Yocto, meaning that the recipes and layers can easily be reused.
- Security Features: Offers advanced security configurations ideal for high-security needs.
Buildroot Specific Features:
- Makefile-Based Build System: Utilizes .mk Makefiles and kconfig for a straightforward approach to managing the download, configuration, and compilation of packages.
- Simplicity by Design: Less resource-intensive and fewer dependencies make it ideal for smaller systems or projects where simplicity is a priority.
- Firmware Generator: Primarily focuses on generating a root filesystem image, streamlining the process to produce minimal and ready-to-deploy firmware.
- Performance Metrics: Known for quicker configuration and compilation, making it suitable for rapid prototyping and small-scale projects.
- Learning Curve and Ease of Use: Offers a simpler learning experience, making it accessible and straightforward for beginners.
- Long-term Maintenance and Updates: Its simplicity facilitates easier updates, while the straightforward nature allows for manual security updates.
By understanding the strengths and limitations of each system, developers can choose the most appropriate tool to create efficient and stable embedded systems. Whether your project demands the robust flexibility of Yocto or the streamlined simplicity of Buildroot, selecting the right tool is crucial for optimal performance and success.
Interested in building one of wolfSSL’s solutions like wolfCLU, wolfMQTT, wolfTPM, or wolfSSH with Yocto? Check out our Yocto layer meta-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
wolfCrypt implementations of LMS/HSS and XMSS/XMSS^MT signatures: build options and benchmarks (Intel x86)
At wolfSSL we’re excited about stateful hash-based signature schemes and the CNSA 2.0, and we just had a webinar on this subject. If you recall, previously we added initial support for LMS/HSS and XMSS/XMSS^MT, through external integration with the hash-sigs and xmss-reference implementations.
Recently however we have completed our own wolfCrypt implementations of these algorithms, and would like to share benchmarking results and some of the build options available. Generally the wolfCrypt implementations of these signature methods are faster, with more options available to tune build size and performance.
With that said, we’ll review some of the more relevant build options and benchmarking data for LMS/HSS, and XMSS/XMSS^MT. These benchmarks were obtained on a Fedora 38 workstation with an Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz. Only a single core was used. wolfSSL was built with –enable-intelasm to utilize assembly speedups for all tests. Note: LMS/HSS and XMSS/XMSS^MT support a very wide range of parameters. For the sake of conciseness only a targeted range is benchmarked here.
LMS build options and benchmarking
The five main defines that customize the wolfCrypt LMS/HSS build are the following:
- WOLFSSL_LMS_LARGE_CACHES
- WOLFSSL_WC_LMS_SMALL
- WOLFSSL_LMS_MAX_LEVELS=N
- WOLFSSL_LMS_MAX_HEIGHT=H
- WOLFSSL_LMS_VERIFY_ONLY
The define WOLFSSL_LMS_LARGE_CACHES will cache more of the authentication path into memory, speeding up signing operations for larger height trees.
The define WOLFSSL_WC_LMS_SMALL reduces code size and memory use overall, with the tradeoff of much slower signing operations. However the performance impact for verification is negligible.
The defines WOLFSSL_LMS_MAX_LEVELS, and WOLFSSL_LMS_MAX_HEIGHT set compile time limits on the size of the LMS/HSS hypertree, and mainly reduce code footprint without impacting performance. These can be used to slim the build size if you are only interested in a specific parameter set range. More specifically, WOLFSSL_LMS_MAX_LEVELS sets the max allowed levels in HSS (the number of trees in the hypertree), while WOLFSSL_LMS_MAX_HEIGHT sets the max allowed height per tree for both LMS and HSS.
The define WOLFSSL_LMS_VERIFY_ONLY restricts the build to a smaller verify-only subset (LMS API and data structures needed for keygen/signing are omitted). This does not impact verify performance, and is intended for embedded targets that need verify-only functionality (e.g. wolfBoot). WOLFSSL_LMS_VERIFY_ONLY can be combined with WOLFSSL_WC_LMS_SMALL, WOLFSSL_LMS_MAX_LEVELS, and WOLFSSL_LMS_MAX_HEIGHT for further footprint reduction.
In Table 1 we show benchmarking results (obtained with ./wolfcrypt/benchmark/benchmark -lms_hss) for these different build options, with the external LMS/HSS implementation provided for comparison.
In general we see the default wolfCrypt LMS/HSS performance (wc_lms) is much faster than the external integration (ext_lms) for all categories of operation (keygen, signing, verifying). The WOLFSSL_LMS_LARGE_CACHES (wc_lms large) option speeds up signing operations for larger height trees, but otherwise does not impact performance. The small variations in verify speed across wc_lms, wc_lms large, and wc_lms small are likely just system noise and do not represent a systematic trend. The WOLFSSL_WC_LMS_SMALL option (wc_lms small) significantly reduces signing speed, but leaves verification speed basically unchanged, making this option attractive for verify-only applications in embedded systems.
Table 1: Comparison of wolfCrypt LMS/HSS (wc_lms), wolfCrypt LMS/HSS with WOLFSSL_LMS_LARGE_CACHES (wc_lms large), wolfCrypt LMS/HSS with WOLFSSL_WC_LMS_SMALL (wc_lms small), and the external integration implementation (ext_lms). All values in units of ops/sec.
| wc_lms | wc_lms large | wc_lms small | ext_lms | |
|---|---|---|---|---|
| L2_H10_W2 keygen | 6.482 | 6.494 | 12.828 | 1.330 |
| L2_H10_W2 sign | 4437.469 | 5521.796 | 6.526 | 786.083 |
| L2_H10_W2 verify | 13954.450 | 14087.794 | 13874.450 | 4789.383 |
| L2_H10_W4 keygen | 3.567 | 3.592 | 6.954 | 0.764 |
| L2_H10_W4 sign | 2452.361 | 3052.326 | 3.562 | 443.225 |
| L2_H10_W4 verify | 6482.891 | 6707.271 | 6962.215 | 2281.440 |
| L3_H5_W4 keygen | 70.926 | 73.673 | 227.376 | 17.467 |
| L3_H5_W4 sign | 4660.370 | 4669.019 | 74.653 | 820.640 |
| L3_H5_W4 verify | 4632.118 | 4670.963 | 4790.742 | 1756.355 |
| L3_H5_W8 keygen | 9.395 | 9.413 | 29.041 | 2.265 |
| L3_H5_W8 sign | 609.408 | 605.199 | 9.542 | 106.059 |
| L3_H5_W8 verify | 561.759 | 554.635 | 573.341 | 214.093 |
| L3_H10_W4 keygen | 2.384 | 2.368 | 7.128 | 0.569 |
| L3_H10_W4 sign | 2459.698 | 3067.848 | 2.376 | 444.601 |
| L3_H10_W4 verify | 4895.203 | 4345.130 | 4793.853 | 1618.676 |
| L4_H5_W8 keygen | 7.045 | 7.017 | 29.258 | 1.770 |
| L4_H5_W8 sign | 608.915 | 607.318 | 7.168 | 106.881 |
| L4_H5_W8 verify | 446.384 | 443.804 | 438.542 | 145.672 |
Graph 1: Signing speeds for wolfCrypt LMS/HSS (wc_lms), wolfCrypt LMS/HSS with WOLFSSL_LMS_LARGE_CACHES (wc_lms large), and the external integration implementation (ext_lms). All values in units of ops/sec.
XMSS build options and benchmarking
Three important defines that customize the wc_xmss build are:
- WOLFSSL_WC_XMSS_SMALL
- WOLFSSL_XMSS_MAX_HEIGHT=N
- WOLFSSL_XMSS_VERIFY_ONLY
The define WOLFSSL_WC_XMSS_SMALL reduces code size and memory use overall, with the tradeoff of much slower signing operations, and 20-30% slower verification.
The define WOLFSSL_XMSS_MAX_HEIGHT=N sets compile time limits on the max height of the hypertree, and mainly reduces code size without impacting performance.
The define WOLFSSL_XMSS_VERIFY_ONLY restricts the build to a smaller verify-only subset, and can be combined with WOLFSSL_WC_XMSS_SMALL, and WOLFSSL_XMSS_MAX_HEIGHT for further size reduction. It does not impact verify performance.
In Table 2 we show benchmarking results for XMSS/XMSS^MT for these options (obtained with ./wolfcrypt/benchmark/benchmark -xmss_xmssmt_sha256), with the external XMSS/XMSS^MT implementation for comparison. The default wolfCrypt XMSS/XMSS^MT (wc_xmss) is in general better than the external integration (ext_xmss), for all operations. There is a smaller difference between wc_xmss and ext_xmss as compared to wc_lms and ext_lms though, because ext_xmss can benefit from assembly speedups whereas ext_lms cannot. Similar to LMS, the WOLFSSL_WC_XMSS_SMALL option (wc_xmss small) significantly reduces signing performance, but verify speeds remain fast, making this a good option for embedded verify-only targets.
Table 2: Comparison of wolfCrypt XMSS/XMSS^MT (wc_xmss), wolfCrypt XMSS/XMSS^MT with WOLFSSL_WC_XMSS_SMALL (wc_xmss small), and the external integration implementation (ext_xmss). All values in units of ops/sec.
| wc_xmss | wc_xmss small | ext_xmss | |
|---|---|---|---|
| XMSS-SHA2_10_256 keygen | 1.587 | 1.079 | 0.943 |
| XMSS-SHA2_10_256 sign | 363.693 | 1.106 | 226.782 |
| XMSS-SHA2_10_256 verify | 3050.276 | 2044.995 | 1892.234 |
| XMSSMT-SHA2_20/2_256 keygen | 0.808 | 1.100 | 0.472 |
| XMSSMT-SHA2_20/2_256 sign | 298.138 | 0.551 | 191.214 |
| XMSSMT-SHA2_20/2_256 verify | 1307.295 | 982.836 | 852.348 |
| XMSSMT-SHA2_20/4_256 keygen | 9.880 | 35.274 | 7.309 |
| XMSSMT-SHA2_20/4_256 sign | 390.942 | 8.681 | 290.516 |
| XMSSMT-SHA2_20/4_256 verify | 729.433 | 517.298 | 443.444 |
| XMSSMT-SHA2_40/4_256 keygen | 0.406 | 1.107 | 0.237 |
| XMSSMT-SHA2_40/4_256 sign | 294.738 | 0.276 | 161.656 |
| XMSSMT-SHA2_40/4_256 verify | 750.591 | 487.257 | 424.986 |
| XMSSMT-SHA2_40/8_256 keygen | 5.604 | 35.318 | 3.755 |
| XMSSMT-SHA2_40/8_256 sign | 469.764 | 4.374 | 293.184 |
| XMSSMT-SHA2_40/8_256 verify | 361.289 | 262.160 | 225.254 |
| XMSSMT-SHA2_60/6_256 keygen | 0.266 | 1.099 | 0.159 |
| XMSSMT-SHA2_60/6_256 sign | 280.160 | 0.185 | 144.637 |
| XMSSMT-SHA2_60/6_256 verify | 521.610 | 352.718 | 295.882 |
| XMSSMT-SHA2_60/12_256 keygen | 4.143 | 35.280 | 2.505 |
| XMSSMT-SHA2_60/12_256 sign | 514.658 | 2.910 | 292.371 |
| XMSSMT-SHA2_60/12_256 verify | 247.682 | 170.459 | 152.471 |
Graph 2: Verify speeds for wolfCrypt XMSS/XMSS^MT (wc_xmss), wolfCrypt XMSS/XMSS^MT with WOLFSSL_WC_XMSS_SMALL (wc_xmss small), and the external integration implementation (ext_xmss). All values in units of ops/sec.
Conclusions
In general our wolfCrypt implementations for LMS/HSS and XMSS/XMSS^MT are significantly faster than the external reference implementations, with speedups of 20-30% to even 3x-4x possible depending on the combination of operation, algorithm, and parameters.
The small footprint build shows fast verification speeds for all parameters, making it an attractive choice for embedded verify-only applications (e.g. wolfBoot).
Overall our LMS/HSS implementation is faster than XMSS/XMSS^MT (at least on x86), which is consistent with what is known about these two methods. However which of the two is more appropriate for your use case will ultimately depend on other factors as well, such as signature size, target environment, and parameters used.
If you’re interested in learning more about our post-quantum work, or want to learn more about stateful hash-based signature schemes, 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: Linux Kernel Module with FIPS 140-3
Join us for our upcoming webinar, “Linux Kernel Module with FIPS 140-3,” on June 20th at 10 AM PT. The session will be led by wolfSSL Senior Software Engineer Daniel Pouzzner.
In this webinar, you’ll learn the fundamentals of how the wolfSSL Library functions as a Linux kernel module and explore advanced features, including how developers can utilize it with FIPS 140-3.
Register Here: Linux Kernel Module with FIPS 140-3
wolfSSL is excited to announce that the Linux kernel module now supports kernel cryptosystem registration for AES-XTS, with a simple configure option, providing FIPS 140-3 AES-XTS with performance meeting or exceeding native in-tree performance.
Register now to secure your spot for this exclusive webinar and gain fundamental and advanced knowledge of using wolfSSL with the Linux kernel module. Stay updated on the latest features and advancements!
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 +1 425 245 8247.
Download wolfSSL Now
Everything wolfSSL is Preparing for Post-Quantum as of Spring 2024
We’ve done a lot to enable post quantum cryptography in our products over the last 3 years. The list below outlines everything we have available, in open source, for users right now. If you see something on the list that you have questions about, or think there is some further enablement that we should do, please email us at facts@wolfSSL.com and share your thoughts.
wolfCrypt
We now have our own in house developed implementations of the following post-quantum algorithms:
- Kyber/ML-KEM
- LMS/HSS
- XMSS/XMSS^MT
- Dilithium/ML-DSA (Coming soon!!)
We will be implementing more over the coming months. These implementations live up to the wolfCrypt standards: Minimum code size, maximum performance, and ability to run on bare metal, RTOS, and standard environments.
wolfSSL
For TLS 1.3 and DTLS 1.3, we know from Grover’s algorithm that the symmetric ciphers lose about half their security in the presence of a Cryptographically Relevant Quantum Computer (CRQC). Typically, AES-128 is considered sufficient. As such, if you want to preserve that level of security, simply move to AES-256 which is easy because we already support TLS_AES_256_GCM_SHA384.
Authentication and key exchange are a different story. These are asymmetric algorithms and we know from Shor’s algorithm that our modern methods are completely broken in the presence of a CRQC. As such, we support Kyber/ML-KEM in both hybrid and normal modes:
- Kyber Level 1
- Kyber Level 3
- Kyber Level 5
- ECDHE P-256 hybridized with Kyber Level 1
- ECDHE P-384 hybridized with Kyber Level 3
- ECDHE P-521 hybridized with Kyber Level 5
For authentication, we support Dilithium/ML-DSA as well as Falcon. We have chosen to use the method of hybridization that is specified in the most recent edition of the X.509 specification where an alternative public key and signature are specified as X.509 extensions; we call these dual-algorithm certificates. At the TLS 1.3 layer, which key(s) and signature(s) are used in the CertificateVerify handshake message is negotiated via TLS extensions.
We support authentication in both hybrid and normal modes:
- Dilithium Level 2
- Dilithium Level 3
- Dilithium Level 5
- Falcon Level 1
- Falcon Level 5
- 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
wolfMQTT
Note that our wolfMQTT product uses the TLS 1.3 implementation from wolfSSL so you can get these post-quantum features automatically.
wolfSSH
For wolfSSH, we support the hybrid key exchange known as ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org which allows us to interop with the OQS fork of OpenSSH and the AWS Transfer Family SSH implementation.
wolfBoot
For wolfBoot, we have support for the stateful hash based signature schemes LMS/HSS and XMSS/XMSS^MT.
Open Source Integrations
In terms of open source project integrations, we have post-quantum integrations with these three web servers:
And for the web client side, we have also made cURL quantum-safe! See this video for instructions on how to build.
If you’ve got an application where making changes is difficult due to legacy software, we’ve got our post-quantum integration with stunnel to make your migration a breeze.
The Future
Our own implementation of Dilthium/ML-DSA is coming soon.
We have plans to add Curve25519 hybridized with Kyber in TLS 1.3, DTLS 1.3 and SSH. Want to get these plans accelerated? Send us a message letting us know your protocol preference!
If you have questions about our post-quantum efforts or any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now