So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

FIPS 140-3 Announcement to the world

wolfSSL Inc. is very pleased to announce our wolf pack has successfully hunted down and captured the ever elusive FIPS 140-3 certificate! The world’s first automated submission (SP800-140Br1) FIPS 140-3 validated certificate #4718 posted to the NIST website on July 11th 2024, valid through July 10th, 2029!

“wolfSSL remains focused on enhancing our technologies and expanding capabilities. We are dedicated to continuous innovation in security. The advancements in our FIPS 140-3 module highlight our commitment to delivering state-of-the-art cryptographic solutions that meet the rigorous demands of today’s cybersecurity landscape.” Stated wolfSSL CTO, Todd Ouska.

We are thrilled to work with ÆGISOLVE, INC. on this journey. The wolfSSL team is grateful for the ÆGISOLVE staff’s hard-work and dedication in realizing the very first SP800-140Br1 140-3 certificate in the world! A note from the ÆGISOLVE team:

“‘AEGISOLVE is pleased to announce the world’s first SP800-140Br1 compliant FIPS 140-3 Validation Certificate for wolfSSL’s wolfCrypt module’ reported Travis Spann, Founder and President of AEGISOLVE (NVLAP Lab Code: 200802-0).

‘As a first of its kind, this is a tremendous achievement and a huge step forward for the next generation of FIPS 140-3 Validated Cryptographic Modules. Congratulations, wolfSSL!


  • Boot Times
    • wolfCrypt FIPS 140-2, power-on times could be slower due to mandatory self-tests
    • wolfCrypt FIPS 140-3 requires self-tests only at the first algorithm use or during a slower event cycle
      • faster boot times
      • optimal power and resource consumption with careful planning!
  • Design
    • The wolfCrypt FIPS 140-3 validated module is the only commercial FIPS solution tailored for embedded
      • Emphasis on a minimal footprint, low resource use, reduced power consumption, and high performance for standard and real time systems
      • Design leads to superior scalability across devices, from mobile to server
        • 10 times more connections per device at 15-20% better performance than competing solutions.
  • OpenSSL Replacement
  • Embeddability
    • Embedded Systems (Medical, networking, sensors, security systems, etc.)
    • Extended Battery life and high performance
    • Hardware Encryption Support
    • Assembly Acceleration

Changes from the historic wolfCrypt FIPS 140-2 cert #3389 to the active wolfCrypt FIPS 140-3 cert #4718:

  • CAST (conditional algo self tests)
  • KDF-TLS, TLS v1.2 KDF and TLSv1.3 KDF
  • AES-OFB mode
  • RSA 3072, 4096 and PSS
  • New Degraded mode of operation in the event of a CAST failure other algorithm services will remain available.

For more about what FIPS is please checkout these blogs:

For information on transitioning from 140-2 to 140-3 please checkout our blog: What is the difference between FIPS 140-2 and FIPS 140-3?

Algo cert Link
Security Policy Link
Ref: Section 2.5 Algorithms
Ref: Section 2.2 Table 6 “Tested Operational Environments – Software, Firmware, Hybrid”
Cert #4718 Link

For questions, comments or feedback please contact the wolfSSL team anytime at

Download wolfSSL Now

Everything You Need To Know About FIPS 140-3

wolfSSL is currently the leader in embedded FIPS certificates. With current FIPS 140-3 validated certificate #4718 for the wolfCrypt Cryptographic Module, wolfSSL is thrilled to hold the world’s first SP800-140Br1-compliant FIPS 140-3 Validation Certificate. Join the wolfSSL team as we cover all things FIPS 140-3. We will cover the current transition to FIPS 140-3, its importance for cybersecurity, as well as how wolfSSL is implementing it in our products.

Watch the video: Everything You Need to Know about FIPS 140-3

