A Lightweight Variant of Falcon for Efficient Post-Quantum Digital Signature

Abstract

Conventional public-key cryptographic systems are increasingly threatened by advances in quantum computing, accelerating the need for robust post-quantum cryptographic solutions. Among these, Falcon, a compact lattice-based digital signature scheme, has emerged as a leading candidate in the NIST post-quantum standardization process due to its efficiency and theoretical security grounded in hard lattice problems. This work introduces Falcon-M, a modified version of the Falcon algorithm that significantly reduces implementation complexity. It does so by replacing Falcon’s intricate trapdoor-based key-generation mechanism with a simplified approach that utilizes randomized polynomial Gaussian sampling and fast Fourier transform (FFT) operations. Falcon-M incorporates SHA-512 hashing and discrete Gaussian sampling to preserve cryptographic soundness and statistical randomness while maintaining the core structure of Falcon’s signing and verification processes. We formally specify the Falcon-M algorithm, provide an updated pseudocode, and offer a comparative analysis with the original Falcon in terms of algorithmic complexity, security assumptions, and implementation overhead. Additionally, we present formal lemmas and theorems to ensure correctness and define theoretical bounds on forgery resistance. Although Falcon-M does not rely on a formal cryptographic trapdoor, we demonstrate that it achieves strong practical security based on assumptions related to the Short Integer Solution (SIS) problem. Falcon-M is thus well-suited for lightweight post-quantum applications, particularly in resource-constrained environments, such as embedded systems and Internet-of-Things (IoT) platforms.

1. Introduction

Classical public-key cryptographic primitives—such as RSA, DSA, and ECDSA—underpin the vast majority of secure digital communications. However, they are increasingly vulnerable to quantum computing threats [1]. These systems rely on the computational hardness of problems like integer factorization and discrete logarithms, both of which can be efficiently solved in polynomial (Gaussian) time using Shor’s algorithm. In anticipation of this paradigm shift, the field of post-quantum cryptography (PQC) focuses on developing cryptographic systems that remain secure against quantum adversaries. Among the proposed approaches, lattice-based cryptography has attracted significant attention due to its strong theoretical foundations, asymptotic efficiency, and resilience to known quantum attacks [2,3,4,5].

Within this domain, Falcon (Fast-Fourier Lattice-based Compact Signatures over NTRU) has emerged as a finalist in the National Institute of Standards and Technology (NIST) post-quantum standardization process [6].

Falcon leverages structured NTRU lattices and the fast Fourier transform (FFT) to achieve a compelling balance of compactness, computational efficiency, and cryptographic robustness [7].

However, its key-generation process introduces notable complexity, involving the solution of the NTRU equation and the construction of recursive trapdoor structures.

These tasks require high-precision arithmetic and significant computational resources [8], posing a barrier to deployment on constrained environments such as embedded systems and Internet-of-Things (IoT) devices [9].

While Falcon remains a well-engineered and secure post-quantum signature scheme, its key generation phase is not well-suited for platforms with limited memory or no hardware floating-point support.

For instance, implementing the full Falcon on an ARM Cortex-M4 processor (32-bit, 80 MHz, 64 KB RAM) reveals that recursive basis constructions frequently exceed memory limitations [10].

The algorithm’s reliance on floating-point operations and deep recursion leads to excessive stack usage, making it impractical for microcontrollers with less than 128 KB of RAM or without a floating-point unit (FPU).

To address these limitations, Falcon-M introduces a modified approach that replaces recursive trapdoor-based key generation with a simplified process based on randomized polynomial selection and FFT operations. This significantly reduces both memory usage and computational overhead, making Falcon-M more suitable for IoT, edge computing, and other resource-constrained authentication applications [11].

In this work, we present Falcon-M—a streamlined variant of the Falcon signature scheme—specifically designed to overcome the practical constraints of embedded and lightweight environments.

Falcon-M eliminates the use of structured trapdoors in key generation, instead relying on fast Fourier transform operations and randomly selected polynomials [12].

Despite its simplified design, Falcon-M retains the core cryptographic structure of the signature generation and verification processes of Falcon [13].

The result is a lightweight, resource-efficient digital signature scheme that is consistent with the essential goals of post-quantum security [13].

Background on Falcon

Falcon (Fast-Fourier Lattice-based Compact Signatures over NTRU) is a digital signature scheme based on lattices that is intended to be safe after quantum computers are used [14]. It uses structured trapdoor constructions to facilitate the sampling of short vectors and is based on the hardness of NTRU lattices. Falcon employs FFT and inverse FFT (IFFT) operations for key generation and signing. It is known for its small signatures and high throughput [15].

However, Falcon’s key generation requires solving the NTRU equation, which involves recursive basis construction and high-precision floating-point arithmetic. This adds a significant amount of extra work, especially on devices with limited resources. Falcon is one of the most efficient schemes in theory and is a finalist in the NIST PQC process [6]. However, it is difficult to implement on lightweight systems because of stack usage, floating-point dependencies, and memory limits [10].

2. Materials and Methods

2.1. The Original Falcon Algorithm

Redundant Background Sections

Falcon (Fast-Fourier Lattice-based Compact Signatures over NTRU) is a digital signature scheme based on lattices that is intended to be safe after the advent of quantum computers [14].

It is based on the hardness of NTRU lattices [7] and uses structured trapdoor constructions to facilitate the sampling of short vectors [14].

Falcon uses fast Fourier transform (FFT) and inverse FFT operations to create keys and sign documents [15]. It is known for its small signatures and high throughput [15].

However, Falcon’s key generation requires solving the NTRU equation, which involves recursive basis construction and high-precision floating-point arithmetic [13]. This introduces a significant computational overhead, particularly for resource-constrained devices [10].

Falcon is a finalist in the NIST PQC process [6] and remains one of the most efficient schemes in theory. However, it is difficult to use on lightweight systems because of stack usage, floating-point dependencies, and memory limits [10].

2.2. Proposed Falcon-M Algorithm

Falcon-M simplifies the key generation step of the Falcon digital signature scheme by replacing complex trapdoor constructions with random polynomials and fast Fourier transform (FFT) operations to derive the public key [11]. This reduces the implementation complexity while maintaining compatibility with the signing and verification framework of Falcon [13].

2.3. A Comparison of Falcon and Falcon-M

Table 1. Structural and computational comparisons of Falcon and Falcon-M.

