365 Architect

07 — When to Use FN-DSA

The Value Proposition

FN-DSA gives you the smallest post-quantum signatures available — 666 B at Level 1, 1,280 B at Level 5 — with verification speed comparable to ECDSA.

The trade-off is more complex implementation (floating-point, FFT, Gaussian sampling) and moderate signing speed.

Primary Use Cases

1. TLS and HTTPS (Bandwidth-Constrained)

Problem: ML-DSA-65 adds 3.3 KB to every TLS handshake. For high-traffic sites, this is significant:

  • 1 million handshakes/day = 3.3 GB extra bandwidth
  • CDN costs scale with bandwidth
  • Mobile users pay for data

FN-DSA-512 solution:

  • Signature: 666 B (5× smaller than ML-DSA-65)
  • Total handshake increase: ~1.5 KB vs. ~6 KB with ML-DSA
  • Savings: ~75% reduction in PQC handshake overhead

Deployment:

TLS 1.3 configuration:
  signature_algorithms: fn-dsa-512, ecdsa_secp256r1
  
Server certificate:
  - Public key algorithm: FN-DSA-512
  - Signature on cert: FN-DSA-512 (self-signed root) or ML-DSA-65 (intermediate)

Status: CA/Browser Forum is updating baseline requirements. FN-DSA is expected to be approved for end-entity certificates by 2026–2027.

2. Blockchain and Distributed Ledgers

Problem: Blockchain transactions are permanent and replicated. Signature size directly affects:

  • Block size and frequency
  • Storage costs for full nodes
  • Network propagation latency
  • Transaction fees (per-byte pricing)
Blockchain Current sig With ML-DSA-65 With FN-DSA-512 Annual storage impact*
Bitcoin 72 B 3,293 B 666 B ML-DSA: +450 TB; FN-DSA: +91 TB
Ethereum 65 B 3,293 B 666 B ML-DSA: +2,100 TB; FN-DSA: +425 TB
Cardano 64 B 3,293 B 666 B ML-DSA: +180 TB; FN-DSA: +36 TB

*Assuming 300M transactions/year

Solutions:

  • Layer 1: Use FN-DSA-512 directly (small signatures)
  • Layer 2: Aggregate multiple signatures into one (further reduction)
  • Batched verification: Verify many FN-DSA signatures simultaneously (amortised cost)

3. Internet of Things (IoT)

Problem: IoT devices have severe constraints:

  • RAM: 8–64 KB
  • Flash: 128 KB–1 MB
  • Bandwidth: LoRaWAN (51 B/frame), NB-IoT (~1 KB/message)
  • Power: Battery-operated, must last years
Device type RAM Flash Can fit ML-DSA-65? Can fit FN-DSA-512?
LoRaWAN sensor 16 KB 128 KB No (signature alone = 25% RAM) Maybe (fragmented)
Smart meter (NB-IoT) 64 KB 512 KB Tight Yes
Industrial gateway 256 KB 2 MB Yes Yes easily
Medical implant 8 KB 64 KB No No

FN-DSA-512 advantages:

  • Smaller signatures = fewer radio transmissions = less power
  • Can fit in single LoRaWAN frame (with fragmentation)
  • Verification is fast (low CPU usage = low power)

Caveat: FP arithmetic may require software FP library on processors without hardware FPU (~10 KB code overhead).

4. Smart Cards and Secure Elements

Problem: Smart cards have:

  • EEPROM: 32–256 KB (for keys and certificates)
  • RAM: 2–8 KB (for computation)
  • CPU: 8–32 MHz (slow)
  • No floating-point unit (on most cards)
Resource ML-DSA-65 FN-DSA-512 Impact
Certificate storage 3.3 KB sig 666 B sig FN-DSA: 5× more certs in same EEPROM
RAM during verify ~8 KB ~6 KB Similar
Code footprint ~20 KB ~30 KB (+FP lib) FN-DSA larger (needs FP or NTT lib)
Verify time ~0.12 ms ~0.08 ms FN-DSA slightly faster

Best practice: For smart cards, use FN-DSA-512 for verification (fast, small sigs) and offload signing to a server or HSM.

5. Code and Firmware Signing

Problem: Software updates are signed to prevent malware injection. Large signatures:

  • Increase download size (user pays for mobile data)
  • Slow down update checks (more data to transfer)
  • Complicate delta updates (signature invalidates binary diff)
Firmware size ECDSA ML-DSA-65 FN-DSA-512 User impact
1 MB +64 B +3,293 B +666 B Negligible for all
10 MB +64 B +3,293 B +666 B Negligible for all
100 KB +64 B +3,293 B +666 B FN-DSA: 0.7% overhead; ML-DSA: 3.3%

Recommendation: For most code signing, ML-DSA-65 is sufficient (simple implementation, well-supported tools). Use FN-DSA-512 only when:

  • Firmware is very small (< 500 KB)
  • Update frequency is very high (hourly checks)
  • Bandwidth is severely constrained (satellite, rural)

When NOT to Use FN-DSA

Scenario Why not Alternative
General-purpose enterprise Complex implementation, FP risks ML-DSA-65 (simpler, safer)
High-frequency signing (>1000/s) Signing is slower than ML-DSA ML-DSA-65 (~0.5 ms vs. ~0.5 ms, but simpler)
Side-channel sensitive (smart cards) FP side channels are hard to mitigate SLH-DSA (no FP, stateless)
Trust anchors / long-term Lattice assumptions less conservative than hashes SLH-DSA (conservative)
Teams without FP expertise Implementation errors likely ML-DSA-65 (integer-only, easier to audit)

Deployment Checklist

Phase 1: Assessment (Weeks 1–2)

  • Measure current signature sizes in your protocols
  • Calculate bandwidth cost of ML-DSA-65 vs. FN-DSA-512
  • Assess FP side-channel risks in your environment
  • Verify HSM/smart card supports FN-DSA (many don't yet)

Phase 2: Pilot (Weeks 3–6)

  • Select 1–2 systems where size matters most
  • Implement FN-DSA-512 using reference code (test only)
  • Run dudect/ctgrind for side-channel testing
  • Measure performance vs. ML-DSA-65 on target hardware

Phase 3: Production (Weeks 7–12)

  • Deploy with feature flag (canary: 5% → 25% → 100%)
  • Monitor: handshake failures, latency p99, error rates
  • Maintain ML-DSA-65 as fallback during transition
  • Document: key ceremony, HSM procedures, audit trail

Resources

★★★★★
Share on LinkedIn