FIPS 140-3 is the third revision of the Federal Information Processing Standard (FIPS) for cryptographic modules. The new revision of the standard includes an increased focus on algorithm agility, updated requirements for testing and validation, including changes to the testing methodology. wolfSSL is at the forefront of this important transition, and is working to ensure that its products continue to meet the highest standards of security and compliance.

FIPS 140-3 establishes the security requirements for cryptographic modules used by the U.S. government, as well as other organizations in the public and private sectors. By complying with the FIPS 140-3 standard, organizations can have greater confidence in the security of their cryptographic solutions, which is particularly important in today’s world where data breaches and cyber attacks are becoming more frequent and sophisticated.

If you have questions about any of the above, please contact us at or call us at +1 425 245 8247.

Download wolfSSL Now

What is FIPS (short version)

Doing FIPS responsibly since 2014!

FIPS is a set of standards, detailed in Special Publications, that need to be met to be awarded a FIPS validation/certification published on the NIST website.

A FIPS certificate, with the product listed in the certificate, is required to sell product(s) to medical, federal, or military agencies and is often required by some private sector entities as well.

The typical FIPS certification process is as follows:

  1. You send us your hardware and toolchain
  2. We run the initial tests which ensure the cryptography module behaves according to specification given your specific hardware and OS
  3. The CMVP certified lab runs and verifies the tests and their documentation
  4. The test results are submitted to NIST for review
  5. Your specific operating environment is added to our certificate
  6. You are FIPS 140 compliant in 60-90 days

For more info please see the long version of this post.

If you have any questions about FIPS or the process of being awarded a FIPS validation/certifcation please contact us at, or +1 425 245 8247 anytime. We offer free pre-sales customer support, we have FIPS evaluation options and our staff are knowledgeable and eager to help!

Download wolfSSL Now

What is FIPS (long version)

Doing FIPS responsibly since 2014!

INTRO (wolfSSL FIPS service(s)):

(skip to next paragraph for “What is FIPS”)

FIPS is rightly viewed as a complex process with a steep entry learning curve. Lucky for customers of wolfSSL Inc. our management and engineering team have taken the time to learn the documentation surrounding the topic and developed all the tooling necessary to complete FIPS validation testing of the wolfCrypt cryptographic module in coordination with an NVLAP accredited FIPS lab. In order to FIPS validate a new product or operating environment (OE), wolfSSL asks for simply a customer’s hardware, compiler/toolchain (IDE etc), and a guide such that one of our FIPS developers can sit down with nothing but a laptop and achieve compiling and running a hello-world.c application on the target product to be FIPS validated. Yes you read that right, wolfSSL does not need your proprietary application software, just a hello-world.c application to get started. The CMVP validates the cryptographic module running on the target, not the applications that are consuming that cryptographic module. The wolfSSL team will standup the wolfCrypt module on your target product and take it through the certification process as quickly as possible leaving your dev team free to focus on preparing the end product while FIPS certification is taking place simultaneously!


Since there are so many options for securing information, the U.S. and Canadian governments recognized in the 1990’s a need to standardize those algorithmic methods deemed to be the most secure and enforce use of only those algorithms in critical government systems. To “encourage” adoption of the requirements by the two governments, the organizations NIST (National Institute of Standards and Technology)¹ and the CCCS (Canadian Centre for Cyber Security)² were called upon to fulfill that mission. The two agencies were to collaboratively:

  1. Decide which algorithms were the best/strongest
  2. Evaluate: If an algorithm had multiple modes or key lengths which modes or key lengths (if any) were considered too weak and should be excluded?
  3. Determine if there were other requirements aside from just having the algorithms implemented correctly
    1. Did the algorithms NEED to be re-tested periodically? (IE as the device was powering up)
    2. Did the module need to be checked periodically to see if it had been tampered with since the factory? (IE an integrity check, etc)
  4. Finally to enforce/encourage adoption of these standards by federal agencies belonging to either government. (Eventually expanded to include medical and some private entities as well)

These standards were called the “Federal Information Processing Standards” or FIPS. These standards were documented in a series of “Special Publications” (SP’s).