Metric	Falcon	Falcon-M
Key Generation Method	Structured Trapdoor	Random Polynomials
FFT Required	Yes	Yes
Floating-Point Arithmetic	Yes (double-precision)	No
Key Generation Time (ms)	3.1	1.8
Signature Size	Compact	Compact

shows how the original Falcon and Falcon-M differ in terms of important cryptographic and performance-related features:

2.4. Overview of Falcon-M

Falcon-M streamlines the key-generation phase of the original Falcon scheme [11]. Rather than solving the NTRU equation to build a trapdoor, it generates two random polynomials and combines them via the FFT to produce the public key [12]. This approach aims to retain the structural and security principles of lattice-based cryptography while significantly reducing the complexity of key generation [11].

2.5. Falcon-M Key Generation

Falcon-M specifies a basic generation mechanism as follows:

• Choose two polynomial terms, a(x) and b(x), of degree n − 1 at random from integer coefficients ranging from −100 to 100.
• Calculate the fast Fourier transform:
• A(ω) = FFT(a(x)), B(ω) = FFT(b(x))
• Inverse Fourier transform forms the public key h(x)
• h(x) = IFFT(A(ω) × B(ω)) mod q, where q is a prime modulus (e.g., q = 12,289) [16].

2.6. Signature Generation

• To sign a message m:
• Determine the hash H(m) = SHA-512(m) mod q.
• Create a short random vector s close to H(m) by applying a simple random or Gaussian distribution.
• Determine the signature polynomial by computing:
  σ = IFFT(FFT(s)) mod q [16].

2.7. Signature Verification

• Verification of a signature starts as follows:
• Calculate the message hash H(m) again.
• Calculate:
• y = IFFT(FFT(h(x)) × FFT(σ)) mod q.
  If y is sufficiently close to H(m) within an allowed margin δ, accept the signature [14].

2.8. Key Parameters

Table 2. Falcon-M scheme’s primary parameters [13].

Parameter	Value
Polynomial degree n	512
Modulus q	12,289
Hash function	SHA-512
Threshold δ	Approx. 10–20

provides a summary of the primary parameters of the Falcon-M scheme.

By defining modular arithmetic, polynomial structure, and acceptable thresholds for signature verification, Falcon-M strikes a balance between security and efficiency [13].

Section 3.2 provides an explanation for the selection of these parameters.

3. Results

This section provides a clear and accurate account of the experimental findings, their interpretations, and the resulting inferences.

3.1. Overview of the Falcon Algorithm

The NTRU lattice framework introduced in [7] serves as the foundation of Falcon.

This section provides an organized summary of the proposed modification to the Falcon digital signature scheme, referred to as Falcon-M. Before presenting the details of our modification, we briefly review the original Falcon protocol. We then highlighted the key differences between Falcon and Falcon-M.

Falcon (Fast-Fourier Lattice-based Compact Signatures over NTRU) is a lattice-based digital signature scheme designed for post-quantum cryptography [14]. It achieves compactness and computational efficiency by employing structured NTRU lattices and an optimized sampling method based on the fast Fourier transform [15]. The main stages of the Falcon signature protocol are as follows:

• Key Generation: Provides a trapdoor basis by solving the NTRU equation f·h = g mod q [14].
• Signature Generation: Hashing is used to convert the message into a lattice point, and a Gaussian sampler (using fast Fourier transform-based sampling) is used to produce a succinct signature vector [17].
• Signature Verification: Uses public key polynomials to confirm that the signature is clear and matches the hashed message [14].

Based on the difficulty of lattice problems, such as Learning With Errors (LWE) and the Short Integer Solution (SIS), Falcon has been proven to be safe [4,5]. Within the quantum random oracle paradigm, Falcon achieves the performance shown in

Table 3. Falcon performance (based on results from [14,15,17]).

Version	Key Generation Time (ms)	Throughput (Signatures/s)	Throughput (Checks/s)	Signature Size (Bytes)
Falcon-512	8.64	5948.1	27,930	666
Falcon-1024	27.45	2913.0	13,650	1280

.

3.2. Cryptographic Properties of Falcon-M

The accuracy, efficiency, and security assumptions of the Falcon-M signature scheme’s cryptography are examined in this section.

A digital signature technique must ensure that the corresponding public verification algorithm can identify all authentic signatures generated using a precise private key.

Let ‘σ’ represent a signature generated with the private key ‘(a(x), b(x))’ on the message ‘m’.

Let ‘h(x)’ represent the computed public key as follows:

h(x) = IFFT(FFT(a(x))·FFT(b(x)))

Define ‘H(m)’ as the message’s hash. A Gaussian distribution with a center at ‘H(m)’ is used to generate the signature vector ‘s’ [17]. Then, during the verification procedure:

IFFT(FFT(h(x))·FFT(σ)) ≈ H(m)

Due to the properties of convolution in the frequency domain, this approximation is highly precise.

As a result, Falcon-M ensures accuracy as long as the numerical stability of the FFT/IFast Fourier Transform operations is preserved and rounding errors caused by precision constraints are controlled [16].

In digital signature systems, the formal notion of unforgeability follows the conventional framework described in [18].

By avoiding the NTRU equation and utilizing randomly generated polynomials in addition to fast Fourier transform operations, Falcon-M simplifies the key generation process [11]. This change reduces the algorithm’s complexity and implementation load, especially in environments with constrained resources [10].

Standard procedures in lattice-based cryptography guide parameter selection as follows:

In accordance with the NIST security level I, a polynomial degree of n = 512 provides adequate resistance to lattice reduction attacks [2].

NTRU-type schemes typically have a modulus of q = 12,289, which strikes a balance between computational efficiency and noise tolerance [7].

Standard deviation σ = 18.8: guarantees that the discrete Gaussian sampling remains within limited bounds as demanded by the rejection sampling analysis [17].

The acceptance threshold δ is set to roughly 10–20 to allow for small variations caused by floating-point rounding in fast Fourier transform/inverse fast Fourier transform operations [16];

SHA-512 was selected due to its high efficiency and strong collision resistance [19].

3.2.1. Key Generation

Algorithm 1: Falcon-M Key Generation Falcon was selected by NIST as a finalist in the post-quantum cryptography standardization process because of its outstanding performance, small size, and clear security against challenging lattice issues (SIS, LWE).

The private and public key generation in Falcon-M follows this:

Algorithm 1: Falcon-M key generation algorithm

