01 — Why Small Signatures?
The Hidden Cost of Large Signatures
Every digital signature adds overhead to a message, transaction, or handshake. In most enterprise systems, a few kilobytes seem negligible. But in specific scenarios, signature size is the dominant factor — and can make or break a protocol.
Where Size Matters
1. Blockchain Transactions
| Blockchain | Transaction size | ECDSA sig | ML-DSA-65 sig | FN-DSA-512 sig |
|---|---|---|---|---|
| Bitcoin | ~250 B | 72 B | 3,293 B | 666 B |
| Ethereum | ~150 B | 65 B | 3,293 B | 666 B |
| Cardano | ~300 B | 64 B | 3,293 B | 666 B |
Impact:
- Bitcoin with ML-DSA: 13× larger transactions → 13× blockchain growth
- Ethereum gas fees are per-byte: ML-DSA = 22× more expensive
- FN-DSA-512: Only 2.7× larger than ECDSA — manageable with layer-2 scaling
2. TLS Handshakes
A typical TLS 1.3 handshake without client certificates:
Component Size (classical) Size (ML-DSA-65) Size (FN-DSA-512)
ClientHello ~150 B ~150 B ~150 B
ServerHello + extensions ~200 B ~200 B ~200 B
Certificate chain ~2,000 B ~2,000 B ~2,000 B
Certificate signature 64 B (ECDSA) 3,293 B 666 B
CertificateVerify (server) 64 B 3,293 B 666 B
Finished ~40 B ~40 B ~40 B
Total handshake: ~2,518 B ~8,976 B ~3,722 B
ML-DSA-65 increases handshake by 3.6×. FN-DSA-512 increases by only 1.5×.
3. Internet of Things (IoT)
| IoT Protocol | Payload budget | Signature overhead |
|---|---|---|
| LoRaWAN | 51 bytes per frame | ML-DSA doesn't fit; FN-DSA barely fits with fragmentation |
| NB-IoT | ~1 KB per message | ML-DSA = 3× payload; FN-DSA = 0.7× payload |
| MQTT (constrained) | ~100 B typical | ML-DSA = 33× payload; FN-DSA = 6.7× payload |
| Bluetooth LE | ~20 B per packet | Neither fits without segmentation |
4. Smart Cards and Secure Elements
| Device | Storage | RAM | ML-DSA-65 sig | FN-DSA-512 sig |
|---|---|---|---|---|
| JavaCard (classic) | 80 KB | 2 KB | Doesn't fit | Doesn't fit |
| JavaCard (extended) | 500 KB | 8 KB | Fits, but 41% of storage | Fits, 8% of storage |
| NFC Type 4 tag | 32 KB | N/A | Doesn't fit | Fits (2% of storage) |
| TPM 2.0 | 2 MB NV | 16 KB RAM | Fits easily | Fits easily |
5. Embedded Firmware
Firmware updates for constrained devices (medical implants, industrial sensors):
| Firmware size | Update frequency | Overhead per update (ML-DSA) | Overhead (FN-DSA) |
|---|---|---|---|
| 64 KB | Monthly | 3,293 B = 5.1% | 666 B = 1.0% |
| 256 KB | Weekly | 3,293 B = 1.3% | 666 B = 0.26% |
| 1 MB | Daily | 3,293 B = 0.32% | 666 B = 0.07% |
For small firmware, ML-DSA signatures can exceed 5% of the update size. FN-DSA stays under 1%.
The Size Hierarchy
| Signature scheme | Size | Relative to ECDSA |
|---|---|---|
| ECDSA P-256 | 64 B | 1× (baseline) |
| Ed25519 | 64 B | 1× |
| RSA-2048 | 256 B | 4× |
| FN-DSA-512 | 666 B | 10× |
| FN-DSA-1024 | 1,280 B | 20× |
| ML-DSA-44 | 2,420 B | 38× |
| ML-DSA-65 | 3,293 B | 51× |
| ML-DSA-87 | 4,595 B | 72× |
| SLH-DSA-SHA2-128s | 7,856 B | 123× |
| SLH-DSA-SHA2-128f | 17,064 B | 267× |
FN-DSA-512 is 4–5× smaller than ML-DSA-65 and 10× smaller than SLH-DSA-SHA2-128s.
When FN-DSA Is Essential vs. Nice-to-Have
| Scenario | Size critical? | Recommended |
|---|---|---|
| TLS 1.3 (high traffic) | Yes | FN-DSA-512 or hybrid with ECDSA |
| Blockchain layer 1 | Critical | FN-DSA-512 (or aggregation) |
| IoT (LoRaWAN, NB-IoT) | Critical | FN-DSA-512 with fragmentation |
| Smart card (constrained) | Critical | FN-DSA-512 if card supports floating-point |
| Code signing | No | ML-DSA-65 (simpler, well-supported) |
| Document signing | No | ML-DSA-65 or ML-DSA-87 |
| Firmware updates (>1 MB) | No | ML-DSA-65 |
| Root CA certificates | No | SLH-DSA (conservative) |
Resources
- FALCON performance benchmarks: falcon-sign.info/benchmarks.html
- PQCrypto blog post: "Why signature size matters" (2019)