Out of a need to document which cryptographic modules and vendors were abiding by the standards set forth, a “certification” program was decided as the best approach. Vendors who made cryptographic modules could submit for and be awarded a certificate if their module was found to be compliant with all standards applicable to that module. The certificates would be hosted on the U.S. based NIST website so that federal agencies (or the public) could “browse” the available FIPS certified modules.

It was a big job for the two agencies to handle alone, so in 1995 NIST and CCCS established two organizations called the “CMVP” (Cryptographic Module Validation Program)³ and CAVP (Cryptographic Algorithm Validation Program)? to handle testing Cryptographic modules for compliance with the standards. These two organizations would also handle issuing the certificates for vendors and products that passed algorithm testing and were found to meet all applicable standards outlined in the SP’s.

The CAVP issues algorithm certificates (which are a prerequisite to submitting a module for FIPS certification to the CMVP). The CMVP issues FIPS certificates for “tested configurations” or “operating environments” found to pass the CAVP testing and be in compliance with the standards. Both certificate types (CAVP algo certs and CMVP FIPS certs) are hosted on the NIST website. The certificates are public domain and can be searched by anyone.

Once established, the CMVP and CAVP needed to establish a way to “test” the modules. To that end they called upon the NVLAP (National Voluntary Laboratory Accreditation Program)? to accredit “third-party” testing laboratories that would serve as an intermediary between the vendors seeking FIPS certification and the CAVP/CMVP bodies.

A last step in the history of FIPS was adoption of software modules. Originally when the standards were written, only dedicated hardware could perform the heavy lifting necessary for cryptographic mathematical operations so the standards were designed with ONLY hardware modules in mind. Doing cryptography in software at the time was impractical and therefore not considered in the original standards. As general purpose CPUs advanced, eventually it became feasible to implement algorithms in software and have those expensive math operations executed by a general purpose CPU in a reasonable amount of time. Once this reality arrived the standards were “adapted” to allow for both hardware and software modules. To this day there are “some scenarios” in the standards that only seem to make sense for hardware (See our blog post on vendor affirmation and how some software vendors are exploiting a loophole in the standards that was intended for hardware). NIST, the CMVP and CAVP have done a lot of work in the past few years bringing about the latest 140-3 standards and wolfSSL Inc is very excited to be one of the first software modules with a commercial FIPS 140-3 offering!

The Process (validating a module):

Today a hardware or software vendor will work in coordination with an NVLAP accredited lab to complete algorithm testing and receive algorithms certificates.

(Milestone 1 of a FIPS certification effort)

Once the vendor receives the prerequisite CAVP certificates they will perform operational testing with the same NVLAP accredited lab. Once all testing evidence has been captured and everything reviewed and approved by the NVLAP quality assurance department, the lab is ready to submit everything to the CMVP.

(Milestone 2 of a FIPS certification effort)

The CMVP will coordinate with the vendor via the NVLAP accredited lab and once all requirements have been satisfied the CMVP will either issue a new FIPS certificate or update an existing certificate if the vendor is adding an operating environment to an existing certificate.

(Milestone 3 of a FIPS certification effort)

Submission Scenario(s) supported by wolfSSL Inc:

  • New cert (draw a new module boundary around specific algorithms and certify from scratch resulting in a new certificate)
  • OE addition (Add an OE to an existing certificate)
  • Revalidation (redraw the module boundary of an existing validated module to include new or remove existing algorithms from the boundary description)
  • Vendor Affirmation – wolfSSL is a software module vendor. As a responsible FIPS vendor wolfSSL feels that software vendors are generally incapable of determining how a change to the CPU or OS will affect the cryptography (especially if the CPU or OS changes completely). As such wolfSSL Inc does not currently offer Vendor Affirmation as a path to FIPS. Special circumstances MAY exist but would need to be evaluated on a case-by-case basis.