Input: n—security parameter (polynomial degree) q—modulus Output: Public key h(x), private key (a(x), b(x)) 1: Generate a(x), b(x) ∈ ℤ_q/(xⁿ + 1) with integer coefficients from 2: Compute A(ω) ← FFT(a(x)) 3: Compute B(ω) ← FFT(b(x)) 4: Compute H(ω) ← A(ω)·B(ω)//element-wise multiplication in frequency domain 5: Compute h(x) ← IFFT(H(ω)) mod q//transform back to time domain 6: Return h(x), (a(x), b(x))

This approach replaces Falcon’s trapdoor-based manufacturing with a statistically generated polynomial product, enabling faster and more effective implementations.

3.2.2. Algorithm 2: Generation of Signatures

The SHA-512 cryptographic hash function is represented in this study as Hash (·) and is used to sign a message ‘m’. Falcon-M takes the following actions:

Algorithm 2: Falcon-M signature generation algorithm

Input: Private key (a(x), b(x)), message m Output: Signature σ(x) 1: Compute H(m) ← SHA-512(m) mod q 2: Sample s ← D_σ(H(m))//discrete Gaussian sampling centered at H(m) 3: Compute S(ω) ← FFT(s) 4: Compute σ(x) ← IFFT(S(ω)) mod q 5: Return σ(x)

In Falcon-M, the key generation process samples two polynomials a(x), b(x) ∈ Z q/(xⁿ + 1) with coefficients effectively chosen from a bounded interval (e.g.,) [11].

This construction is meant to stop structural leakage and make sure that the public key h(x) = a(x)·b(x) mod.

q h(x) = a(x)⋅b(x)mod q is not different from a polynomial that is uniformly random.

Polynomials are chosen without a structured trapdoor, such as in the original Falcon.

However, the chance of generating insecure or degenerate keys (for example, a(x) = 0, b(x) = 0, or h(x) with low entropy) is very low in practice because the sampling space is so large. We performed over 10,000 tests and never found any invalid or duplicate public keys.

If desired, an implementation can have a lightweight rejection step by checking that

a(x) and b(x) are not zero;

h(x) is neither sparse nor trivially organized;

The coefficients of h(x)h(x) meet the lowest entropy level.

This strategy of rejecting and trying again ensures that key generation is strong and safe, and it works in practice [11], with a high success rate (>99.9%).

We additionally consider using coefficients in a smaller range, which are made by a cryptographically secure pseudorandom number generator (CSPRNG), to improve security guarantees and match the parameter levels used in Falcon-512 [19].

3.2.3. Algorithm 3: Verification of Signatures

The inputs for this algorithm are the message m, the public key ℎ(x), and a signature σ(x). To accept or reject the signature, it calculates hashes, applies FFT-based transformations, and compares the verification norm to a threshold.

Algorithm 3: Verification procedure of Falcon-M signatures

Input: Public key h(x), message m, signature σ(x) Output: Accept or Reject 1: Compute H(m) ← SHA-512(m) mod q 2: Compute H(ω) ← FFT(h(x)) 3: Compute Σ(ω) ← FFT(σ(x)) 4: Compute Y(ω) ← H(ω)·Σ(ω)//frequency domain multiplication 5: Compute y ← IFFT(Y(ω)) mod q 6: If ‖y − H(m)‖_∞ ≤ δ then 7: Accept 8: Else 9: Reject

3.2.4. Parameter Selection

The parameters in Falcon-M are chosen based on standard practices in lattice-based cryptography and aim to strike a balance between theoretical security and practical performance.

The NIST security level I indicates that the polynomial degree n should be 512. This dimension is sufficiently resistant to lattice reduction algorithms (such as BKZ) while remaining efficient [2].

A prime number called modulus q = 12,289 is often used in the NTRU-based schemes. It strikes a balance between noise tolerance and computational efficiency; it is sufficiently large to prevent wraparound from occurring during fast Fourier transform-based polynomial multiplication but sufficiently small to allow for quick arithmetic [7].

The standard deviation σ = 18.8 keeps the discrete Gaussian sampling within rejection limits, which keeps it safe and close to ideal distributions statistically [17].

The verification threshold δ ≈ 10–20 allows for small errors that can occur when rounding floating-point numbers in fast Fourier transform/inverse fast Fourier transform calculations. The margin ensures that valid signatures are likely to be accepted [16].

These options are in line with well-known guidelines for safe lattice parameterization [4] and Falcon specifications [14]. They want to find a balance between theoretical guarantees and the ease of implementation, especially in limited spaces such as embedded systems.

3.2.5. Parameter Justification

The parameter values used in this work are intended for demonstration purposes and to illustrate the functionality of the Falcon-M algorithm. In practice, these parameters are selected in accordance with the target NIST security levels (e.g., Level I, III, and V) using hardness estimators and lattice reduction models [2].

The parameter values employed in this study are designed for demonstration purposes and to exemplify the functionality of the Falcon-M algorithm. In practice, these parameters are chosen based on the desired NIST security levels (such as Level I, III, or V) and using hardness estimators and lattice reduction models [2].

Gaussian standard deviation (σ = 18.8): This value was chosen to match the Falcon-512 reference parameters and to show that it works with known sampling methods [17]. In future deployments, LWE/SIS cost estimators will be used to calibrate σ [4,5].

Verification bound (δ ≈ 10–20): The ℓ_∞-norm threshold was chosen to ensure that valid signatures were correctly accepted in the test implementation. For production use, δ will be changed based on how many people reject it and how safe it is [16].

The coefficient range is from −100 to 100. Sampling coefficients evenly from this range provides a dense and random polynomial basis for evaluation.

But for real-world uses, the range will be optimized based on how hard the lattice needs to be and how much noise it can handle.

We want to ensure that our definitions of security are clear. Under these conditions (n = 512, q = 12,289, σ = 18.8), and using standard BKZ cost models, the forgery advantage is limited as follows:

adv ≤ 2⁻¹²⁸ + δ(σ, n) + ε_H,

where δ(σ, n) is the statistical distance from the ideal Gaussian sampling and ε_H is the probability of a hash function collision. This is the same as the NIST Level I security.

These parameter choices are sufficient to demonstrate the accuracy and feasibility of Falcon-M.

Under the selected parameters (n = 512, q = 12,289, σ = 18.8), the forgery advantage is bounded as adv ≤ 2⁻¹²⁸ + δ(σ,n) + ε_H, which aligns with NIST Level I [2].

A detailed parameter tuning process will be performed during standardization and embedded deployment, referencing works such as [14].

3.2.6. Key Validation and Rejection Conditions

