The Efficiency of Post-Quantum Signature Schemes
NIST has given us three Post-Quantum Signature algorithms
| Original Name | Standard Name | FIPS | Approach | Status |
|---|---|---|---|---|
| CRYSTALS-Dilithium | ML-DSA | FIPS 204 | Lattice-based (module-LWE) | Final, Aug 2024 |
| SPHINCS+ | SLH-DSA | FIPS 205 | Hash-based (stateless) | Final, Aug 2024 |
| FALCON | FN-DSA | FIPS 206 | Lattice-based (NTRU + FFT) | In development |
And now it’s up to us to prepare for Q-Day. For a deeper dive into the history of NIST’s standardization process check out our blog post on NIST’s Post-Quantum Standardization Process.
Cryptographic signature schemes consist of three algorithms:
- Key Generation This is run once, and generates a public-key / private-key pair. In the context of signature schemes, the private key is often called the “signing key”, while the public key is called the “verification key”
- Signature Generation This takes the signing key and the message and produces a signature
- Verification This takes the signature, the message, and the verification key, and verifies that the signature is valid (i.e., that the signer used the private signing key to produce this signature on this message)
After undergoing serious public scrutiny during the NIST selection process, we believe that these post-quantum signature schemes will be secure, but if we’re going to switch from our current signature schemes (e.g. ECDSA, RSA) to a post-quantum scheme, the performance of these schemes is also important. And, in this case, it’s a big issue. All three of NIST’s post-quantum signatures schemes produce signatures that are much larger than the classical (pre-quantum) signature schemes that are widely used today. This means that applications that process a lot of digital signatures may see their bandwidth and storage costs increase dramatically.
Sizes
Classical Signature Sizes
| Algorithm | Public Key (bytes) | Secret Key (bytes) | Signature (bytes) |
|---|---|---|---|
| RSA-2048 | 294 | 1,217 | 256 |
| ECDSA-P256 | 65 | 32 | 72 |
| Ed25519 | 32 | 32 | 64 |
Post-Quantum Signature sizes
| Algorithm | Security Level | Public Key (bytes) | Secret Key (bytes) | Signature (bytes) |
|---|---|---|---|---|
| ML-DSA-44 | 2 | 1,312 | 2,560 | 2,420 |
| SLH-DSA-SHA2-128s | 1 | 32 | 64 | 7,856 |
| SLH-DSA-SHA2-128f | 1 | 32 | 64 | 17,088 |
| Falcon-512 | 1 | 897 | 1,281 | 752 |
Note that each of these schemes can be instantiated at different security levels (e.g. RSA-2048, RSA-4096, ML-DSA-44, ML-DSA-65). These benchmarks are for the lowest level of security of all these schemes. This roughly corresponds to the security level of ECDSA-P256 or Ed25519.
Note that SLH-DSA has two variants “small” (s) and “fast” (f). The “small” variant creates smaller signatures, and the “fast” variant improves signature-generation time.
The key takeaway here is that the smallest Post-Quantum signatures (Falcon’s) are 10x larger than those generated by ECDSA / Ed25519 (which are those commonly used in the blockchain space), and the “small” variant of SLH-DSA has signatures that are 100x the size of the classical schemes that they’re replacing.
Speeds
These numbers were taken on my Macbook Pro (with Apple’s M3 Max chip). Benchmarks on different machines will always be a bit different, but these should give a sense of how these schemes compare.
Classical Signature speeds
| Algorithm | KeyGen (ms) | Sign (ms) | Verify (ms) |
|---|---|---|---|
| RSA-2048 | 67.376 | 0.859 | 0.025 |
| ECDSA-P256 | 0.015 | 0.024 | 0.048 |
| Ed25519 | 0.084 | 0.084 | 0.190 |
Post-Quantum Signature speeds
| Algorithm | KeyGen (ms) | Sign (ms) | Verify (ms) |
|---|---|---|---|
| ML-DSA-44 | 0.042 | 0.165 | 0.040 |
| SLH-DSA-SHA2-128s | 32.756 | 246.849 | 0.254 |
| SLH-DSA-SHA2-128f | 0.506 | 11.588 | 0.703 |
| SLH-DSA-SHAKE-128s | 55.061 | 418.913 | 0.412 |
| SLH-DSA-SHAKE-128f | 0.867 | 19.968 | 1.223 |
| Falcon-512 | 4.146 | 0.125 | 0.020 |
Note that the Apple M3 Max chip has the FEAT_SHA256 instruction that provides hardware acceleration for SHA256. This is likely why the SHA2 version of SLH-DSA runs faster than the SHAKE variant on this machine.
There are a handful of key takeways from the timings.
- Generating a single signature is quite fast — the usually under 1 millisecond, so the efficiency is only an issue for systems that are generating or verifying thousands of signatures
- Many of the Post-Quantum Schemes are actually faster than the classical schemes
- This means that the efficiency bottleneck with moving to Post-Quantum signatures is only in the size of the keys / signatures
The benchmarking scripts can be found in the git repo