Timeline estimates for the various scenarios change over time. If you would like an up-to-date estimate for a given submission scenario please contact for the latest.


  • wolfSSL Inc can make the process of certifying your product painless and hands-free once we have the product and basic instructions for getting a hello-world app up and running on the target!
  • FIPS is a set of standards, detailed in Special Publications, that need to be met in order to be awarded a FIPS validation/certification published on the NIST website. A FIPS certificate, with the product listed in the certificate, is required to sell product(s) to medical, federal or military agencies and often required by some private sector entities as well.
  • The process can take time so please plan accordingly!

If you have any other questions about FIPS or the process or wolfSSL Inc please contact either or anytime. We offer free pre-sales customer support, we have FIPS evaluation options and our staff are knowledgeable and eager to help!

¹ The National Institute of Standards and Technology (NIST) was founded in 1901 and is now part of the U.S. Department of Commerce. NIST is one of the nation’s oldest physical science laboratories. To promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life. –

² The Cyber Centre is the single unified source of expert advice, guidance, services and support on cyber security for government, critical infrastructure owners and operations, the private sector and the Canadian public. –

³ The Cryptographic Module Validation Program (CMVP) is a joint effort between the National Institute of Standards and Technology under the Department of Commerce and the Canadian Centre for Cyber Security, a branch of the Communications Security Establishment. The goal of the CMVP is to promote the use of validated cryptographic modules and provide Federal agencies with a security metric to use in procuring equipment containing validated cryptographic modules. –

? The CAVP was established in July 1995 by NIST and the Government of Canada’s CCCS. CSD’s Security Testing, Validation, and Measurement Group (STVMG) manages the validation testing of cryptographic modules and their underlying cryptographic algorithms through the CAVP and CMVP. –

? The National Voluntary Laboratory Accreditation Program (NVLAP) provides third-party accreditation to testing and calibration laboratories in response to legislative actions or requests from government agencies or private-sector organizations. NVLAP-accredited laboratories are assessed against the management and technical requirements published in the International Standard, ISO/IEC 17025:2017. –

If you have questions about any of the above, please contact us at or +1 425 245 8247.

Download wolfSSL Now

What is the difference between FIPS 140-2 and FIPS 140-3?

This week we are tackling the question: what is the difference between FIPS 140-2 and FIPS 140-3? wolfSSL is currently the leader in embedded FIPS certificates. The wolfCrypt module holds the world’s first SP800-140Br1 FIPS 140-3 validated certificate #4718. We always strive to keep our users up to date on the latest standards!

With various specification updates, the newest standard of FIPS 140-3 will include the hardware module, firmware module, software module, hybrid-software module, and hybrid-firmware module and will have no restriction as to the level at which a hybrid module may be validated in the new standard. This is beneficial to vendors with hybrid modules looking to be validated at a higher level than level 1. FIPS 140-2 standard was originally written with all modules as hardware and only later were additional modules added.

While both FIPS 140-2 and FIPS 140-3 include the four logical interface data input, data output, control input, and status output. FIPS 140-3 introduces a fifth interface, called the control output interface for the use of output of commands including signals and control data to indicate the state of operation. Instead of the use of a “trusted path” used in FIPS 140-2, FIPS 140-3 uses a “trusted channel” which is a secure communications link between the cryptographic module and the end point device which is sending data to and receiving data from the module, with the goal of securing unprotected CSPs. In FIPS 140-3, the Level 4 module using a trusted channel must use multi-factor identity-based authentication for all services using the trusted channel.

Instead of requiring module support for crypto officer and user roles with the maintenance role as optional, FIPS 140-3 only requires the crypto officer role. There is a new capability within FIPS 140-3, called the “Self-Initiated Cryptographic Output Capability” where a module can perform cryptographic operations or other approved security functions without any operator intervention.

Check out our latest blog post on FIPS 140-3 Announcement to the world.