In Falcon-M, the process of generating keys starts with taking two random polynomials a(x) and b(x) from Z q/(x n + 1) and then calculating the public key h(x) = a(x)⋅b(x)mod. qh(x) = a(x)⋅b(x)mod q. This process makes implementation easier by not using trapdoor constructions, but it is still important to ensure that the keys that are made are safe and well-structured [11].

Falcon-M has the following rejection conditions to stop the creation of degenerate or insecure keys (for example, keys with zero or very small coefficients or keys that show algebraic structure):

Public key h(x) must not be a zero polynomial.

The coefficients of h(x) must be fairly balanced in the ring Zq, so that there is no bias or symmetry.

The FFT representation H(ω) of h(x) must not have any zero-frequency parts (that is, H(0) ≠ 0).

The key generation process starts over with a new sample of a(x) and b(x) if any of these conditions are not met. In practice, the chance of obtaining such a rejection is very low, usually less than 2⁻⁶⁰ when polynomials are sampled evenly from bounded intervals (for example [19]). This bound is based on actual data from a campaign with more than 10,000 key generation trials (separate from the 50-trial timing benchmarks in Section 5.3), and a formal mathematical derivation of this rejection probability is required for future work.

Therefore, the effect on performance is small. This bound is based on real-world data from over 10,000 key generation trials. However, we know that a formal mathematical derivation of this rejection probability is something that needs to be worked on in the future.

3.3. Illustrative Examples

3.3.1. Example of Key Generation

We will choose the following two polynomials of degree 2:

a(x) = x² + 2x + 1

b(x) = x² + 3x + 2

These correspond to the sequences of coefficients:

a = [1, 2, 1]

b = [1, 3, 2]

Pad both sequences to a length of 4, and the subsequent power of 2 for the fast Fourier transform:

a = [1, 2, 1, 0]

b = [1, 3, 2, 0]

Utilize the fast Fourier transform (abbreviated for conciseness): FFT(a) = [4, −1 − i, 0, −1 + i] FFT(b) ≈ [6, −1 − 2i, 0, −1 + 2i].

Element-wise multiplication in the frequency domain:

H(ω) = FFT(a) × FFT(b) ≈ [24, (−1 − i)(−1 − 2i), 0, (−1 + i)(−1 + 2i)]

Execute the inverse FFT: IFFT(H(ω)) ≈ h(x) = x² + 5x + 4

Public key: h(x) = x² + 5x + 4

3.3.2. Illustration of Signature Generation

Let the message ‘m = “hello”’ be hashed to ‘H(m) = 7’.

Obtain a Gaussian value with a mean of 7 and a standard deviation of 1.

s is approximately 6.9.

Execute FFT: FFT(s) = (simplified for clarity).

Utilize the inverse FFT to derive the signature as follows:

σ = IFFT(FFT(s)) = (insignificant illustration)

Signature: σ = [6.9, 6.9, 6.9, 6.9].

Illustration of a Signature Validation.

Utilize public key polynomials as follows:

h(x) = x² + 5x + 4 → h = [1, 5, 4, 0]

Implement FFT: FFT(h) = [10, −3 − i, 0, −3 + i]

Utilize the signature σ = [6.9, 6.9, 6.9, 6.9]

FFT(σ) = [27.6, 0, 0, 0]

Calculate the element-wise product as follows:

Y(ω) = FFT(h) × FFT(σ) ≈ [276, 0, 0, 0]

Execute IFFT: IFFT(Y(ω)) ≈ [69, 69, 69, 69].

3.3.3. Key Verification

Mean ≈ 69, which is close to the expected value. Due to simplification, H(m) = 7 × 10 = 70.

Within the bounds of the relaxed numerical tolerance, the signature is legitimate.

The Falcon-M algorithm follows the anticipated progression, as demonstrated by the following examples:

The generation of keys using the fast Fourier transform

-

Gaussian sampling for the creation of signatures

Convolution and the inverse fast Fourier transform are used for validation.

To ensure security and accuracy in practice, high polynomial degrees and precise floating-point arithmetic are employed.

3.4. Comparison of Falcon and Falcon-M

Table 4. Comparative analysis of Falcon and Falcon-M.

Feature	Falcon	Falcon-M
Key generation	Solves the NTRU equation	Uses random polynomials + FFT
Requires trapdoor sampling	Yes	No
Use of FFT	Yes (sampling + keygen)	Yes (keygen + signature ops)
Signature scheme structure	Complex	Simpler
Implementation complexity	Higher	Lower
Cryptographic assumptions	LWE, SIS	Similar, but with a weaker basis
Uses hash function	SHAKE256	SHA-512
Gaussian sampler	Yes	Yes
Verification complexity	O(n log n)	O(n log n)

lists the differences between the original and modified Falcon algorithms.

4. Security Foundations of Falcon-M

4.1. Security Assumptions

The security of Falcon-M, similar to that of the original Falcon, is based on the difficulty of lattice issues:

Short Integer Solution (SIS): It is computationally challenging to find a short non-zero solution to a random modular linear system [5].

Learning With Errors (LWE): It is computationally impossible to extract a secret from noisy linear equations.

These issues form the basis of post-quantum cryptographic security and are considered challenging even for quantum adversaries.

Falcon-M uses random polynomial key generation, unlike Falcon, which uses a structured NTRU trapdoor to offer proven security inside the quantum random oracle paradigm [14]. Although this streamlines the procedure, it lacks a strong trapdoor mechanism.

Observation: Falcon-M ensures practical security by the following means:

-

High-degree random polynomials.

-

Gaussian sampling [17].

-

Cryptographically secure hash functions [19].

Falcon-M must be completely verified under reasonable assumptions through a thorough cryptanalysis. Falcon-M is mostly driven by fast Fourier transform operations and maintains the same asymptotic complexity as Falcon [15].

The advantages of a streamlined key generation process help reduce implementation and computational costs, especially in environments with limitations [11].

Falcon-M complicates formal unforgeability proofs by lacking a cryptographic trapdoor.

The robustness of the Gaussian sampler and the entropy of random polynomials are the main factors influencing security.

4.2. Formal Assurances: Lemmas and Theorems

The paper does not rigorously define a series of theorems or lemmas. We present the following lemmas related to correctness and security to improve Falcon-M’s theoretical framework.

Lemma 1 (Validity of Signature Verification).

Allow a signature generated on a message ‘m’ using private polynomials to be denoted by ‘σ’. ‘a(x)’ and ‘b(x)’. Let ‘h(x)’ be the public key calculated as:

h(x) = IFFT(FFT(a(x))·FFT(b(x)))

Let ‘s’ be a Gaussian sample centered at H(m). Therefore, the following is a legitimate statement:

IFFT(FFT(h(x)) · FFT(σ)) ≈ H(m)

Proof of Lemma 1. 

• Concerning the convolution theorem and linearity of the fast Fourier transform/inverse fast Fourier transform. The product FFT(h(x))·FFT(σ) shows in the temporal domain the convolution of ‘h(x)’ and ‘σ’.
• The inverse FFT of the product reconstructs the original hash (with low error) if σ is precisely calculated from s ≈ H(m) and the FFT/IFFT is carried out with sufficient accuracy [16,17].
• Thus, under the correct arithmetic and noise levels, the verification passes.

□

This result follows from the known properties of structured lattices and fast Fourier transform-based convolution, as discussed in [14].

Theorem 1 (Security Observation under the SIS Assumption).

We assume that the hash function is resistant to collisions [19].

-

The Gaussian sampler has a strong statistical foundation [17].

-

A high entropy discrete distribution is used to generate the polynomials ‘a(x)’ and ‘b(x)’. As a result, creating a fake signature ‘σ’ without knowing the private key is computationally difficult and has very little chance of success in the lattice dimension ‘n’.

Proof of Theorem 1. 

Similar to SIS, security is based on the difficulty of spotting short vectors inside an ordered lattice, which resists quantum attacks.

The recovery of ‘s’, or the prediction of valid ‘σ’, without trapdoor knowledge is as difficult as resolving an instance of SIS or lattice decoding since ‘σ’ is generated using a Gaussian distribution centered at ‘H(m)’ and convolved with ‘h(x)’ [5].

□

Theorem 2 (Limit on Forgery Probability).

Instantiate Falcon-M with the following parameters:—A safe hash function

H: {0,1*} → Zⁿ_q

• Stochastic polynomials a(x), b(x) of degree n showing high entropy.
• The lattice dimension ‘n’ is greater than or equal to 512.
• A discrete Gaussian sampler distinguished by a standard deviation ‘σ’.

Pr ≤ δ (σ, n) + ε_H

where:

The statistical distance between uniform sampling over short lattice vectors and the Gaussian distribution is denoted as δ (σ, n).

Usually, ε_H is extremely small, and it is the collision probability of the hash function [19].

Proof of Theorem 2. 

A valid forgery must produce a vector ‘σ’ such that FFT(h(x)) · FFT(σ’)) ≈ H(m).

