Performance Characteristics Of The Cryptographic Algorithm Crystals-Dilithium

When it comes to Quantum Threats to Classical Cryptography, we need to consider two key players: RSA and ECC. Both of these cryptographic methods are at risk from Shor’s algorithm, which can efficiently factor large numbers and tackle discrete logarithms in polynomial time. This means that once we have large-scale quantum computers, RSA and elliptic-curve cryptography (ECC) could become insecure (Gitonga, 2025; Freemindtronic, 2024). On the other hand, we have Dilithium, which stands out for its resistance. It is built on module-lattice problems (Module-LWE and Module-SIS), and there is a strong belief that these problems can withstand both classical and quantum attacks. Unlike RSA and ECC, there are no known efficient quantum algorithms which can crack these issues (Bos et al., 2022).

For the CRYSTALS-Dilithium variants (Dilithium-2, Dilithium-3, Dilithium-5), the key generation time is very low (<0.05 seconds) and unaffected by file size, since it depends only on cryptographic operations defined by the algorithm’s parameters. The differences between 1 MB and 1000 MB are negligible – for example, in Dilithium-2 the average remains ~0.02 seconds in all cases.

Figure 1:

File Size vs. Execution Time in CRYSTALS-Dilithium 5

In contrast, signing and verification times grow significantly with file size. In Dilithium-2, signing increases from ~0.088 seconds at 1 MB to ~7.62 seconds at 1000 MB (≈86× increase). Verification shows the same trend, rising from ~0.037 seconds to ~7.54 seconds over the same range. The results clearly indicate an almost linear relationship: a tenfold input increase leads to a nearly tenfold execution increase. For instance, between 100 MB and 1000 MB, signing time grows by ≈9.2×. This trend occurs because the algorithm must process the entire message – typically via hashing – before generating or verifying a digital signature.

The results show that execution-time differences between Dilithium-2, Dilithium-3, and Dilithium-5 are more pronounced for small files, while they nearly vanish for the largest ones. For example, when signing a 1 MB message, Dilithium-5 is ~72% slower than Dilithium-2 (0.1517s vs. 0.0879s), and verification is ~45% slower (0.0534s vs. 0.0368s). However, at 1000 MB, signing times converge to ~7.6 seconds and verification to ~7.55 seconds across all variants. This indicates that for large files, message processing (I/O and hashing) dominates execution time, rendering the extra cryptographic cost of higher security levels negligible.

For key generation, higher levels show moderate increases: for instance, at 1 MB, Dilithium-5 requires 0.0533s compared to 0.0231s for Dilithium-2. Yet these differences, in the order of tenths of a second, remain insignificant in practice, especially since key generation is not performed frequently.

The CPU load during cryptographic operations increases with file size, particularly in the signing and verification phases, which involve intensive data processing. Table 1 shows the average CPU utilization values (in %) obtained from the same experiments across different file sizes and Dilithium security levels.

Figure 2:

File Size vs. CPU Utilization in CRYSTALS-Dilithium 5

Key generation consumes relatively few resources (~10–19%), with no clear dependency on file size, since the process relies only on the algorithmic parameters. Small variations are likely due to measurement noise or system activity (e.g. OS interruptions background processes).

During signing, the CPU load is notably higher, approaching the full use of a single core. For smaller files (1 MB, 100 MB), average utilization is ~22–24% (Dilithium-2/3 at ~22–23%, Dilithium-5 slightly higher at ~22–25%). For larger files (500 MB, 1000 MB), utilization rises to ~29–30% for all variants, indicating continuous workload on one core. On a quad-core system, ~25% corresponds to one fully loaded core; ~30% suggests hyper-threading or occasional task switching between cores.

A similar trend is seen in verification: ~15–19% at 1 MB, increasing to ~28–29% at 1000 MB. For 100 MB, Dilithium-5 shows lower utilization (23.19%) than Dilithium-2 (29.23%), but this difference diminishes at higher sizes, converging near ~29%. These minor deviations may stem from implementation differences, internal optimizations, or measurement artifacts (e.g. thread management). Overall, the results confirm that file size drives higher CPU load, stabilizing near the saturation point of a single core.

The analysis indicates that cryptographic key pair generation consumes a relatively small portion of CPU resources and is effectively independent of input file size, as this phase relies on algorithmic parameters and internally generated values rather than message processing.