When it comes to wolfSSL, we are ready to offer the first implementation of FIPS 140-3:

  • The power-on self-test is changing. It now takes two sets of tests: the Pre-operational Self-Test (POST) and the Conditional Algorithm Self-Test (CAST).
  • The old Known Answer Tests used as a part of the old test are not required to run at startup. They are now conditional tests that must be run right before use of an algorithm. If you don’t use an algorithm, you don’t need to test it. The tests will run automatically on calling any API for an algorithm.
  • The pre-operational self-test is now purely an integrity test of the executable in memory. The algorithms used for this test must be tested first. In our case, HMAC-SHA-256’s CAST is run automatically, then the POST. The POST will be run automatically as wolfCrypt’s default entry point in the code.
  • All the tests may be and should be run periodically during run time. We will provide an API to run tests as desired. In an embedded application, you can run your CAST early before any algorithms are used as some CASTs do take time.

Contact Us

Please contact us at or +1 425 245 8247 with any questions. For technical support, please contact or view our wolfCrypt FIPS FAQ page.

Download wolfSSL Now

Live Webinar: World’s first SP800-140Br1 FIPS 140-3 validated certificate #4718

We are thrilled to announce a landmark achievement in cybersecurity! wolfSSL has obtained the world’s first SP800-140Br1 FIPS 140-3 validated certificate #4718. This milestone is a testament to our commitment to providing top-notch security solutions. To celebrate, wolfSSL Senior Software Engineer, Kaleb Himes, is hosting an exciting webinar, “World’s first SP800-140Br1 FIPS 140-3 validated certificate #4718”, on July 18th at 10am PT!

Register today for “World’s first SP800-140Br1 FIPS 140-3 validated certificate #4718

This Webinar Will Cover:

  • World’s first SP800-140Br1 FIPS 140-3 validated certificate #4718: Understand the significance of this groundbreaking achievement.
  • OpenSSL compatibility: Learn about the integration and benefits of our solutions with OpenSSL, including Provider and Engine support.
  • Java JSSE/JCE provider: Discover how our FIPS-validated solutions work seamlessly with Java security frameworks.
  • Commercial FIPS offering: Explore the only embedded general-purpose commercial FIPS solution available in the market.
  • Expert Team: Connect with industry experts at wolfSSL who make all this possible. We are here to help you navigate the complexities of FIPS certification and implementation.

Don’t miss out on this opportunity to be a part of cybersecurity history. Kaleb will provide valuable insights, practical knowledge, and a chance to interact with industry experts. Register now and secure your spot in this exciting event.

As always, our webinars include Q&A sessions. If you have questions about any of the above, please contact us at or +1 425 245 8247.

Download wolfSSL Now

wolfSSL 5.7.2 Now Available!

wolfSSL release 5.7.2 is now available! This release includes an implementation of Dilithium, optimizations for RISC-V use, AES-XTS streaming capabilities, and quantum safe algorithm support with the Linux kernel module, to name a few of the recent additions. There have also been other enhancements, such as STM32 AES hardware support for STM32H5 and SHA-3 ARM thumb assembly implementations. Along with these amazing features and enhancements, some great fixes and additional sanity checks were added. One of the additional sanity checks limits the maximum number of alternate names parsed with certificates. This defaults to 128 but can be changed by defining the macro WOLFSSL_MAX_ALT_NAMES to any desired value. A full list of vulnerability fixes, feature additions, and general changes can be found in the bundled with wolfSSL or in the main

If you have questions about any of the above, please contact us at or +1 425 245 8247.

Download wolfSSL Now

Integrating lwIP with wolfCrypt and IPSec

The lwIP project is a great, lightweight TCP/IP stack implementation, with widespread use in the embedded world. Users of lwIP and wolfSSL know that we have long supported an lwIP integration, which allows wolfSSL to handle the TLS layer while lwIP handles network input/output.

Similarly, we support a wolfSentry integration with lwIP, that allows wolfSentry to function as a dynamic firewall and IDPS for lwIP.

