365 Architect

08 — When to Use SLH-DSA

The Core Principle

Use SLH-DSA when you need maximum trustworthiness and can tolerate larger signatures and slower signing.

Primary Use Cases

1. Trust Anchors (Root Certificates)

What: The top-level certificate in a PKI hierarchy.

Why SLH-DSA:

  • Compromise of a root CA is catastrophic — all descendants are untrusted
  • Root certificates sign rarely (monthly or yearly) but verify constantly (billions of times daily)
  • Large signatures are irrelevant (root certs are distributed out-of-band)
  • Conservative security is paramount

Deployment:

Root CA (SLH-DSA-SHA2-192s, Level 3)
    |
    signs
    |
Intermediate CA (ML-DSA-65)
    |
    signs
    |
End-entity certs (ML-DSA-65)

The root uses SLH-DSA for maximum confidence. The intermediates and leaves use ML-DSA for performance.

2. Long-Term Notarisation

What: Proof that a document existed at a specific time.

Why SLH-DSA:

  • Document signatures must remain valid for 20–50 years
  • Lattice security assumptions may evolve over decades
  • Hash function security is better understood for long timeframes
  • Signature size is irrelevant (stored alongside multi-megabyte documents)

Deployment:

Document Archive:
  - Original document (PDF)
  - Timestamp (RFC 3161)
  - SLH-DSA signature (SHA2-192s)
  - ML-DSA signature (ML-DSA-65)
  - Classical ECDSA signature (legacy)

Multiple signatures provide algorithmic redundancy.

3. Algorithm Agility / Fallback

What: Pre-position a fallback algorithm in case lattices fail.

Why SLH-DSA:

  • Signatures can be added to existing documents without invalidating them
  • Provides an "insurance policy" against cryptanalytic breakthroughs
  • No runtime cost until needed

Deployment:

Software Release Package:
  - Binary
  - ML-DSA signature (primary)
  - ECDSA signature (legacy compatibility)
  - SLH-DSA signature (fallback)

Clients verify whichever algorithm they support. If ML-DSA is broken, SLH-DSA signatures remain valid.

4. High-Assurance Environments

What: Military, nuclear, voting, financial infrastructure.

Why SLH-DSA:

  • Minimal mathematical assumptions
  • No floating-point arithmetic (unlike FN-DSA)
  • No structured algebraic objects (unlike ML-DSA)
  • Side-channel resistance is straightforward (only hash functions)

5. "Break Glass" Emergency Signatures

What: Pre-signed revocation statements or emergency updates.

Why SLH-DSA:

  • Generated once, stored offline
  • Activated only if primary algorithms are compromised
  • Stateless — no key tracking needed during long dormancy

When NOT to Use SLH-DSA

Scenario Why not Alternative
TLS handshakes 8 KB signatures blow up handshake size ML-DSA or hybrid
Blockchain transactions 8 KB × thousands of tx = gigabytes ML-DSA or FN-DSA
High-frequency signing 10 ms per signature is too slow ML-DSA (~0.5 ms)
Embedded/IoT (very constrained) Signature larger than firmware FN-DSA or LMS/XMSS (stateful)
Interactive protocols Latency matters ML-DSA

Deployment Checklist

Phase 1: Preparation (Weeks 1–4)

  • Identify systems requiring highest-assurance signatures
  • Inventory existing PKI hierarchy
  • Select parameter set (typically SHA2-192s or SHAKE-256s)
  • Evaluate HSM compatibility (many HSMs don't yet support SLH-DSA)

Phase 2: Pilot (Weeks 5–8)

  • Generate SLH-DSA root CA keypair (offline, air-gapped ceremony)
  • Issue test intermediate certificate
  • Test verification in target systems (browsers, libraries, firmware)
  • Measure performance impact on signing pipeline

Phase 3: Production (Weeks 9–12)

  • Deploy SLH-DSA root CA (or sub-CA under existing root)
  • Enable dual-signature verification (classical + SLH-DSA)
  • Monitor: verification failures, latency, client compatibility
  • Document: key ceremony procedures, backup, disaster recovery

Phase 4: Maintenance (Ongoing)

  • Annual key ceremony review
  • Track NIST/NSA guidance updates
  • Plan for algorithm updates (FIPS 205 revisions)
  • Maintain offline backup of master seed

Resources

★★★★★
Share on LinkedIn