In contrast, signing and verification operations, which require reading and hashing variable-size data, progressively increase CPU load with file size. This increase is, however, limited; CPU utilization stabilizes at a saturation point due to architectural constraints, specifically the processing capacity of a single core.

For large files, all three CRYSTALS-Dilithium variants (Dilithium-2, 3, and 5) reach similar maximum CPU utilization (~30%), indicating that the bottleneck is identical across variants: the single-core processing speed for the given data volume, independent of cryptographic parameters.

Memory (RAM) usage in cryptographic operations also increases with input file size, especially during signing and verification, as larger files require bigger buffers and more data in active memory.

Figure 3:

File Size vs. Memory (RAM) Utilization in CRYSTALS-Dilithium 2

During key generation, memory usage is very low and roughly constant (~15–16 MB), independent of file size, since the process involves fixed structures (small vectors and matrices) defined by algorithm parameters, rather than the message itself. For example, with a 1 MB file, memory usage is ~16.6 MB, while with 100 MB it is ~15.7 MB, variations attributable to OS memory allocation, caching, or fragmentation, not functional changes in the algorithm.

In signing, memory usage grows almost linearly with file size. For a 1 MB file, ~17–18 MB is needed, while for 100 MB it rises to ~116 MB, reflecting the loading of the entire file plus buffers and cryptographic structures (~16 MB overhead). For larger files:

• 500 MB: Dilithium-2 ~518 MB, Dilithium-5 ~531 MB

• 1000 MB: all variants ~1.02 GB RAM

This indicates that the implementation loads the full file into memory before or during signing, with additional space for buffers, cryptographic structures, and internal algorithm functions. The increase roughly matches the 1:1 ratio of file size plus a fixed base overhead.

During verification, memory usage also grows with file size, with differences between the security levels.

• For a 100 MB file: Dilithium-2: ~23.9 MB, Dilithium-3: ~64.5 MB, Dilithium-5: ~114.7 MB

These differences suggest not all variants load the full file into memory, or manage internal buffers and caching differently. Dilithium-2 may process the message chunkwise, while Dilithium-5 likely pre-allocates more memory or loads the entire file upfront.

For larger files, the numbers approach full file load scenarios:

• 500 MB: Dilithium-2 ~438.6 MB, Dilithium-3 ~489.4 MB, Dilithium-5 ~541.2 MB

• 1000 MB: Dilithium-2 ~909 MB, Dilithium-3 ~968 MB, Dilithium-5 ~1049 MB

These values are approximately equal to the file size, with a small, consistent overhead increasing with security level, likely due to the larger public keys, signatures, and internal parameters in Dilithium-5.

In conclusion, verification, like signing, requires memory roughly equal to message size, with possible implementation optimizations at lower security levels (e.g. Dilithium-2 using smaller working buffers or streamed processing). In practice, signing or verifying very large files is memory-intensive and requires sufficient RAM – at least equal to the file size, plus additional space for cryptographic logic.

This trend indicates that in practical applications with large documents, memory usage optimization strategies become necessary. A recommended approach is, for example, to sign a precomputed hash of the document instead of the entire file, an approach which will be further discussed in this section.

As shown in Table 2 execution time differences between CRYSTALS-Dilithium parameter sets (Dilithium-2, 3, 5) are most noticeable for small messages, where cryptographic computation dominates.

For a 1 MB file:

• Signing: Dilithium-2 ~0.088 s, Dilithium-3 ~0.127 s, Dilithium-5 ~0.152 s (~70% slower than Dilithium-2);

• Verification: Dilithium-2 ~0.037 s, Dilithium-5 ~0.053 s (~45% slower), with Dilithium-3 between the two;

• Key generation: Dilithium-2 0.0231 s, Dilithium-5 0.0533 s (~2× slower).

Figure 4:

Security Level (CRYSTALS-Dilithium 2, 3, 5) vs. Execution Time for 1 MB File

These differences result from larger matrices, polynomials, and vectors in higher-security variants, increasing arithmetic complexity in key generation, signing, and verification.

With larger files, relative differences decrease:

• 100 MB signing: Dilithium-5 0.8978 s (~8.5% slower than Dilithium-2 0.8276s)