But what if you wanted to combine lwIP with IPSec? Furthermore, what if you wanted wolfCrypt to handle the IPSec cryptographic operations in such a combination?

If you’re curious about lwIP, wolfCrypt, and IPSec, or have questions about any of the above, please contact us at or +1 425 245 8247.

Download wolfSSL Now

wolfBoot 2.1.0 released

wolfBoot is our secure bootloader designed to provide safety-oriented secure boot for any embedded device. Its success lies in its ability to offer security, efficiency and adaptability to many different use cases, while keeping a simple and safe design. wolfBoot is a solid choice made by many developers securing the boot mechanism on a wide range of embedded devices from every industry.

A new version of wolfBoot (v2.1.0) has been released, which introduces new features, support for more cryptography, ports to new embedded targets and improvements to existing code.

Download wofBoot 2.1.0 from our download page or clone it from github.

Support for custom fields in the manifest header

One of the most requested features by our users consisted in allowing extra parameters in the manifest header of the firmware/software images to be verified.

wolfBoot manifest header consists in a sequence of “TLV” (table-length-value) fields. By default, a signed image’s manifest header contains a SHA digest, the public-key signature itself, and a few extra fields containing metadata relative to the image and the sign process. These fields include a 32-bit version number (used to prevent rollback attacks), a 64-bit timestamp, a digest of the public key needed to verify the signature, a ‘type’ field, used by the bootloader to identify and confirm the algorithms used and the destination partition for the update.

All these fields in the manifest headers, except for the digest and the signature itself, are included in the calculation of the signed digest, which means that their values cannot be altered without compromising the validity of the signature.

The new feature introduced in wolfBoot 2.1.0 consists in three new mechanism that can be used to add new TLVs to the header:

  • –custom-tlv tag len val
    Adds a TLV entry to the manifest header, corresponding to the type identified by “tag”, with length “len“ bytes, and assigns the value “val”.Values can be decimal or hex numbers (prefixed by ‘0x’). This is useful to add numeric values (e.g. with length 1, 2, 4, or 8).
  • –custom-tlv-buffer tag len buffer
    Adds a TLV entry with a buffer in hex format,
    e.g. –custom-tlv-buffer 0x31 6 CCBBAA998877
  • –custom-tlv tag string
    Adds a TLV containing a string of bytes read as ASCII characters from the “string” argument. In this case the length is implicit as the argument is null-terminated.

As usual, these fields can be accessed from wolfBoot custom modules, using the wolfBoot_find_header() parser. This function is included in libwolfboot, which means that the same parser can be invoked on any stored signed image by applications integrating the library.

New signature verification algorithm

ECC521 support has been added, further expanding the range of cryptographic algorithms available for signature verification, bolstering security for a broader spectrum of applications (and did you know that since v2.0 wolfBoot also supports post-quantum signature verification algorithms too?).

Support for new embedded platforms

We facilitate the process to integrate new ports of wolfBoot, which includes the integration of an example application to demonstrate secure boot and update out-of-the-box, with a single build command. This version introduces support for new embedded targets:

  • Renesas RZ2NL
  • Microchip SAM E51
  • NXP MCXA-153
  • NXP i.MX-RT1040

Improvements and enhancements

Version 2.1.0 addresses various bugs and introduces enhancements for existing platforms and target-specific mechanisms.

For targets supporting the DUALBANK option, i.e. the ability to swap the mapping of two “banks” inside the same flash memory support, we added some additional checks to ensure that wolfBoot copies (or “forks”) itself to the second bank only once in the lifetime of the bootloader.

For those use-cases with backup disabled, we have simplified the update mechanism, which also improved the reliability of the update across power-failures.

We have fixed an issue in the wolfTPM integration code, which was preventing the policy from being properly sealed. This issue is only affecting those configurations including the `WOLFBOOT_TPM_SEAL` option introduced in version 2.0.0.

Contacts Us

