Post-Quantum: 3 New Draft Standards

After a long and arduous journey, NIST has finally released the draft standards for 3 post-quantum algorithms:

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

Post-Quantum Script Magician: Igor Barshteyn

Today we’d like to give a quick shout out to Igor Barshteyn! He is a long time and active member of the cryptography and information security communities. His interests are very apparent in his posts on LinkedIn.

Besides sleuthing out the the NIST post-quantum draft standards the day before their release and a multitude of other interesting posts, he has come up with a script to allow for easy experimentation in wolfSSL with post-quantum algorithms hybridized with NIST ECC curves in our fips-ready releases. But why would he do that?

Well, if you’re interested in cryptographic compliance, then you will know that the NSA’s CNSA 2.0 guidance requires the use of Kyber. You’ll also know that FIPS 140-2/3 requires the use of FIPS approved ECC curves for key exchange. Moreover, NIST has stated that an ECC key exchange done in a FIPS 140 approved mode of operation can be hybridized a with a post-quantum algorithm and still be considered in a FIPS 140 approved mode of operation. See FQAs for more detail.

Are you curious to see how hybrid FIPS 140 approved mode of key exchange hybridized with the CNSA 2.0 approved Kyber will perform in your environment or on your system? You can find out today!! Check out Igor’s post which has great instructions and a link to his script!Are you curious to see how hybrid FIPS 140 approved mode of key exchange hybridized with the CNSA 2.0 approved Kyber will perform in your environment or on your system? You can find out today!! Check out Igor’s post which has great instructions and a link to his script!

If you have questions on any of above, please contact us at facts@wolfSSL.com, or call us as +1 425 245 8247.

Download wolfSSL

Live Webinar: Reasons to Migrate from OpenSSL to wolfSSL

Are you seeking a superior alternative to OpenSSL with better support and smoother workflow?
wolfSSL can fulfill your needs, addressing the gaps you might be experiencing while using OpenSSL. Join our upcoming webinar hosted by wolfSSL engineer Anthony, where he will focus on advantages of switching to wolfSSL. Discover why choosing wolfSSL over OpenSSL can reshape your projects.

Save the date: 9/14/2023 at 10 am PT

Sneak peek of the webinar:

  • Certified FIPS provider
  • Support for the QUIC protocol (–enable-quic)
  • Support for Post-quantum integration
  • Top-notch support services
  • And much more!

Anthony will provide in-depth insights into what sets wolfSSL apart from OpenSSL. Register now to explore the potential benefits of using wolfSSL. Let us introduce you to solutions that work best for your projects!

As always, our webinars will include Q&A sessions throughout the webinar. 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

Benchmarking wolfCrypt on Cortex M0+

We added a benchmark running on Raspberry Pi PIco-W. It runs with Cortex M0+, 125MHz. If you are interested in how wolfSSL/wolfCrypt works on low end MCU, this should be a good example benchmark to look into.

Here are some highlights:

  • Hash operations such as SHA256 run faster than 1 M bytes per second.
  • Symmetric algorithms like AES-GCM enc/dec faster than 300 k bytes per second.
  • ECDH keygen/agreement, ECDSA sign/verify around 100mSec to 50mSec per operation.

Visit our ‘Raspberry Pi Pico-W’ benchmark page for further details.

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

DTLS Support Added to wolfMQTT-SN

wolfSSL is delighted to announce that we have added a secure way for sensors to communicate to the gateway using DTLS and MQTT-SN! We used the Paho MQTT-SN Gateway project’s recent addition of DTLS support for testing.

Testing details are in the pull request.

Let us know what you think by sending a note to facts@wolfSSL.com.

You can download the latest release, or clone directly from our GitHub repository.
While you’re there, show us some love and give the wolfMQTT project a Star!

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

Live Webinar: SM ciphers are implemented in wolfSSL

Join the webinar to discover how the latest SM cipher implementations from wolfSSL comply with Chinese regulations and can secure your critical systems! wolfSSL engineer Sean will reveal all the details to help you find the best solutions for your critical systems on September 7th at 2pm PT.

Save the date: 9/7/2023 at 2pm PT

The Chinese government mandates the use of SM2, SM3, and SM4 in critical systems such as automobiles, avionics and more. wolfSSL is proud to announce our supported versions of these ciphers tailored to our customers in the Chinese market. We also have a plan to release the ZUC stream cipher later this year to completely satisfy SM9. Additionally, we’re actively communicating with labs regarding support of OSCCA certification in the future.

This exciting development is fantastic news for our customers in the Chinese market, ensuring they remain compliant with the latest regulations.

Benefits of using wolfSSL products:

  1. The SM Ciphers are fully supported in wolfSSL’s TLS 1.3 and DTLS 1.3 implementations.
  2. wolfSSH, wolfBoot and our other products will support ShangMi ciphers.
  3. ARM, Intel, and RiscV assembly is in the works for our SM implementations for maximum performance
  4. We support bare metal for SM2, SM3, and SM4
  5. We have maximized performance and minimized size, so the ShangMi algorithms will work well for embedded systems use cases on a wide variety of microcontrollers (MCU’s). They will be available for all of the MCU silicon that we currently support, including STM32, NXP i.MX, RISC-V, Renesas RA, RX, and Synergy, Nordic NRF32, Microchip PIC32, Infineon Aurix, TI MSP, and many others
  6. Our GPLv2 versions of the SM ciphers are available on GitHub

Commercially licensed versions are available.

Don’t miss this opportunity to discover solutions for your system security and compliance. Join our webinar to explore the full potential of SM cipher implementations from wolfSSL.

Register now!

As always, our webinars will include Q&A sessions throughout the webinar. 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

Every hardware cryptography scheme wolfSSL has ever enabled

At wolfSSL we support hardware cryptography for a wide range of platforms. The benefits of hardware cryptography include reduced code footprint size, improved security, acceleration of cryptographic operations, and utilization of true random number generators. For example, this allows everything from wolfBoot to TLS cipher suites to enjoy acceleration of cryptographic operations.

Furthermore, we have deep partnerships with industry leaders such as Intel, NXP, and Renesas. We support standard Intel instruction extensions such as AES-NI, AVX, and ADX and BMI2, and have recently published a joint whitepaper on using wolfBoot with 11th Gen Intel Core processors. We also support NXP’s Cryptographic Accelerator and Assurance Module (CAAM), and have leveraged this for hardware acceleration on a number of NXP i.MX series processors. Other examples include Espressif and Analog Devices, to name but a few.

If you’re curious for a list of every hardware cryptography scheme and platform we have enabled, then read on:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Do you have a platform requiring hardware cryptographic support that isn’t on our list, or are you curious about benchmarking? Please contact us at facts@wolfSSL.com, or call us at +1 425 245 8247 with the details of your platform and we will be glad to help you! Also, check out our wolfSSL and wolfCrypt benchmark page.

 

Download wolfSSL

Posts navigation

1 2