• 500 MB signing: 3.9298 s vs. 3.8791 s (~1.3% difference)

• 1000 MB signing: 7.67 s vs. 7.62 s (<1% difference)

• Verification: difference between D5 and D2 drops from ~2.6% (100 MB) to <1% (500 MB) and ~0.3% (1000 MB)

This confirms that for large messages, total time is dominated by hashing and I/O rather than cryptographic complexity. For small messages, parameter set choice significantly affects performance, due to the higher fixed cryptographic overhead in Dilithium-5.

Key generation differences follow the same trend: Dilithium-3 is ~1.5× slower than Dilithium-2, and Dilithium-5 ~2× slower. For a 1000 MB file, the key generation times are 0.021 s (D2), 0.031 s (D3), and 0.046 s (D5). Absolute times remain below 0.05 s, keeping key generation fast and efficient across all security levels.

The differences in CPU load between Dilithium-2, 3, and 5 are most noticeable in short-term operations, similar to execution time. During key generation, the larger algorithm (Dilithium-5) uses more CPU power (up to ~17–18% on average) compared to Dilithium-2 (~10–12%) because it carries out more operations. The same applies to the verification of small messages: for 1 MB, Dilithium-5 uses ~19% CPU, compared to ~15.6% for Dilithium-2. This indicates that the more complex algorithm consumes more CPU cycles for processing, so even over short periods it registers a higher load.

Figure 5:

Security Level (CRYSTALS-Dilithium 2, 3, 5) vs. CPU Utilization for 1 MB File

However, for longer tasks, such as signing or verifying large files, the average CPU load levels out. As seen in Table 2 for 500 MB and 1000 MB, all variants use ~28–30% CPU, with no significant difference. For example, signing a 1000 MB file uses ~29.5% CPU across all three levels. This means that all the variants ultimately limit CPU usage to a similar degree (as discussed, roughly one core at maximum). The differences observed with small inputs disappear here because the execution is long, and the CPU is continuously engaged; whether executing Dilithium-2 or 5, it always has enough work (from data hashing or the signing logic itself) to remain near 100% utilization of one core. Therefore, for long operations, the choice of algorithm does not affect the average CPU load, only the operation duration; but as we have seen, the duration is almost identical when data processing dominates.

Figure 6:

Security Level (CRYSTALS-Dilithium 2, 3, 5) vs. Memory Utilization for 1 MB File

The key size, i.e. the choice of parameter set, also affects the algorithm’s memory requirements, although its impact is significantly smaller than that of file size. As shown in Table 2 during key generation, all variants use roughly the same memory, around 15–16 MB, with no notable differences between Dilithium-2, 3, and 5, since even the largest structures, such as secret keys, occupy only a few kilobytes. Memory usage here is more influenced by the runtime environment, allocation methods, and system configuration than by the algorithm itself.

During signing, higher security levels consume slightly more memory, which becomes more noticeable for larger files. For example, when signing a 500 MB file, Dilithium-5 used ~531 MB versus ~518 MB for Dilithium-2, a difference of ~2.5%. For smaller files, such as 100 MB, the difference is minimal: 116.5 MB forDilithium-5 versus 116.3 MB for Dilithium-2. This indicates that the extra memory required by larger cryptographic structures, such as public keys and signatures, represents a relatively constant overhead which becomes proportionally smaller for larger inputs.

During verification, differences in memory usage across parameter sets are more pronounced, particularly for medium-sized files. For a 100 MB message, Dilithium-5 requires ~114.7 MB RAM, while Dilithium-2 uses only ~23.9 MB, likely due to different buffer management strategies in the implementation. For larger files, the trend continues: for 1000 MB, Dilithium-5 uses ~1048 MB, Dilithium-2 ~909 MB (~15% difference), likely caused by larger internal structures at higher security levels, such as expanded matrix vectors. Nevertheless, all the variants generally use memory approximately equal to the file size, meaning that for memory-sensitive applications, choosing Dilithium-2 over Dilithium-5 will not significantly reduce the requirements for the same large files. The differences become more relevant with smaller files: for 1 MB messages, all three sets use ~16–18 MB RAM, showing negligible deviations. Overall, the memory overhead of Dilithium-5 appears mainly for large data, with a worst-case increase of up to ~100 MB compared to Dilithium-2.