Let us know what features you value the most, what platforms you would like to see our code running on, or just tell us your story about secure-boot in your embedded systems.
If you have questions about any of the above, please contact us at or call us at +1 425 245 8247.

Download wolfSSL Now

Don’t Miss Out: wolfBoot security on the STM32H5 with PQC Webinar

Learn about the advanced security features of the STM32H5 microcontroller and how wolfBoot enhances these capabilities, including support for Post Quantum Cryptography.

Register today for “wolfBoot security on the STM32H5 with PQC.”
Date: July 10th | 9 am PT

wolfSSL is excited to announce that wolfBoot, our secure bootloader, now supports the STM32H5 microcontroller series. This integration brings robust secure boot features and efficient update mechanisms to the STM32H5, following RFC9019 guidelines for a reliable secure boot solution.

The STM32H5 series excels within the STM32 family with superior performance and security. Built around the Arm Cortex-M33 core, it provides a notable boost in computational power and efficiency. Featuring TrustZone-M technology, it offers hardware-assisted isolation between secure and non-secure domains, enhancing security and simplifying secure application development. The series includes up to 2 MB of flash memory and 640 KB of SRAM, ideal for complex applications. Its dual-bank flash architecture enables quick firmware updates. Equipped with advanced cryptographic accelerators and a cryptographic-grade TRNG, the STM32H5 series is perfect for secure, high-performance embedded applications.

wolfBoot extends its support within the STM32 family by including target-specific security features offered by the STM32H5 series. Explore these features and their role in a system secured using wolfBoot, wolfCrypt, and wolfPKCS11.

During this webinar, attendees will learn about:

  • STM32H5 Security Features
  • wolfBoot Secure Boot Solution
  • TrustZone with PKCS11
  • Post Quantum Cryptography
  • Dual Bank Swap, OTP for RoT, HW TRNG
  • Live Demonstration

Register Now

As always, our webinar includes Q&A throughout. If you have questions about any of the above, please contact us at or call us at +1 425 245 8247.

Download wolfSSL Now

Dilithium vs. Falcon

Recently, more and more attention has been focused on post-quantum key encapsulation mechanism (KEM) algorithms due to the “Harvest Now, Decrypt Later” threat model. But we here at wolfSSL know that post-quantum signature schemes also deserve a lot of attention as there is a tendency for signing keys to have long lifetimes. As such, today we’d like to delve a bit deeper by comparing Dilithium (also known as ML-DSA) and Falcon (also known as NL-DSA); 2 signature schemes slated for standardization.

Both algorithms are based on lattice-based cryptography and depend on the hardness of finding short vectors in a lattice. The difference is that Dilithium uses module vector spaces while Falcon uses NTRU lattices. The math gets very complicated very quickly; please see the webpage for the algorithms for further details:

Implementing them is very different. For example, Dilithium can be implemented with only integer arithmetic whereas falcon requires floating point arithmetic. This difference in difficulty has resulted in a delay in Falcon’s standardization process. While Dilithium is slated for standardization in the summer of 2024, the draft standard for Falcon hasn’t even been published yet as NIST wants to be very cautious writing it.

Finally, the cryptographic artifact sizes are significantly different.

Dilithium-2 Falcon-1 Dilithium-3 Dilithium-5 Falcon-5
Private Key 2528 1281 4000 4864 2305
Public Key 1312 897 1952 2592 1793
Signature 2420 752 3293 4595 1462

Note that the units listed here are in bytes and the number after the algorithm name on the top row denotes the claimed security levels.

As you can see, Falcon’s artifact sizes are all smaller than Dilithium’s, but are still fairly large compared to ECDSA artifacts. This is why we suggest our customers get started early integrating these algorithms into their systems. You need to know how these larger artifact sizes are going to affect data transmission times and network throughput. How with this cascade into user experience and resource requirements?

Get started by having a conversation with us! If you have questions about any of the above, please contact us at or call us at +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2 3 4 178 179 180

Weekly updates