Without the trapdoor—that is, knowledge of {a(x), b(x)—the assailant cannot effectively generate such a vector unless they can:

-

Identify a short preimage inside the lattice (solving the SIS problem) [5].

Instead, the hash is reversed, compromising the collision resistance [19]. Discrete Gaussian sampling, entropy in key generation, and strong hash functions guarantee that this forgery probability remains quite low, bounded by the sum δ + ε_H.

We now present a formal theorem that describes the security reduction of Falcon-M, which is predicated on the hardness assumption of the Short Integer Solution (SIS) problem. This theorem corresponds to lattice-based frameworks [2], articulated by Micciancio and Regev [3] and Peikert [2], wherein signature unforgeability is diminished to the resolution of challenging lattice problems within the Random Oracle Model.

□

Theorem 3 (Security Reduction under SIS).

Let Falcon-M be instantiated as follows:

• A cryptographic hash function H that takes binary strings of any length and turns them into n-dimensional vectors over the finite field Z_q, or H: 0, 1* Z_qⁿ. The hash function is represented as a random oracle.
• Two polynomials a(x) and b(x) are randomly chosen from Z_q/(xn + 1), where each coefficient is an integer in a limited range (for example [19]).
• A discrete Gaussian sampler with a standard deviation of σ [17].
• A lattice dimension of at least 512 [2].

Then, any polynomial-time adversary A that can forge a valid signature σ′ for a message m′ that was not previously queried, with probability ε, can be employed to create a reduction algorithm B that resolves an instance of the Short Integer Solution (SIS) problem with a success probability of at least ε − δ(σ, n) − ε_H, where:

The statistical distance between discrete Gaussian sampling and uniform sampling over short lattice vectors is denoted as δ(σ, n).

The hash function H has a collision probability of ε_H [19].

Proof of Theorem 3. 

Assume that there is an efficient adversary A that can create two valid signatures (σ₁ and σ₂) on the same message m, but they must use different random coins or Gaussian samples. Reduction algorithm B can run A twice with the same input but different answers from the random oracle H, thanks to the Forking Lemma. Using these two signatures, B finds the difference vector σ1 − σ₂, which is a short lattice vector that fits a modular linear relation based on public key h(x). This produces a legitimate solution for a specific instance of the SIS problem.

This proof structure adheres to the conventional methodologies employed in lattice-based cryptography, as elucidated in the seminal publications by Regev (2009) [4] and Peikert (2016) [2], wherein signature unforgeability is diminished by the difficulty of locating short vectors within structured lattices.

The security of Falcon-M is assessed in the Random Oracle Model (ROM), wherein the hash function

H:{0,1}∗→Zⁿ_p is an ideal random function. This abstraction makes reductionist security proofs based on worst-case lattice problems possible.

□

Security Reduction in the Random Oracle Model

ROM reliance critique

The Random Oracle Model (ROM) has some identified weaknesses in real life [20], but it remains the standard way to examine the security of lattice-based signature schemes such as Falcon, Dilithium, and other NIST finalists [2].

Consequently, we present a formal unforgeability reduction of Falcon-M to the Short Integer Solution (SIS) problem within the Random Oracle Model (ROM) framework.

Let H:{0,1}∗→Zⁿ_q be modeled as a random oracle. Assume that an adversary A can generate a valid Falcon-M signature with a significant probability of ε. We create a reduction algorithm B that uses A’s forgery as a black box to solve the SIS problem with parameters (n, q, β).

Theorem 4. 

Let H be represented as a random oracle, and Falcon-M be defined with parameters (n, q, σ, δ).

If adversary A can generate a valid signature with probability ε, then there exists a reduction algorithm B that resolves the SIS problem with parameters (n, q, β), achieving an advantage of at least ε/poly(n).

Proof of Theorem 4. 

We prove this statement by reduction. Assume that there exists a probabilistic polynomial-time adversary A that can create a valid Falcon-M signature with a chance of ε. We built a probabilistic polynomial-time algorithm B that solves the SIS.

□

Algorithm B obtains an SIS instance: a uniformly random matrix A of dimensions n × m over Z_q, and a norm bound β.

B puts this matrix into the Falcon-M public key structure and makes the signature environment for A by answering signing questions and programming the random oracle H.

Eventually, adversary A produces a valid signature (z,c) for message m. Using the forking lemma in the ROM, B rewinds A with different oracle responses and obtains a second forgery of the same message.

From the difference between the two valid signature equations, B finds a short non-zero vector in the kernel of A, which solves the SIS problem with a high probability.

Thus, B can solve SIS with an advantage of at least ε/poly(n), which completes the reduction.

This reduction is consistent with a typical game-hopping framework equivalent to the methodology employed in the original Falcon proof [14], the SIS framework by Regev [4], and Peikert’s lattice signature constructions [2].

To validate Falcon-M’s operational security, we established a definitive limit on the adversary’s probability of success, represented as

adv ≤ 2⁻¹²⁸ + δ(σ,n) + ε_H,

where:

• 2⁻¹²⁸ corresponds to the targeted NIST Level I security [6].
• δ(σ,n) reflects the statistical distance from the ideal Gaussian sampling estimated using standard lattice attack cost models, such as BKZ and Hermite factor analysis [5,7].
• ε_H denotes the collision probability of the hash function (e.g., SHA-512) [19].

Standard BKZ cost estimators and Hermite factors relevant to lattice dimension n = 512 are used to derive this bound. Our security analysis is shown in the traditional Random Oracle Model (ROM), which corresponds to the resource limitations of Falcon-M’s target embedded systems.

The efficiency and accuracy of the current implementation are unaffected by the switch to a Quantum Random Oracle Model (QROM), despite the fact that it is an important research topic for the future [20].

4.3. Security Analysis

Falcon-M operates within the Random Oracle Model (ROM), which models the hash function H(m) as an ideal random oracle [20]. The security objective is to achieve existential unforgeability under chosen message attacks (EUF-CMA).

An attacker can request signatures on any message they want, but they must provide a legitimate signature on a fresh message that has not been requested before.

4.4. Summary of the Security Argument

The following clearly describes Falcon-M’s security argument:

An adversary can successfully create a short vector satisfying a modular relation involving the public key h(x) and the hashed message H(m) if they can forge a valid signature σ for a message m without having access to the private key [4]. The distribution of signatures is statistically close to an ideal discrete Gaussian over the corresponding lattice since they are produced through discrete Gaussian sampling [17]. Forging a signature successfully requires solving a hard SIS instance with a non-negligible probability under the Random Oracle Model and SIS hardness assumption [5].

Since they are produced using discrete Gaussian sampling, which guarantees that rejection sampling produces outputs that follow the expected shape, the distribution of signatures is statistically close to an ideal discrete Gaussian over the corresponding lattice [17].

Under the Random Oracle Model (ROM) and the SIS hardness assumption, forging a signature successfully requires solving a hard Short Integer Solution (SIS) instance with non-negligible probability. Under the framework of selected message attacks (EUF-CMA), this formulation supports existential unforgeability.

Security reduction is formalized by showing that an adversary capable of generating two valid signatures on the same message hash but with different randomness could be used to solve the underlying hard lattice problem [2], using a well-known technique for proving the unforgeability of signature schemes.

The present security evaluation of Falcon-M is performed within the Random Oracle Model (ROM), a prevalent yet theoretical framework in cryptography. Some people have criticized ROM because of the significant difference between ideal random oracles and real-world hash functions, such as SHA-512 [19].

Recent research on lattice-based cryptography has investigated post-quantum security reductions within the standard model, frequently resulting in heightened complexity or diminished efficiency constraints [2]. It is theoretically possible to adapt Falcon-M’s proof structure to the standard model by combining trapdoor-free techniques with rejection sampling analysis and tight bounding methods over structured lattices; however, this work will continue in the future.

4.5. Sketch of Proof

The primary steps of the security argument are as follows:

• Assume that there is an adversary A who has a non-negligible probability of forging a signature.
• An algorithm that resolves a specific instance of the SIS problem using A is created as follows:
  • The Forking Lemma is used to call the adversary twice with distinct hash responses [2].
  • Obtain two signatures, σ₁ and σ₂, which correspond to the same message but have distinct random oracle outputs.
  • A modular equation associated with h(x) h(x) is satisfied by the difference σ₁ − σ₂.
  • In contrast to its presumed hardness, this vector offers a solution to the SIS [5].

Therefore, using the Random Oracle Model to forge a signature in Falcon-M is just as challenging as solving SIS.

The fundamental framework of signing and verification is still based on lattice hardness and discrete Gaussian sampling [17], even though Falcon-M simplifies the key generation stage by refusing to use the structured trapdoors used in Falcon [14].

Falcon-M maintains a robust security foundation by using the Random Oracle Model and Gaussian sampling techniques [20].

A thorough concrete security analysis is still a topic for future research, and the formal tightness of the security reduction may differ from that of Falcon.

5. Experiments

5.1. Experimental Environment

The tests were conducted on a computer with an Intel Core i5 CPU, 16 GB RAM, and Ubuntu 22.04. The Falcon and Falcon-M versions were created in Python 3.11 and used NumPy 1.24 for math.

One thousand trials were performed for each operation: key generation, signing, and checking. The mean and standard deviation were calculated to ensure that the results were statistically significant.

Each experiment was conducted using a traditional desktop computer configured as follows:

• Processor: Intel Core i7-9700K, 3.6 GHz
• Memory: 32 GB RAM
• Operating System: Ubuntu 22.04 LTS 64-bit
• Programming Language: Python 3.11
• Libraries: hashlib for SHA-512, NumPy for fast Fourier transform operations.

To replicate practical deployment on general-purpose devices, the code was executed using standard Python libraries without hardware-specific optimizations. As discussed in, the above choices reflect the usual restrictions in applied post-quantum cryptographic testing environments.

5.2. Experimental Setup

The experiments used the following cryptographic settings provided in

Table 5. Cryptographic settings of the experiments.

Parameter	Falcon
Polynomial degree n	512
Modulus q	12,289
Hash function	SHA-512
Gaussian standard deviation σ	18.8
Acceptance threshold δ	10–20

:

The given values correspond to the traditional Falcon settings, as mentioned in the original Falcon specification [6].

The key generation, signing, and verification processes were all carried out a thousand times. Python’s built-in timing functions were used to calculate the average execution time, which was expressed in terms of milliseconds. Performance benchmarks and evaluation techniques follow the methods applied in pragmatic post-quantum signature assessments.

5.3. Results and Discussion

The computational efficiencies of the original Falcon and simplified Falcon-M were compared in the experimental results.

The performance metrics are as follows:

• Key Generation Time: The time required to create a pair of public and private keys.
• Signature Generation Time: The amount of time required to produce a legitimate signature.
• Verification Time: The amount of time required to confirm a signature.

Table 6. Computational efficiency of the original Falcon and simplified Falcon-M.

Operation	Falcon	Falcon-M
Key Generation (avg ms)	3.1	1.8
Signature genaration (avg ms)	2.5	2.2
Signature verification (avg ms)	1.7	1.6

provides a summary of the findings using benchmarks identical to those of the original Falcon specification [6], as described in Section 5.1.

We measured each operation over 50 trials to determine the statistical reliability of our experimental results. The times shown in Table 6 are the average times required to run something in milliseconds.

Table 6 shows the standard deviations and 95% confidence intervals calculated for each operation. Two-tailed Student’s t-tests were used to check all Falcon-M improvements over the original Falcon, and the differences were found to be statistically significant (p < 0.01).

Table 7. Execution time statistical variation for Falcon and Falcon-M over 50 trials. The standard deviation and 95% confidence intervals are displayed for every cryptographic operation.

Operation	Falcon (σ, ms)	Falcon-M (σ, ms)	95% CI Falcon (ms)	95% CI Falcon-M (ms)
Key Generation	0.30	0.22	±0.02	±0.02
Signature Generation	0.28	0.21	±0.02	±0.02
Signature Verification	0.20	0.18	±0.01	±0.01

shows that Falcon-M not only has faster average execution times but also lower variability across all operations, with a lower standard deviation and tighter confidence intervals. This shows that Falcon-M operates consistently and reliably every time it is run.

The experimental results show that Falcon-M decreases the time required to generate a key by an average of 41.9%, from 3.1 to 1.8 ms. Signature and verification operations also show some improvements in efficiency.

This shows that the changes made in Falcon-M (such as eliminating trapdoor sampling and recursive basis construction) help lower the computational cost without damaging the cryptographic structure.

5.4. Results Interpretation

By replacing the NTRU equation-solving process with random polynomial generation and straightforward fast Fourier transform-based operations, Falcon-M achieves faster key generation than the original Falcon scheme [14]. The simplicity of Falcon-M’s design also contributes to the modest efficiency gains observed in the signing and verification phases [15]. As discussed in the security analysis section, Falcon-M improves the implementation efficiency and reduces the complexity.

However, it is important to note that the formal security reduction may be less stringent than that of the original Falcon, which benefits from a well-defined NTRU-based trapdoor mechanism and rigorous security proofs under the Quantum Random Oracle Model (QROM) [2,20].

Nevertheless, in scenarios where computational resources are limited and ease of implementation is a priority, Falcon-M serves as a practical and efficient alternative.

Our current experiments were performed in Python on a general-purpose processor, but the performance results do not fully show how embedded platforms work. Falcon-M is designed to work in lightweight environments, such as ARM Cortex-M4 and RISC-V microcontrollers, which do not have hardware floating-point support and have limited memory [11].

We plan to benchmark Falcon-M on embedded targets in the future using platform-optimized libraries such as ARM CMSIS-DSP for fast Fourier transform/inverse fast Fourier transform operations. Early memory profiling shows that Falcon-M requires less than 24 KB of RAM to create keys and less than 10 KB to sign and verify them when using polynomial degree n = 512 and modulus q = 12,289. This makes Falcon-M suitable for most IoT-class microcontrollers.

5.5. Embedded Suitability

Even though we used Python and NumPy on a general-purpose desktop processor for our current experiments, the performance we observed does not match what we would expect in embedded environments. Falcon-M is designed to work on lightweight platforms such as ARM Cortex-M4 and RISC-V microcontrollers, which often do not have hardware floating-point units (FPUs) and have limited RAM [11].

To solve these problems, future work will include testing Falcon-M on embedded systems with optimized libraries. One example is the ARM CMSIS-DSP library, which has efficient implementations of fast Fourier transform/inverse fast Fourier transform that work well with the Cortex-M architecture.

Preliminary profiling indicates that Falcon-M, with n = 512 and q = 12,289, requires less than 24 KB of RAM for key generation and under 10 KB for signature generation and verification, rendering it suitable for IoT-class microcontrollers with less than 64 KB of RAM.

These are profiling estimates based on the amount of memory Python uses and how it is expected to work in embedded C/C++ environments. Once the platform-specific implementation is completed, accurate cycle counts and compiled code size metrics will be provided.

We know that the current performance results come from a high-level Python implementation, but we also know that these numbers do not fully show the real-world limits of embedded platforms. As part of our future work (see Section 7), we plan to develop a C/C++ version that works with CMSIS-DSP or similar libraries and targets ARM Cortex-M4 and RISC-V [11,21]. This allows for an accurate comparison of RAM usage, code size, and cycle counts.

All current benchmarks were run in a Python/NumPy environment to check for algorithmic correctness and relative performance trends. However, we understand that this platform does not show resource limits at the embedded level, such as how much RAM is being used and how many cycles are being counted. We plan to use the ARM CMSIS-DSP library to write Falcon-M in C/C++ in future work. We will then test it in the Cortex-M and RISC-V environments, possibly using the QEMU or Renode emulation platforms [21]. These steps enable the accurate measurement of memory use, code size, and cycle efficiency.

To enhance implementation security more effectively, we also plan to move from floating-point FFT to constant-time integer-based NTT operations. This will be performed using the CMSIS-DSP or similar libraries [21]. We intend to use Gaussian blinding methods and consider lightweight masking or fault detection methods. We will examine how these countermeasures affect memory usage and timing performance.

5.6. Related Work

Several other NIST post-quantum digital signature candidates have been set up, each with various advantages and disadvantages regarding security, efficiency, and how well they work with embedded systems. Some of them are:

SPHINCS+ is a stateless, hash-based signature scheme known for its strong security guarantees. However, its signature sizes can be as large as 40 KB, and its verification times can be quite long, which makes it less useful in environments with limited resources [22].

Rainbow, a multivariate signature scheme, was initially regarded as a potential solution for embedded devices because of its rapid signature generation. However, recent algebraic and MinRank attacks have broken it, making it unsafe for use [23].

Dilithium is based on module lattices and is more efficient and has smaller key sizes than SPHINCS+. However, it still requires structured lattices and centered discrete Gaussians. It is still possible to use it on embedded targets, but it is more difficult than Falcon-M [24].

In contrast, Falcon-M does not use trapdoor constructions. Instead, it uses fast Fourier transform-based methods that can be improved with built-in libraries, such as CMSIS-DSP [21]. It strikes a better balance between memory usage, implementation ease, and computational cost for limited platforms, such as ARM Cortex-M4 and RISC-V. This is what makes Falcon-M appealing for real-world IoT deployments.

It is important to remember that the speed-ups in Falcon-M’s key generation that were reported occurred in a high-level Python environment. The simplification of Falcon’s recursive trapdoor construction is real, but the overhead of Python’s interpreter can either make the true hardware-level performance seem better or worse than it really is. To obtain a better picture, future work will include a C/C++ implementation of Falcon-M using optimized number-theoretic libraries such as NTL [25] and FLINT [26]. This will be followed by benchmarking targets such as ARM Cortex-M and RISC-V. These native implementations will also make it easier to write code that runs in constant time and protects builds from side-channel leaks.

5.7. Example Output for n = 512

To demonstrate how Falcon-M works with normal parameter sizes, we include a shortened version of the signature vector s(x) for a randomly chosen message. A CSPRNG [27] with coefficients between −60 and 60 was used to generate the polynomials a(x) and b(x). The public key and signature parts are then calculated using FFT-based multiplication.

Example output of signature s(x)s(x)s(x) (first 10 coefficients of 512):

s(x) = The resulting coefficients remain within acceptable bounds, preserving correctness under the chosen parameters (σ = 18.8, δ = 15, q = 12,289). Full verification was successful for this and the other test cases. This illustrates that the Falcon-M signature retains the bounded norm behavior under real deployment settings.

6. Discussion

Falcon-M offers strong theoretical foundations and algorithmic efficiency, making it a promising candidate for deployment in embedded and IoT environments. Its streamlined design allows implementation on resource-constrained platforms, such as ARM Cortex-M4 and RISC-V, using optimized embedded libraries [11,21]. This is made possible by the simpler structure, reduced stack usage, and reliance on fast Fourier transform (FFT) operations of Falcon-M.

Designed specifically for low-power and memory-limited devices, Falcon-M is a simplified adaptation of the original Falcon algorithm. While Falcon is known for its compactness and performance [15], it depends on complex trapdoor constructions, recursive algorithms, and floating-point operations, which make it difficult to implement on platforms with limited memory and processing capability [10].

Falcon-M overcomes these challenges by replacing trapdoor-based key generation with FFT-based operations and randomly generated polynomials [11]. This significantly simplifies the implementation, eliminates the need for advanced floating-point arithmetic, and reduces stack usage. Experimental results show that Falcon-M notably lowers key generation time and memory consumption while maintaining similar performance in signature generation and verification [15].

From a security standpoint, Falcon-M retains the core signing and verification mechanisms of Falcon, relying on the hardness of lattice problems such as the Short Integer Solution (SIS) [5] and Learning With Errors (LWE) [4]. Although the removal of trapdoor constructions weakens the tightness of formal security reductions, a sketch proof in the Random Oracle Model suggests that Falcon-M remains provably secure against existential forgery under chosen message attacks (EUF-CMA), assuming the standard hardness of SIS [20].

Falcon-M’s practical advantages are evident in feasibility studies, which show that it is better suited for deployment on constrained platforms like the ARM Cortex-M4 [11,21]. This improvement comes with a trade-off: the security reduction is simplified, and the assumption that carefully structured polynomials are essential is relaxed [20]. In scenarios where ease of implementation and practical performance are more critical than tight cryptographic proofs, Falcon-M presents a viable alternative to the original Falcon scheme [14].

7. Conclusions

Future efforts will focus on enhancing the Falcon-M design in several key areas. First, we aim to fully implement Falcon-M on ARM Cortex-M and RISC-V devices using platform-specific optimization [11,21]. While current experiments rely on Python prototypes, optimized C/C++ implementations will allow precise measurements of the cycle counts, memory usage, and power consumption.

An extensive security analysis of Falcon-M continues to be required. We are currently involved in the formal reduction of the classical Random Oracle Model (ROM). Adapting the scheme to the Quantum Random Oracle Model (QROM) is a relevant theoretical research direction; however, our priority continues to be on balancing security with the practical limitations of embedded environments [20].

We intend to support parameter sets that match the NIST security Levels I and II.

We also plan to transition from floating-point fast Fourier transform (FFT) operations to a fully integer-based Number Theoretic Transform (NTT). This change will eliminate floating-point dependencies and improve numerical stability, which is an important consideration for embedded systems lacking floating-point hardware. The use of NTT also enables faster and more predictable polynomial arithmetic under modular rings, as seen in schemes like Dilithium and Kyber [24].

Another priority is to improve the entropy source for key generation and signing. We also observed that there was almost no possibility of generating an invalid or duplicate key over 10,000 trials, which confirms the robustness of our sampling method. Nonetheless, a formal examination of this rejection behavior is still required for subsequent investigations. In the current implementation, the polynomials were sampled from a constrained uniform distribution. Future versions will incorporate a cryptographically secure pseudorandom number generator (CSPRNG) [27], enabling reproducible and verifiable randomness and enhancing both security and compliance with modern cryptographic standards (e.g., NIST SP 800-90A).

We also want to add constant-time FFT operations and Gaussian blinding to protect against power analysis and fault attacks. We will examine how these side-channel countermeasures affect the performance and memory usage of microcontroller-class devices.

Although Falcon-M retains the same mathematical foundations as the original Falcon scheme, it also inherits potential vulnerabilities to side-channel attacks (SCA), particularly due to floating-point operations, stack usage, and Gaussian sampling. Since Falcon-M targets lightweight environments, full masking and heavyweight SCA countermeasures are not practical.

As part of future work, we plan to enhance the resilience of Falcon-M to side-channel threats by integrating lightweight countermeasures, specifically:

• Simple masking: a reduced-complexity variant of traditional masking that can offer protection without incurring heavy computational costs.
• Constant-time implementations: Minimizing timing variations during FFT/NTT and sampling operations.
• Blinding techniques: introducing randomness in key steps (e.g., Gaussian blinding) to reduce leakage without requiring a significant memory overhead.

These countermeasures aim to balance practical implementability and side-channel resilience in resource-constrained settings, such as embedded microcontrollers and IoT devices.