wolfCrypt now includes a native implementation of Falcon-512 and Falcon-1024, the lattice-based post-quantum signature algorithm selected by NIST for upcoming standardization as FN-DSA.
The new implementation replaces wolfSSL’s previous liboqs-based Falcon integration. Falcon is now built directly into wolfCrypt, removing the external dependency while improving portability, hardware integration, and control across desktop, embedded, and kernel environments.
Why Native Falcon?
The original Falcon support used a wrapper around liboqs. That provided a useful path for early adoption, but it limited how closely Falcon could integrate with wolfCrypt and added a large external dependency.
Native Falcon provides several benefits:
- No external liboqs dependency
- Support for embedded and Linux kernel environments
- Integration with wolfCrypt crypto callbacks and hardware offload
- Accelerated options for x86-64 and ARM
- Smaller builds for embedded deployments
- Verify-only and reduced-memory configurations
Falcon was the final post-quantum algorithm in wolfCrypt that still depended on liboqs. With this update, wolfSSL’s supported post-quantum algorithms are implemented directly within wolfCrypt.
From Falcon to FN-DSA
Falcon was selected by NIST alongside the algorithms that became ML-KEM, ML-DSA, and SLH-DSA.
NIST is developing FIPS 206 under the name FN-DSA, short for FFT over NTRU-Lattice-Based Digital Signature Algorithm. NIST presented details of the developing FIPS 206 standard at its Sixth Post-Quantum Cryptography Standardization Conference in September 2025. At the time of writing, FIPS 206 remains in development and an Initial Public Draft has not yet been published.
Because FN-DSA standardization is not yet complete, the current wolfCrypt API remains provisional. Applications currently use the wc_falcon_* functions and the span style=”font-family:courier new;”>falcon_key type, but these names may change when the final FN-DSA standard is available.
For this reason, enabling Falcon requires activating wolfSSL’s experimental settings.
Designed for Multiple Platforms
Falcon presents an unusual implementation challenge because signing and key generation use floating-point-style arithmetic, while verification relies primarily on integer operations.
wolfCrypt provides different build options so applications can select the right balance of portability, performance, memory use, and side-channel protection.
The default configuration uses an integer-emulated arithmetic backend. It avoids floating-point registers and is suitable for Linux kernel builds, processors with or without a double-precision FPU, and smaller devices such as Cortex-M microcontrollers.
Accelerated configurations are also available using native double-precision arithmetic, x86-64 assembly, AVX2, and AArch64 NEON. On supported Cortex-M processors, ARM DSP instructions accelerate the integer verification path.
Falcon also integrates with wolfCrypt’s standard WOLF_CRYPTO_CB interface. Key generation, signing, and verification can be routed to a secure element, hardware accelerator, or application-defined cryptographic provider, with software fallback when appropriate. Callback-only builds are also supported for applications that require Falcon operations to remain entirely inside a hardware device.
Performance and Embedded Footprint
On an AMD Ryzen 9 7950X3D, the accelerated wolfCrypt configuration performed competitively with liboqs 0.15.0.
Falcon-512
| Operation | wolfCrypt accelerated | liboqs |
|---|---|---|
| Key generation | 4.32 ms | 4.31 ms |
| Signing | 0.124 ms | 0.143 ms |
| Verification | 0.020 ms | 0.025 ms |
Falcon-1024
| Operation | wolfCrypt accelerated | liboqs |
|---|---|---|
| Key generation | 12.83 ms | 12.86 ms |
| Signing | 0.270 ms | 0.290 ms |
| Verification | 0.043 ms | 0.048 ms |
In these measurements, accelerated wolfCrypt signing was approximately 7–13 percent faster than liboqs. Verification was also faster at both Falcon security levels.
The default integer-emulated configuration is slower during signing and key generation, but it provides an alternative for applications that prioritize constant-time arithmetic and avoiding floating-point register use.
The native implementation also performs well on embedded targets. On an STM32H563 Cortex-M33 running at 250 MHz, wolfCrypt completed key generation, signing, and verification for both Falcon-512 within comparable times as the reference liboqs implementation, and with Falcon-1024, where the test fails to complete on 32bit arm with the reference code.
The full wolfCrypt Falcon build used approximately 77.1 KB of code, compared with 140.3 KB for the tested liboqs configuration—a reduction of roughly 45 percent. A verification-only wolfCrypt build required approximately 17.3 KB of code and 3.1 KB of static memory.
There was also a practical difference at Falcon-1024. On the same 32-bit ARM target, the PQClean clean implementation used by liboqs could generate keys, but its private-key validation rejected every generated key when signing was attempted. This made Falcon-1024 signing unusable on that target, while the native wolfCrypt implementation completed the full key-generation, signing, and verification flow.
Building Falcon
Enable the default native implementation with:
./configure --enable-experimental --enable-falcon
Additional options can select an accelerated or reduced-memory configuration:
# Native double-precision arithmetic ./configure --enable-experimental --enable-falcon=double # x86-64 AVX2 acceleration ./configure --enable-experimental --enable-falcon=avx2 # AArch64 NEON acceleration ./configure --enable-experimental --enable-falcon=neon # Reduced-memory signing ./configure --enable-experimental --enable-falcon=small-mem
Compatible options can be combined:
./configure --enable-experimental --enable-falcon=avx2,small-mem
Applications that only require signature verification can define WOLFSSL_FALCON_VERIFY_ONLY (or –enable-falcon=verify-only) to remove native key generation and signing from the build.
API Example
#includefalcon_key key; byte sig[FALCON_LEVEL1_SIG_SIZE]; word32 sigLen = sizeof(sig); int verified; wc_falcon_init(&key); wc_falcon_set_level(&key, FALCON_LEVEL1); wc_falcon_make_key(&key, &rng); wc_falcon_sign_msg( msg, msgLen, sig, &sigLen, &key, &rng); wc_falcon_verify_msg( sig, sigLen, msg, msgLen, &verified, &key); wc_falcon_free(&key);
The same API supports Falcon-1024 by selecting FALCON_LEVEL5. Production applications should check each return value and clean up resources on all error paths.
Native Post-Quantum Signatures for More Platforms
Native Falcon gives wolfSSL users a practical way to evaluate Falcon and prepare for FN-DSA without depending on liboqs to their applications.
Desktop and server applications can select accelerated implementations, while embedded and kernel applications can use the integer-emulated backend without relying on floating-point hardware. Verify-only, reduced-memory, and hardware-backed configurations provide further flexibility for constrained or security-sensitive deployments.
Falcon support remains experimental while NIST completes FIPS 206 and the FN-DSA standard. Developers can begin testing the algorithm today while preparing to migrate to the finalized FN-DSA naming and formats when they become available. However, keep in mind that the final FN-DSA support will be updated (and the API likely will be subject to changes) when FIPS 206 is published.
For questions about Falcon, FN-DSA, or post-quantum cryptography with wolfSSL, contact us at facts@wolfssl.com or call +1 425 245 8247.
Download wolfSSL Now