New Espressif Managed Components for MQTT and SSH
In our ongoing quest to bring the power and capabilities of wolfSSL products to all Espressif ESP32 developers, we are proud to announce two new upcoming Managed Components in the ESP Registry: wolfMQTT and wolfSSH.
Earlier this year we announced the core wolfSSL availability on the Managed Component Registry. Having wolfSSL as a Managed Component lets you get started in just a few minutes.
We know that many of you are excited to get started as soon as possible. To meet this demand we are announcing the availability of the experimental staging site for wolfSSL components:
https://components-staging.espressif.com/components?q=namespace%3Agojimmypi+wolfssl
First up is wolfMQTT. Getting started with wolfMQTT is easier than ever. Now you can get an example running in about 3 minutes. In fact, in this YouTube video [gojimmypi] demonstrates how with only a few commands in the ESP-IDF, you can get the AWS IoT MQTT example working on your own ESP32:
Here are the steps shown in the video:
#!/bin/bash . ~/esp/esp-idf/export.sh # Needed for Staging site: export IDF_COMPONENT_REGISTRY_URL=https://components-staging.espressif.com idf.py create-project-from-example "gojimmypi/mywolfmqtt^1.0.14-test:AWS_IoT_MQTT" cd AWS_IoT_MQTT idf.py -p /dev/ttyS9 -b 921600 flash monitor -b 115200
Note that this is using the components-staging site, and as such the IDF_COMPONENT_REGISTRY_URL setting is very important. Clear the value when using the production components link.
As you can see, for this example, only one command is needed to create the AWS IoT example application:
If you already have an existing project, that too is just a single command:
Stay tuned for the wolfSSH component to also be added. Soon these will all be available on the production ESP Registry site:
https://components.espressif.com/components?q=wolfssl
Be sure to watch the recording from the recent webinar:
Getting Started with wolfSSL on the Espressif ESP32.
See also some of the recent ESP32 blogs such as the RISC-V ESP32-C3, running Linux on the ESP32-S3 and others.
There’s also support for wolfSSL on Espressif and more Espressif resources.
Do you have any questions related to using wolfSSL in your next project? Contact us at facts@wolfSSL.com or call us at +1 425 245 8247 to learn more.
Download wolfSSL Now
wolfCrypt in TrustZone-M
Using wolfBoot as PKCS#11 secure supervisor
Today, we’re introducing an exciting feature from wolfBoot that makes use of TrustZone-M technology to enhance safe and monitored access to cryptographic operations. By exposing a complete set of standard cryptographic APIs to the application, wolfBoot provides controlled access to the wolfCrypt crypto engine running in the secure domain.
TrustZone-M and domain separation
TrustZone-M essentially creates a secure memory and IO domain within your microcontroller , where system supervision software can execute and provide controlled access to resources to its non-secure counterpart. The secure domain in TrustZone-M is similar to a controlled-access area where only trusted software can be executed. Software running in this domain is usually responsible for enforcing the separation of access permissions for all memory areas and peripherals. It may then optionally assume the role of a passive supervisor by providing special cross-domain API functions (non-secure callables), for a supervised and controlled access to specific functionality otherwise only available in the secure world. This hardware assisted feature is available on most microcontrollers in the ARMv8-M family.
Built-in, hardware assisted security module
Combining this feature with a cryptography engine running in secure mode is an ideal way to create a hardware-assisted separation for secrets and private keys from the application software. It is like having an advanced HSM that can perform crypto operations and store secrets in a security vault, where sensitive information is kept protected. This feature ensures that even if the rest of the system is compromised, the critical information stored in the vault remains secure based on hardware-enforced techniques.
Bootloader supervision
To ensure a trusted boot sequence, the requisite place to set up TrustZone-M, define the separation between the domains, and start the non-secure code execution is, of course, the bootloader. Older versions of wolfBoot were already capable of providing this type of isolation between the two domains, by using a tightly tailored wolfCrypt to verify the authenticity of the application code before staging into non-secure execution mode. We decided to further explore the potential of this integration by adding a fully-equipped wolfCrypt library to wolfBoot, running as a bootloader in the secure domain, and providing a standard way to access cryptographic functions and secure vault to the non-secure application.
The wolfCrypt library is embedded in the bootloader code, and can be used by both the applications/OS, through non-secure callable functions, as well as by wolfBoot itself for its everyday tasks of firmware authentication and integrity verification for securing the boot process.
Resources separation
The first important task to fulfill when preparing a system with TrustZone-M to run non-secure software is to set up and associate each memory segment and peripheral to either domain.
wolfBoot provides configuration options to delimit the areas in the internal flash memory of the microcontroller and separate its own non-volatile memory space from the one dedicated to running the application and receiving the updates in non-secure domain. The example configuration shown in the picture below demonstrates a possible way to divide the internal flash space. The initialization routines in wolfBoot ensure that such a segmentation is enforced through the TrustZone manager embedded in the chip. This configuration implies that the secure and non-secure flash space are logically mapped to different memory locations. A special section is reserved for non-secure callable objects exporting the API for applications to call exposed API functions from the secure domain.
Example flash memory segmentation in an embedded system using wolfBoot as TrustZone-M supervisor
RAM can also be separated by the global trustzone controller (GTZC) in the MCU. This is also enforced at runtime by the microcontroller once the zones have been set up by wolfBoot. The picture below shows an example separation between secure and non-secure RAM sections on a STM32L552 microcontroller, offering a total of 256KB of SRAM in two separate but contiguous banks. In this configuration, half of the total SRAM is dedicated to cryptographic and vault operations in the secure domain. Also in this case, once the GTZC is configured, the RAM is mapped into two separate virtual addresses, starting at 0x3000 0000 and 0x2000 0000 for secure and non-secure domain access, respectively.
Example segmentation of RAM in an embedded system using wolfBoot as TrustZone-M supervisor
PKCS#11
What has been described so far is the infrastructure that wolfBoot is capable of supporting when running on microcontrollers supporting TrustZone-M. All we need at this point is a valid API to access the cryptographic resources offered by wolfBoot running as a TrustZone-M supervisor.
Introduced by RSA laboratories in 2004, PKCS#11 sets the path for vendor-neutral cryptographic token interface (CTI). The standard consists of a well-defined and widely accepted API for the interaction between software and hardware components accessing cryptographic functionality. The use of PKCS#11 for interactions among components in a security infrastructure simplifies the development process, as engineers can rely on standardized interfaces, ultimately reducing development time and risk.
wolfSSL products already support both endpoints for PKCS#11 interoperability. wolfCrypt can be compiled on any platform with built-in support to access a PKCS#11 engine, using the compile time flag –enable-pkcs11, or the equivalent preprocessor definition HAVE_PKCS11. The other side of the communication is provided via a separate library, wolfPKCS11. This module provides the implementation of the API using wolfCrypt as its crypto engine.
When wolfBoot is installed as TrustZone-M secure supervisor, it integrates wolfPKCS11 in its secure domain executable code, which can be accessed by any application in the non-secure domain by calling the corresponding NSC wrappers.
Securing the embedded system architecture
Thanks to the separation between the domains and the integration of a PKCS#11 engine in the secure world, applications can not directly access sensitive cryptographic information such as private keys any more, and rely on the crypto engine under the hood to use these keys when needed. For example, a TLS connection may require the endpoint running on the microcontroller to authenticate itself using a public key mechanism. The private key to generate the signature can be pre-provisioned in the secure vault and used by the TLS to confirm the identity of its local endpoint. Applications already using wolfCrypt APIs to secure data at rest don’t need any adaptations to fit in this new model, because wolfCrypt calls will be translated internally through the wolfCrypt PKCS#11 connector in the non-secure area before calling the actual algorithm implementation in the secure domain, through the NSC API. Finally, any third party application or RTOS integrating a generic PKCS#11 connector can be linked to the NSC API layer and start using the secure, supervised crypto engine right away.
By default all the cryptography functions are implemented in software by wolfCrypt. However, wolfCrypt is very versatile and can make use of hardware security modules or external secure components. This makes this design extendable when more hardware components are in the picture. Compliant usage of some of the functions in wolfCrypt requires a good quality entropy source, which is why we also introduced a secure-world driver for the TRNG of the microcontroller to feed wolfCrypt PRNGs.
Software architecture of an embedded system using wolfBoot as TrustZone-M supervisor. Applications access wolfCrypt in secure world through the PKCS#11 NSC interface
Common use cases
There may be several reasons for a system architect to consider the adoption of wolfBoot as TrustZone-M supervisor in their projects. Some projects rely on two different layers of distribution for the software that eventually runs on target. The owner of the system, who controls the execution of secure and non-secure software on board, may decide to export a SDK to allow customization of the applications. Applications running in the non-secure domain can be mistrusted and sandboxed thanks to the flexibility of the wolfBoot interface to exclude memory sections and peripherals from the non-secure world visibility. In other cases, designers may just be searching for a stable, certified, rock-solid security engine for diverse applications, to facilitate monitoring, updating and managing vulnerabilities through a centralized point. Other scenarios may be simply looking for strong separation of key management, enforced provisioning and avoiding direct interaction between non-secure software and sensitive information, achieved thanks to the policies in place in PKCS#11 for accessing the same tokens with different capabilities and permission masks.
Example on Cortex-M33
As usual, wolfBoot is distributed with example applications to demonstrate the features through real-life porting for evaluation boards for the relevant CPU or microcontrollers in play. For this development, we focused on the STM32L552-Nucleo (Nucleo-L552ZE-Q) board, where all the features needed are accurately documented, which resulted in a smooth integration. A command line tool provided by STMicroelectronics allows users to check and modify the non-volatile registers containing the options for activating and using the TrustZone feature at hardware level. Once the option bytes are correctly configured on the board, wolfBoot can be built using the options WOLFCRYPT_TZ=1 and WOLFCRYPT_TZ_PKCS11=1 to enable wolfCrypt in TrustZone-M with its PKCS#11 interface. The test application that runs in this case initializes a token by creating a new ECC keypair and storing it in the vault. The application then uses the keypair to sign and verify a payload, checking the functionality through the validation of the signature obtained. The file docs/STM32-TZ.md included in wolfBoot provides detailed information on how to build and run the example on the target.
Further research
At wolfSSL we are committed to implement the best solutions for securing your embedded systems. The new wolfBoot feature introduced here is already being expanded to support more hardware platforms, also across different architectures providing hardware-assisted trusted execution environments. Cryptographic APIs between isolated domains can be customized and extended to integrate different interaction models. Moreover, we are looking for the best strategies to extend the wolfCrypt in trustZone-M support with post-quantum cryptography algorithms available in wolfCrypt.
Resources
wolfBoot is available in source code format. The features described in this post will be included in the upcoming version distributed through our download page (https://www.wolfssl.com/download/), and they are already available in the upstream version on our github repository (https://github.com/wolfssl/wolfboot).
If you want to receive more information on wolfBoot running in TrustZone, or if you want to chat with us about secure boot and trusted execution on embedded systems, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Faster No Assembly ChaCha20
At wolfSSL, we always try to get you the best results possible. Most of the time the best way to achieve this is to use assembly optimization. Unfortunately dedicated assembly tuning is targeted and time consuming so it is not always available for your platform. But there are still many ways to squeeze performance out of algorithms with just C. We have achieved up to a 60% speedup in ChaCha20 without using assembly! This was accomplished by performing the exclusive or (XOR) operation on the largest possible word supported by the system. The optimization was merged in https://github.com/wolfSSL/wolfssl/pull/6203 and first available in wolfSSL 5.6.2.
The benchmark was performed on a x86_64 machine with an AMD Ryzen 5 2600 processor. wolfSSL was configured without assembly optimization with ./configure.
These are the results without this optimization:
$ ./wolfcrypt/benchmark/benchmark -chacha20 ------------------------------------------------------------------------------ wolfSSL version 5.5.4 ------------------------------------------------------------------------------ wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) CHACHA 294 MB took 1.016 seconds, 288.985 MB/s Cycles per byte = 11.77 Benchmark complete $ ./wolfcrypt/benchmark/benchmark -chacha20 ------------------------------------------------------------------------------ wolfSSL version 5.5.4 ------------------------------------------------------------------------------ wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) CHACHA 278 MB took 1.017 seconds, 273.204 MB/s Cycles per byte = 12.45 Benchmark complete $ ./wolfcrypt/benchmark/benchmark -chacha20 ------------------------------------------------------------------------------ wolfSSL version 5.5.4 ------------------------------------------------------------------------------ wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) CHACHA 299 MB took 1.006 seconds, 297.137 MB/s Cycles per byte = 11.44 Benchmark complete
These are the results with this optimization:
$ ./wolfcrypt/benchmark/benchmark -chacha20 ------------------------------------------------------------------------------ wolfSSL version 5.5.4 ------------------------------------------------------------------------------ wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) CHACHA 451 MB took 1.010 seconds, 446.210 MB/s Cycles per byte = 7.62 Benchmark complete $ ./wolfcrypt/benchmark/benchmark -chacha20 ------------------------------------------------------------------------------ wolfSSL version 5.5.4 ------------------------------------------------------------------------------ wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) CHACHA 472 MB took 1.003 seconds, 470.584 MB/s Cycles per byte = 7.23 Benchmark complete $ ./wolfcrypt/benchmark/benchmark -chacha20 ------------------------------------------------------------------------------ wolfSSL version 5.5.4 ------------------------------------------------------------------------------ wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) CHACHA 472 MB took 1.004 seconds, 470.026 MB/s Cycles per byte = 7.23 Benchmark complete
If you have questions about the performance of the wolfSSL embedded TLS library, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: All the Cool Things We’ve Added This Year
Join us for an exclusive webinar on the exciting new additions of 2023, presented by wolfSSL Senior Software Engineer, Eric, on September 28th at 9 am PT. Eric will showcase the latest wolfSSL innovations of 2023! Let’s explore the exciting innovations that have been created by wolfSSL engineers this year and discover products and support that offer the best solutions for your projects.
Watch the webinar here: All the Cool Things We’ve Added This year
Sneak peek of the newly added cool products:
- SM Ciphers compliant with Chinese regulations
- Ada/SPARK binding
- wolfSSH ported over to Windows
- And much more!
This is your opportunity to uncover the advantages of using wolfSSL.
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
wolfSSL Support for Renesas RZ/N2L
wolfSSL is delighted to announce that we have added support for the Renesas RZ/N2L. Renesas RZ/N2L uses a high-performance Arm Cortex-R52 core to easily add network functionality to industrial equipment and machines. The RZ/N2L is supported by an open and flexible ecosystem concept – the Flexible Software Package (FSP), built on FreeRTOS – and is expandable to use other RTOS and middleware.
As part of wolfSSL’s port to support the Renesas RZ/N2L board we have added example TLS client and server applications which demonstrate wolfSSL usage. These examples are compiled with e2Studio and run on the target board. The example applications for Renesas RZ/N2L with Renesas IDE e2studio project files are provided in the wolfSSL package, inside the “IDE/Renesas/e2studio/RZN2L” directory. A detailed instruction manual is also included to help you easily get started with wolfSSL on the platform.
These sample applications also leverage the Renesas Secure IP (RSIP), which enables cryptographic hardware acceleration. Currently wolfSSL supports the following Renesas RSIP crypto acceleration algorithms:
- SHA1/SHA256/SHA384/SHA512
- AES-CBC/AES-GCM
- RSA
Limitations:
The current version of the Renesas RSIP driver does not yet include API’s for TLS-related functionality. Therefore, wolfSSL’s usage of RSIP currently only uses hash and random generation while used inside TLS connections.
If interested in using wolfSSL on the RZ/N2L, or 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
eXtremeDB introduces support for wolfSSL
We are extremely excited to announce that McObject, a world leader in embedded and real-time database systems, has chosen wolfSSL as the TLS provider for their eXtremeDB family of database products.
About eXtremeDB
eXtremeDB is a high-performance, low-latency, ACID-compliant embedded database management system with support for both in-memory and persistent storage capability. Exceptionally fast, with unparalleled flexibility, eXtremeDB is used in virtually all embedded systems markets, from consumer electronics to network infrastructure devices to aerospace and defense systems.
In 2021, McObject released eXtremeDB/rt, the first-ever commercially supported deterministic database system suitable for use in hard real-time embedded systems. As an ACID-compliant DBMS, eXtremeDB/rt guarantees internal consistency, but with real-time features also guarantees external consistency when transactions complete within their deadlines. eXtremeDB/rt is designed for use in critical sensor data fusion systems such as avionics and aircraft navigation, driver assistance, medical equipment, power generation and distribution infrastructure, and any other high-reliability system that requires data management.
Why WolfSSL?
The eXtremeDB embedded database system powers mission critical systems that demand “five-nines” reliability (99.999% up-time), thus security and performance is an absolute necessity. When it came to choosing a TLS provider, McObject needed a library that it was confident would satisfy the stringent guarantees it provides to its customers. wolfSSL emerged as the clear choice for several reasons:
Size, Performance, and Flexibility
In the world of embedded systems, resource utilization is critical. wolfSSL can be configured to have an exceptionally small footprint, making it ideal for systems with constrained resources. It also offers the most customizability on the market, allowing users to tune it for highly specific optimization goals such as code size, stack usage, maximum performance, power consumption, and more.
Certification
Compliance is a non-negotiable requirement in secure systems, and eXtremeDB is no exception. wolfCrypt has FIPS 140-2 Certificates #3389 and #2425 and has a certificate for FIPS 140-3 on the way. wolfCrypt has also been DO-178C DAL-A certified for avionics.
Portability
eXtremeDB/rt is available and tightly integrated with all major commercial RTOS including those that are certified to airborne safety standards (DO-178). Therefore, it could not choose a TLS library that had any architectural or platform restrictions. wolfSSL is engineered for maximum portability, supporting virtually every hardware platform and operating system and, like eXtremeDB, can even run on bare-metal, making it the perfect match for eXtremeDB’s diverse use-cases.
The Best-Tested Cryptography Library
eXtremeDB is a DBMS that serves customers who demand 99.999% uptime, designed to power systems that cannot afford to fail. wolfSSL boasts an extensive testing regime, with continuous and rigorous evaluations to ensure the most secure, robust, and up-to-date cryptography solutions, making it a natural choice to satisfy eXtremeDB’s uncompromising customer requirements. Our claim as the best-tested cryptography library in the world is backed by numerous third party audits and our transparent software development process.
Getting Started with eXtremeDB
To get started with eXtremeDB, simply download the latest evaluation release, and then follow the instructions in the documentation to install the package and run the SDK samples. You can contact McObject at info@mcobject.com for more information or support.
By leveraging wolfSSL’s best-in-class TLS capabilities, eXtremeDB can now offer an additional layer of security without compromising on performance. This integration strengthens eXtremeDB’s position as a secure, fast, and reliable database solution for embedded systems and mission-critical real-time applications. We’re thrilled to partner with McObject and look forward to contributing to the ongoing success and security of eXtremeDB products.
For more information on how wolfSSL can enhance your security solutions, feel free to reach out to us at facts@wolfSSL.com, or call us at +1 425 245 8247 with any questions, comments, or suggestions.
Download wolfSSL
Live Webinar: How to Use wolfSSH on Windows
Join us for an informative webinar, wolfSSH on Windows, presented by wolfSSL Software Developer Jacob on September 21st. He will dive into the latest updates on wolfSSH tailored for the Windows environments.
Watch the webinar here: How to Use wolfSSH on Windows
wolfSSH has been ported to Windows, allowing it to operate as a service and host incoming SSH, SFTP and SCP connections. The power of wolfSSH extends further with the advantages of post-quantum support, along with the cryptographic library wolfCrypt, and it’s FIPS certified!
Don’t miss out on this opportunity to discover the benefits of using wolfSSH. This is your chance to gain knowledge about wolfSSH and enhance your technical skills.
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
wolfSSL DTLS1.3 ESP32 Examples Now Available
Last year, wolfSSL announced support for the new RFC 9147 DTLS1.3 Standard. We now have DTLS13 client and server examples available for the Espressif ESP32 series. These projects can optionally be used in conjunction with the command-line client and server examples.
There are a variety of DTLS (both 1.2 and 1.3) examples in the wolfssl-examples/dtls.
If you intend to use Wireshark to inspect packets and verify that your application is using the newest DTLS 1.3, as of September 2023 this feature has not yet been added. See WireShark issue #18071. In the meantime you can check the cipher suite attribute in the Wireshark packet inspection and confirm it is one of the valid TLS 1.3 cipher suites. See RFC 8446 Page 133:
+------------------------------+-------------+
| Description | Value |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| | |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| | |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| | |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| | |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+
Just getting started with wolfSSL on the ESP32? Check out the recorded webinar on youtube
See also some of the recent ESP32 blogs such as the RISC-V ESP32-C3, running Linux on the ESP32-S3 and others.
There’s also support for wolfSSL on Espressif and more Espressif resources.
Do you have any questions related to using wolfSSL in your next project? Contact us at facts@wolfSSL.com or call us at +1 425 245 8247 to learn more.
Download wolfSSL
wolfCLU supports new x509 options
We are constantly enhancing wolfCLU, a command line utility for manipulating certificates. Recently we added some new x509 options. These additions, -req, -extfile, -extensions, -signkey and -* enhance the x509 functionality. Having these options added to wolfCLU helps with generatingself-signed x509 certificates when using the x509 command.
- [-req] Users can generate a certificate signing request (CSR) directly from the command line.
- [-extfile] Users can specify a file containing certificate extension configuration.
- [-extensions] Users can define certificate extensions directly in the command line.[-signkey] Users can provide an existing private key to sign the certificate being generated.
- [-*] Users can select any supported digest for signing. Currently sha1, sha256, sha384 and sha512 are available.
The following example demonstrates how to use these new options to update a self signed x509 certificate.
wolfssl x509 -req -in client-cert.csr -extfile wolfssl.cnf -extensions
uri -signkey client-key.pem -out client-uri-cert.pem
These new options are part of our ongoing commitment to provide a feature-rich and user-friendly experience with wolfCLU’s x509 command.
If you have any feedback, questions, or require support, please don’t hesitate to reach out to us at facts@wolfSSL.com. or call us at +1 425 245 8247.
Download wolfSSL
Post-Quantum: 3 New Draft Standards
After a long and arduous journey, NIST has finally released the draft standards for 3 post-quantum algorithms:
- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf
- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.ipd.pdf
- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.ipd.pdf
Let’s talk a little bit about each of the documents one by one.
FIPS-203 specifies ML-KEM which was based on the NIST Post-Quantum Competition’s only KEM winner Kyber. ML-KEM stands for Module Lattice-based Key Encapsulation Mechanism. It defines 3 parameter sets; each at a different level of security:
- ML-KEM-512 (security equivalence to AES-128)
- ML-KEM-768 (security equivalence to AES-192)
- ML-KEM-1024 (security equivalence to AES-256)
ML-KEM is appropriate as a general replacement for quantum-vulnerable key exchange algorithms such as ECDH or FFDH. Note that ECDH and FFDH happen to be Non-Interactive Key Exchange (NIKE) algorithms, but ML-KEM is not so for applications where the non-interactivity is a requirement, ML-KEM is NOT an appropriate drop-in replacement. While the performance of ML-KEM is very good, the cryptographic artifact sizes are larger than those of ECDH and FFDH.
FIPS 204 specifies ML-DSA which was based on the NIST Post-Quantum Competition’s Signature Scheme winner Dilithium. ML-DSA stands for Module Lattice Digital Signature Algorithm. It defines 3 parameter sets; each at a different level of security:
- ML-DSA-44 (security equivalence to SHA3-256)
- ML-DSA-65 (security equivalence to AES-192)
- ML-DSA-87 (security equivalence to AES-256)
Interestingly, the numbers in the parameter set names refers to the dimensions of a matrix that is used during key generation. For example, for ML-DSA-65, that matrix is 6 by 5 thus the 65. ML-DSA is appropriate as a general replacement for quantum-vulnerable signature algorithms such as ECDSA and RSA. While the performance of ML-DSA is very good, the cryptographic artifact sizes are larger than those of ECDSA and RSA.
FIPS 205 specifies SLH-DSA which was based on the NIST Post-Quantum Competition’s Signature Scheme winner SPHINCS+. SLH-DSA stands for StateLess Hash-based Digital Signature Algorithm. It defines 12 parameter sets:
- SLH-DSA-SHA2-128s
- SLH-DSA-SHAKE-128s
- SLH-DSA-SHA2-128f
- SLH-DSA-SHAKE-128f
- SLH-DSA-SHA2-192s
- SLH-DSA-SHAKE-192s
- SLH-DSA-SHA2-192f
- SLH-DSA-SHAKE-192f
- SLH-DSA-SHA2-256s
- SLH-DSA-SHAKE-256s
- SLH-DSA-SHA2-256f
- SLH-DSA-SHAKE-256f
The names can be seen as having the following format:
SLH-DSA-<hash>-<AES equivalence><optimization>
<hash> : Either SHA2 or or SHAKE. This is the hashing algorithm that is used for that parameter set.
<AES equivalence> : 128, 192, or 256. The security equivalence to AES.
<optimization> : s or f. ‘s’ is for small and ‘f’ is for fast.
SLH-DSA is appropriate as a general replacement for already standardized Stateful Hash-based Signature Schemes such as LMS and XMSS which are currently already standardized by NIST and are suggested for use for firmware signing and verification by the CNSA 2.0 guidance put out by the NSA. The performance and artifact sizes of SLH-DSA are comparable to LMS and XMSS.
This begs the question, since LMS and XMSS are already quantum-safe, why would they need to be replaced? The answer is that the management of the state in the Stateful Hash-based Signature Schemes is a potential pitfall and makes it vastly more difficult to use.
Finally, those of you that have been following this process are probably wondering what happened to Falcon. It is also getting a draft standard but is more difficult to implement so NIST is taking extra care and more time to write the draft standard for it.
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