Skip to content

PATTERN Cited by 1 source

Security margin parameter hedging

Context

Cryptanalytic attack algorithms improve over time. An algorithm parametrised at exactly 128-bit security today may be below 128 bits after the next advance. Parameter selection must account for future cryptanalysis.

Problem

How much security margin to add when selecting algorithm parameters, given that larger parameters mean larger signatures/keys and slower operations?

Solution

Deploy with parameters that exceed the target security level by a meaningful margin, accounting for the algorithm family's historical attack-improvement rate:

  • ML-DSA-44: Targets ~160-bit security (30+ bits above the 128-bit minimum). Cost: slightly larger than the minimum possible lattice signature.
  • UOV: Can tune to arbitrary intermediate levels. A 160-bit parametrisation costs only ~260 B signatures but 446 kB public keys at 256-bit.
  • MAYO: Granular security tuning — a 174-bit parametrisation achieves 1,600 B pubkey + 550 B signature, comfortably ahead of FN-DSA-1024.

Anti-pattern: Missing middle security levels

Some algorithms (FN-DSA, HAWK) have only two security levels with no intermediate option: - FN-DSA-512: 128-bit security - FN-DSA-1024: 256-bit security (double all sizes)

If lattice cryptanalysis removes even a few bits from 128, the only option is a full jump to 256 — an expensive, disruptive upgrade. This "missing middle" is a significant deployment risk.

(Source: sources/2026-07-09-cloudflare-post-quantum-signature-algorithms)

Consequences

  • Systems that can tolerate the size overhead should deploy with security margins above 128 bits.
  • Prefer algorithms with granular parameter flexibility over those with a small fixed set of security levels.
  • Budget for parameter-set upgrades as cryptanalysis advances; design protocols for crypto-agility.

Seen in

Last updated · 575 distilled / 1,757 read