# DSA: Why FIPS 186-5 Deprecates the Original Signature **Source**: https://quantumsequrity.com/blog/dsa-legacy-status **Category**: Cryptography Foundations --- [← Back to Blog](../../blog.html) Cryptography Foundations # DSA: Why FIPS 186-5 Deprecates the Original Signature 10 min read The Digital Signature Algorithm (DSA) was the first signature standard published by the US government, originally specified in FIPS 186 (1994) and refined through 186-2, 186-3, and 186-4. For nearly three decades, DSA was the alternative to RSA in the NIST signature catalog. PGP keys, Java keystores, OpenSSH connections, and countless legacy government deployments used DSA to authenticate documents, code, and connections. In February 2023, NIST published FIPS 186-5. The new standard does something unusual: it formally removes DSA from the approved list. ECDSA continues. EdDSA (Ed25519 and Ed448) joins the family. RSA-PSS and RSA with deterministic and probabilistic schemes remain. But the original DSA, which had been part of FIPS for 28 years, is gone. This article explains why NIST took this step, what was wrong with DSA, what the migration path looks like, and what happens to the systems still running DSA in 2026. ## What DSA Actually Is DSA is built on the discrete logarithm problem in a finite field. The signer chooses two primes p (large, typically 2048 or 3072 bits) and q (smaller, typically 224 or 256 bits) such that q divides p minus 1. A generator g of a subgroup of order q is computed. The private key x is a random integer modulo q. The public key is y = g raised to the x mod p. To sign a message m: 1. Pick a random nonce k in the range 1 to q-1. 2. Compute r = (g raised to the k mod p) mod q. 3. Compute s = (k raised to minus 1 times (H(m) plus x times r)) mod q, where H is a hash function like SHA-256. 4. The signature is the pair (r, s). To verify: 1. Compute w = s raised to minus 1 mod q. 2. Compute u1 = w times H(m) mod q and u2 = w times r mod q. 3. Compute v = ((g raised to the u1 times y raised to the u2) mod p) mod q. 4. Accept if v equals r. The math is a careful application of discrete logarithm cryptography. The security argument: forging a signature requires either solving a discrete log in the subgroup (computationally expensive at 2048+ bits) or guessing the private key. ## Why DSA Was Created In the early 1990s, RSA was the dominant signature scheme but was patented by RSA Security Inc. The patent expired in 2000, but during the 1990s the US government wanted a royalty-free signature standard for federal use. DSA was designed by NSA and proposed to NIST in 1991. The IEEE objected on multiple grounds (key sizes, hash function, performance), and there was public controversy. Despite the objections, NIST adopted DSA in FIPS 186 (1994). DSA filled the role of "open standard signature algorithm" until ECDSA was added in FIPS 186-2 (2000). After that, ECDSA gradually replaced DSA in deployments because: - ECDSA is much faster. - ECDSA produces smaller signatures (64 bytes for P-256 versus 56 bytes for DSA-2048-256, but ECDSA's 256-bit security is much higher than DSA's at the same size). - ECDSA scales better to higher security tiers (P-384, P-521). By 2010, DSA was largely a legacy choice maintained for compatibility with old systems. ## What Went Wrong With DSA Three structural issues drove DSA's deprecation: First, the random nonce k is catastrophic if it leaks or repeats. If two DSA signatures use the same k with the same private key, the private key can be recovered with simple algebra. The Sony PlayStation 3 was famously broken in 2010 because Sony's signing system used a fixed k value. The same problem hit countless smart card and embedded implementations. ECDSA inherits this problem from DSA. EdDSA (Ed25519, Ed448) explicitly fixes it by deriving k deterministically from the message and key. Second, DSA at smaller key sizes (1024-bit p, 160-bit q) became insecure as factoring and discrete-log algorithms improved. NIST raised the minimum to 2048-bit p and 224-bit q, but the upgrade path was awkward and never reached parity with elliptic curves on a per-bit basis. Third, DSA never adapted to modern requirements like deterministic signatures, batch verification, and constant-time implementation. ECDSA at least had a modern variant in EdDSA. DSA had no successor in its own form. ## The FIPS 186-5 Decision When NIST drafted FIPS 186-5 in 2019-2022, they evaluated which algorithms remained necessary. The conclusion: DSA had no use case that ECDSA, RSA-PSS, or EdDSA did not handle better. The final standard: - Removes DSA from approved signature algorithms. - Continues ECDSA over the NIST P-curves. - Adds EdDSA (Ed25519 and Ed448) as approved algorithms. - Continues RSA-PSS as the only approved RSA signature padding. - Deprecates RSA PKCS#1 v1.5 signatures for new deployments. NIST cryptographic guidance for federal agencies (SP 800-131A, "Transitioning the Use of Cryptographic Algorithms and Key Lengths") sets the timeline: DSA verification must stop by 2024 for federal systems. Existing DSA signatures may be verified for legacy purposes, but no new DSA signatures should be generated. ## What Is Still Running DSA in 2026 Despite the deprecation, DSA persists in: - Older OpenSSH installations. SSH-DSS keys (the SSH wire format for DSA) were widely deployed in the 2000s and 2010s. OpenSSH 7.0 (2015) disabled DSS by default. OpenSSH 9.0 (2022) removed support entirely. - OpenPGP / GnuPG. DSA keys remain valid in legacy OpenPGP key rings. RFC 9580 (2024) discourages DSA for new keys. - Java keystores (PKCS#12, JKS). Older Java applications that signed JAR files with DSA continue to verify, but new keys should not be generated. - Some cryptocurrency wallets and blockchain projects that adopted ECDSA but called it "DSA" in API documentation. (These are actually ECDSA, despite naming.) - Government archive systems where DSA-signed documents from the 1990s and 2000s remain in storage. The migration recommendation: replace DSA keys with Ed25519 (preferred) or ECDSA P-256 (acceptable for compatibility). Read more in [Ed25519 vs Ed448](ed25519-vs-ed448) and [NIST P-Curves: P-256, P-384, P-521](ecdh-curves-p256-p384-p521). ## ECDSA: The Continuing Choice ECDSA, defined alongside DSA in FIPS 186 family standards, uses elliptic-curve discrete log instead of finite-field discrete log. It produces much smaller keys for equivalent security: - DSA-2048-256: 2048-bit public key, 256-bit private key, 56-byte signature. - ECDSA P-256: 32-byte public key (compressed), 32-byte private key, 70-72-byte DER-encoded signature. ECDSA inherits DSA's nonce problem. The 2010 Sony PS3 break was technically against ECDSA. The 2013 Bitcoin wallet thefts also exploited weak ECDSA randomness. The hedged-randomness mitigation (RFC 6979 and others) derives the nonce deterministically from the message and key, just like EdDSA. This is now standard in modern ECDSA implementations including Bitcoin Core and Sigstore. ## EdDSA: The Modern Successor EdDSA (Ed25519 and Ed448), specified in IETF RFC 8032 and approved in NIST FIPS 186-5, is the modern signature scheme that replaces DSA conceptually: - Deterministic nonces by default. No randomness foot-gun. - Constant-time computation. Side-channel resistant. - Twist-secure curves. No invalid-curve attack surface. - Fast: 70,000 to 100,000 signatures per second on modern x86_64. - Compact: 32-byte public key, 64-byte signature. For new deployments, Ed25519 is the recommended choice. Ed448 for the 224-bit security tier. Read more in [Curve25519 Deep Dive](curve25519-deep-dive) and [X25519 and Ed25519 Explained](x25519-ed25519-explained). ## Quantum Resistance: All Discrete-Log Schemes Fall DSA, ECDSA, and EdDSA are all broken by Shor's algorithm on a sufficiently large quantum computer. The classical security tier (128, 192, 256 bits) translates to roughly the same quantum cost regardless of whether the underlying problem is finite-field DSA or elliptic-curve ECDSA. The post-quantum migration goes to ML-DSA (Module Lattice DSA, NIST FIPS 204) or SLH-DSA (Stateless Hash-Based DSA, NIST FIPS 205). ML-DSA is the general-purpose signature replacement. SLH-DSA has very large signatures but provides post-quantum security based purely on hash function properties. The NSA's CNSA 2.0 program (2022) requires migration of US national security signature workloads to ML-DSA or SLH-DSA by 2030. Read more in [What Is Post-Quantum Cryptography](what-is-post-quantum-cryptography), [ML-DSA vs SLH-DSA](mldsa-vs-slhdsa), and [Why RSA-2048 Will Break](why-rsa-2048-will-break). ## What QNSQY Uses QNSQY uses ML-DSA combined with Ed25519 in a hybrid signature scheme. An attacker forging a QNSQY signature must forge both halves: ML-DSA on the lattice side and Ed25519 on the elliptic-curve side. This provides defense in depth during the post-quantum transition. QNSQY does not use DSA, ECDSA, or RSA signatures. The signature pipeline is built around the FIPS 186-5 modern algorithms (Ed25519, ML-DSA) and not the deprecated FIPS 186-4 DSA. Read more in [Hybrid Encryption](hybrid-encryption) and [ML-DSA vs SLH-DSA](mldsa-vs-slhdsa). ## Why Ed25519 Was Not in FIPS Sooner A natural question: if Ed25519 was published in 2011 and widely deployed by 2014, why did NIST wait until 2023 to add it to FIPS 186-5? The honest answer is bureaucratic momentum. FIPS revisions are slow. NIST publishes drafts, collects public comment, addresses concerns, and finalizes specifications over a span of years. FIPS 186-4 (2013) was the most recent revision before 186-5 (2023). The intervening decade saw extensive deployment of Ed25519 in non-federal contexts (TLS, SSH, OpenPGP, Signal) but federal systems were technically restricted to ECDSA over P-curves and RSA. The 2023 update was driven partly by the post-quantum context. NIST recognized that the curve choice for the classical half of a hybrid post-quantum system mattered, and Ed25519 had become the defacto choice in commercial cryptography. Including it in FIPS 186-5 brought federal practice into alignment with the wider world. The same logic applied to Curve25519 (X25519) in NIST SP 800-186 (2023). After 17 years of being de facto, it became de jure. ## Migration Checklist for Legacy DSA Systems If you operate a system that still uses DSA in 2026, here is the practical migration plan: 1. Inventory. Find every key, certificate, and signature using DSA. SSH keys, OpenPGP keys, Java keystores, custom signing pipelines. 2. Generate replacement keys. For each DSA key, generate an Ed25519 (preferred) or ECDSA P-256 (acceptable) replacement. 3. Re-sign critical documents. Long-lived signatures (code signing, document archive) should be re-signed under the new key. 4. Update verification policy. Reject new DSA signatures. Accept legacy DSA signatures only for verification of pre-deprecation documents. 5. Plan for post-quantum. Even Ed25519 will need replacement by 2030-2033 in high-security environments. Hybrid Ed25519 plus ML-DSA is the modern recommendation. For SSH specifically: update OpenSSH to 9.0 or later, generate fresh ed25519 host keys (ssh-keygen -t ed25519), and migrate user keys away from DSS. The default ssh-keygen output is now ed25519 since OpenSSH 9.0. ## FAQ **Why was DSA removed but ECDSA kept?** ECDSA is much more efficient for the same security level. The NIST P-curves provide a clear migration path to higher security tiers (P-384, P-521). DSA at 3072 bits is much slower than ECDSA at P-384 for equivalent security. **Are DSA signatures from before 2024 still valid?** For verification of legacy documents, yes. Federal agencies may continue verifying pre-2024 DSA signatures. But new DSA signatures should not be generated, and software should plan to phase out DSA verification over time. **What about OpenPGP keys signed with DSA?** Existing DSA keys remain in key rings and can verify legacy signatures. New keys should be Ed25519 (preferred) or ECDSA. RFC 9580 (2024) is the modern OpenPGP specification. **Is ECDSA safe?** ECDSA is safe when implemented carefully, especially with deterministic nonces (RFC 6979). The historical breaks against ECDSA all came from poor randomness or side channels. Modern implementations like Sigstore, Bitcoin Core, and BoringSSL are robust. **What replaces DSA in the post-quantum world?** ML-DSA (Module Lattice DSA, FIPS 204) is the general-purpose replacement. SLH-DSA (Stateless Hash-Based DSA, FIPS 205) is the conservative alternative with larger signatures. ## Sources 1. NIST FIPS 186-5: Digital Signature Standard (DSS). https://csrc.nist.gov/pubs/fips/186-5/final 2. NIST SP 800-131A Rev. 3: Transitioning the Use of Cryptographic Algorithms and Key Lengths. https://csrc.nist.gov/pubs/sp/800/131/a/r3/final 3. NIST FIPS 186-4: Digital Signature Standard (DSS) (predecessor, withdrawn). https://csrc.nist.gov/pubs/fips/186-4/final 4. IETF RFC 6979: Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA). https://www.rfc-editor.org/rfc/rfc6979 5. IETF RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA). https://www.rfc-editor.org/rfc/rfc8032 6. NIST FIPS 204: Module-Lattice-Based Digital Signature Standard. https://csrc.nist.gov/pubs/fips/204/final ## Related Articles - [ML-DSA vs SLH-DSA](mldsa-vs-slhdsa) - [Ed25519 vs Ed448](ed25519-vs-ed448) - [X25519 and Ed25519 Explained](x25519-ed25519-explained) - [NIST FIPS Guide](nist-fips-guide) - [Why RSA-2048 Will Break](why-rsa-2048-will-break) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)