Recent from talks
Nothing was collected or created yet.
Digital Signature Algorithm
View on WikipediaThe Digital Signature Algorithm (DSA) is a public-key cryptosystem and Federal Information Processing Standard for digital signatures, based on the mathematical concept of modular exponentiation and the discrete logarithm problem. In a digital signature system, there is a keypair involved, consisting of a private and a public key. In this system a signing entity that declared their public key can generate a signature using their private key, and a verifier can assert the source if it verifies the signature correctly using the declared public key. DSA is a variant of the Schnorr and ElGamal signature schemes.[1]: 486
The National Institute of Standards and Technology (NIST) proposed DSA for use in their Digital Signature Standard (DSS) in 1991, and adopted it as FIPS 186 in 1994.[2] Five revisions to the initial specification have been released. The newest specification is: FIPS 186-5 from February 2023.[3] DSA is patented but NIST has made this patent available worldwide royalty-free. Specification FIPS 186-5 indicates DSA will no longer be approved for digital signature generation, but may be used to verify signatures generated prior to the implementation date of that standard.
Overview
[edit]The DSA works in the framework of public-key cryptosystems and is based on the algebraic properties of modular exponentiation, together with the discrete logarithm problem, which is considered to be computationally intractable. The algorithm uses a key pair consisting of a public key and a private key. The private key is used to generate a digital signature for a message, and such a signature can be verified by using the signer's corresponding public key. The digital signature provides message authentication (the receiver can verify the origin of the message), integrity (the receiver can verify that the message has not been modified since it was signed) and non-repudiation (the sender cannot falsely claim that they have not signed the message).
History
[edit]In 1982, the U.S government solicited proposals for a public key signature standard. In August 1991 the National Institute of Standards and Technology (NIST) proposed DSA for use in their Digital Signature Standard (DSS). Initially there was significant criticism, especially from software companies that had already invested effort in developing digital signature software based on the RSA cryptosystem.[1]: 484 Nevertheless, NIST adopted DSA as a Federal standard (FIPS 186) in 1994. Five revisions to the initial specification have been released: FIPS 186–1 in 1998,[4] FIPS 186–2 in 2000,[5] FIPS 186–3 in 2009,[6] FIPS 186–4 in 2013,[3] and FIPS 186–5 in 2023.[7] Standard FIPS 186-5 forbids signing with DSA, while allowing verification of signatures generated prior to the implementation date of the standard as a document. It is to be replaced by newer signature schemes such as EdDSA.[8]
DSA is covered by U.S. patent 5,231,668, filed July 26, 1991 and now expired, and attributed to David W. Kravitz,[9] a former NSA employee. This patent was given to "The United States of America as represented by the Secretary of Commerce, Washington, D.C.", and NIST has made this patent available worldwide royalty-free.[10] Claus P. Schnorr claims that his U.S. patent 4,995,082 (also now expired) covered DSA; this claim is disputed.[11]
In 1993, Dave Banisar managed to get confirmation, via a FOIA request, that the DSA algorithm hasn't been designed by the NIST, but by the NSA.[12]
OpenSSH announced that DSA was going to be removed in 2025. The support was entirely dropped in version 10.0.[13][14]
Operation
[edit]The DSA algorithm involves four operations: key generation (which creates the key pair), key distribution, signing and signature verification.
1. Key generation
[edit]Key generation has two phases. The first phase is a choice of algorithm parameters which may be shared between different users of the system, while the second phase computes a single key pair for one user.
Parameter generation
[edit]- Choose an approved cryptographic hash function with output length bits. In the original DSS, was always SHA-1, but the stronger SHA-2 hash functions are approved for use in the current DSS.[3][15] If is greater than the modulus length , only the leftmost bits of the hash output are used.
- Choose a key length . The original DSS constrained to be a multiple of 64 between 512 and 1024 inclusive. NIST 800-57 recommends lengths of 2048 (or 3072) for keys with security lifetimes extending beyond 2010 (or 2030).[16]
- Choose the modulus length such that and . FIPS 186-4 specifies and to have one of the values: (1024, 160), (2048, 224), (2048, 256), or (3072, 256).[3]
- Choose an -bit prime .
- Choose an -bit prime such that is a multiple of .
- Choose an integer randomly from .
- Compute . In the rare case that try again with a different . Commonly is used. This modular exponentiation can be computed efficiently even if the values are large.
The algorithm parameters are (, , ). These may be shared between different users of the system.
Per-user keys
[edit]Given a set of parameters, the second phase computes the key pair for a single user:
- Choose an integer randomly from .
- Compute .
is the private key and is the public key.
2. Key distribution
[edit]The signer should publish the public key . That is, they should send the key to the receiver via a reliable, but not necessarily secret, mechanism. The signer should keep the private key secret.
3. Signing
[edit]A message is signed as follows:
- Choose an integer randomly from
- Compute . In the unlikely case that , start again with a different random .
- Compute . In the unlikely case that , start again with a different random .
The signature is
The calculation of and amounts to creating a new per-message key. The modular exponentiation in computing is the most computationally expensive part of the signing operation, but it may be computed before the message is known. Calculating the modular inverse is the second most expensive part, and it may also be computed before the message is known. It may be computed using the extended Euclidean algorithm or using Fermat's little theorem as .
4. Signature Verification
[edit]One can verify that a signature is a valid signature for a message as follows:
- Verify that and .
- Compute .
- Compute .
- Compute .
- Compute .
- The signature is valid if and only if .
Correctness of the algorithm
[edit]The signature scheme is correct in the sense that the verifier will always accept genuine signatures. This can be shown as follows:
First, since , it follows that by Fermat's little theorem. Since and is prime, must have order .
The signer computes
Thus
Since has order we have
Finally, the correctness of DSA follows from
Sensitivity
[edit]With DSA, the entropy, secrecy, and uniqueness of the random signature value are critical. It is so critical that violating any one of those three requirements can reveal the entire private key to an attacker.[17] Using the same value twice (even while keeping secret), using a predictable value, or leaking even a few bits of in each of several signatures, is enough to reveal the private key .[18]
This issue affects both DSA and Elliptic Curve Digital Signature Algorithm (ECDSA) – in December 2010, the group fail0verflow announced the recovery of the ECDSA private key used by Sony to sign software for the PlayStation 3 game console. The attack was made possible because Sony failed to generate a new random for each signature.[19]
This issue can be prevented by deriving deterministically from the private key and the message hash, as described by RFC 6979. This ensures that is different for each and unpredictable for attackers who do not know the private key .
In addition, malicious implementations of DSA and ECDSA can be created where is chosen in order to subliminally leak information via signatures. For example, an offline private key could be leaked from a perfect offline device that only released innocent-looking signatures.[20]
Implementations
[edit]Below is a non-exhaustive list of cryptographic libraries that provide support for DSA:
See also
[edit]References
[edit]- ^ a b Schneier, Bruce (1996). Applied Cryptography. Wiley. ISBN 0-471-11709-9.
- ^ "FIPS PUB 186: Digital Signature Standard (DSS), 1994-05-19". qcsrc.nist.gov. Archived from the original on 2013-12-13.
- ^ a b c d "FIPS PUB 186-4: Digital Signature Standard (DSS), July 2013" (PDF). csrc.nist.gov.
- ^ "FIPS PUB 186-1: Digital Signature Standard (DSS), 1998-12-15" (PDF). csrc.nist.gov. Archived from the original (PDF) on 2013-12-26.
- ^ "FIPS PUB 186-2: Digital Signature Standard (DSS), 2000-01-27" (PDF). csrc.nist.gov.
- ^ "FIPS PUB 186-3: Digital Signature Standard (DSS), June 2009" (PDF). csrc.nist.gov.
- ^ "FIPS PUB 186-5: Digital Signature Standard (DSS), February 2023" (PDF). csrc.nist.gov.
- ^ "Digital Signature Standard (DSS)". U.S. Department of Commerce. 31 October 2019. Retrieved 21 July 2020.
- ^ Dr. David W. Kravitz Archived January 9, 2013, at the Wayback Machine
- ^ Werner Koch. "DSA and patents"
- ^ "1994 Annual Report of CSSPAB". 26 August 2009. Archived from the original on 26 August 2009.
- ^ Neumann, Peter G. (2020-02-29). "The RISKS Digest Volume 14 Issue 59". Archived from the original on 2020-02-29. Retrieved 2023-10-03.
{{cite web}}: CS1 maint: bot: original URL status unknown (link) - ^ "OpenSSH announces DSA-removal timeline [LWN.net]". lwn.net. Retrieved 11 January 2024.
- ^ "OpenSSH version 10.0. release notes". Retrieved 21 April 2025.
- ^ "FIPS PUB 180-4: Secure Hash Standard (SHS), March 2012" (PDF). csrc.nist.gov.
- ^ "NIST Special Publication 800-57" (PDF). csrc.nist.gov. Archived from the original (PDF) on 2014-06-06.
- ^ "The Debian PGP disaster that almost was". root labs rdist. 18 May 2009.
- ^ DSA -value Requirements
- ^ Bendel, Mike (2010-12-29). "Hackers Describe PS3 Security As Epic Fail, Gain Unrestricted Access". Exophase.com. Retrieved 2011-01-05.
- ^ Verbücheln, Stephan (2 January 2015). "How Perfect Offline Wallets Can Still Leak Bitcoin Private Keys". arXiv:1501.00447 [cs.CR].
- ^ "Public Key Cryptography — Botan". botan.randombit.net. Retrieved 2025-12-15.
- ^ "Bouncy Castle Releases Java 1.81 and C# .NET 2.6.1". Bouncycastle. Retrieved 2025-12-15.
- ^ https://cryptlib.com/downloads/manual.pdf [bare URL PDF]
- ^ "Digital Signature Algorithm - Crypto++ Wiki". www.cryptopp.com. Retrieved 2025-12-15.
- ^ "Cryptographic Functions (The Libgcrypt Reference Manual)". www.gnupg.org. Retrieved 2025-12-15.
- ^ "Nettle: a low-level cryptographic library". www.lysator.liu.se. Retrieved 2025-12-15.
- ^ "dsa - OpenSSL Documentation". docs.openssl.org. Retrieved 2025-12-15.
- ^ "wolfSSL User Manual | Chapter 10: wolfCrypt Usage Reference | Docs". wolfSSL (in Japanese). Retrieved 2025-12-15.
- ^ "Public key algorithms (GnuTLS 3.8.10)". www.gnutls.org. Retrieved 2025-12-15.
External links
[edit]- FIPS PUB 186-4: Digital Signature Standard (DSS), the fourth (and current) revision of the official DSA specification.
- Recommendation for Key Management -- Part 1: general, NIST Special Publication 800-57, p. 62–63
Digital Signature Algorithm
View on GrokipediaIntroduction
Overview
The Digital Signature Algorithm (DSA) is a public-key cryptographic standard specified in the Federal Information Processing Standard (FIPS) 186 for generating and verifying digital signatures, providing authentication of the signer and integrity of the signed data.[1] It relies on the computational difficulty of the discrete logarithm problem in finite fields to ensure security.[1] Originally proposed by the National Institute of Standards and Technology (NIST) in 1991 as part of the Digital Signature Standard (DSS), DSA was designed for federal use in protecting unclassified information and has since been adopted in various applications.[3] At a high level, DSA operates through a key pair consisting of a private key known only to the signer and a corresponding public key available to verifiers. To sign a message, the signer hashes the message using an approved function and combines it with the private key and a random per-message value to produce a signature pair. Verification involves recomputing the hash and using the public key to check the signature's validity against the original message.[1] Unlike RSA signatures, which are based on the difficulty of integer factorization and involve direct exponentiation of the message hash, DSA employs modular exponentiation over a finite field with carefully selected parameters such as large primes p and q, and a generator g.[1] DSA typically pairs with hash functions from the SHA family, such as SHA-1 or members of SHA-2 (e.g., SHA-256), to process messages before signing.[1]Historical Development
The Digital Signature Algorithm (DSA) draws its foundational concepts from earlier discrete logarithm-based signature schemes, notably the ElGamal signature scheme introduced by Taher ElGamal in 1985, which provided a framework for public-key signatures relying on the computational difficulty of the discrete logarithm problem in finite fields.[7] This work influenced subsequent developments in digital signatures by demonstrating how discrete logs could enable secure, verifiable authentication without revealing private keys. DSA adapted and refined these ideas to create a more efficient variant tailored for standardization. DSA was created collaboratively by the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA). In 1991, NIST, in collaboration with the NSA, proposed DSA as the core component of the Digital Signature Standard (DSS), aiming to establish a federal standard for digital signatures in applications like electronic mail and data interchange.[3] NIST adopted DSA into Federal Information Processing Standard (FIPS) 186 on May 19, 1994, marking its formal integration into U.S. government cryptographic practices.[8] Subsequent revisions refined the algorithm to address evolving security needs: FIPS 186-1 in 1998 added RSA as an option and clarified aspects of DSA parameter generation; FIPS 186-2 in 2000 introduced elliptic curve variants (ECDSA) and approved SHA-1 as a hash function; FIPS 186-3 in 2009 added support for SHA-2 hashes and larger key sizes; and FIPS 186-4 in 2013 further expanded elliptic curve options while approving additional SHA-2 hashes such as SHA-256 and increasing DSA modulus sizes to 2048 or 3072 bits for enhanced security.[9] Despite this, DSA has become less efficient for modern systems due to the need for significantly larger key sizes compared to elliptic curve cryptography (ECC) variants like ECDSA to achieve equivalent security levels. As of 2025, under FIPS 186-5 (issued February 3, 2023), DSA is approved solely for legacy verification purposes, with ECDSA and other algorithms preferred for new digital signature generations to align with current performance and security priorities.[10]Cryptographic Foundations
As of FIPS 186-5 (published February 2023), DSA is deprecated for generating new digital signatures and approved only for verifying existing signatures generated under prior standards. The parameters and key generation below are as specified in the withdrawn FIPS 186-4.[5][1]System Parameters
The Digital Signature Algorithm (DSA) relies on a set of global system parameters that define the underlying finite field and subgroup for cryptographic operations. These parameters are fixed for a given domain or application and must be generated or selected with high assurance to ensure security. The primary parameters are the prime modulus , the subgroup order , and the generator .[1] The prime modulus is a large prime number with bit length (approved values: 1024, 2048, or 3072), chosen such that divides , ensuring a cyclic subgroup of order modulo where the discrete logarithm problem is computationally hard. Generation methods in FIPS 186-4 produce p with appropriate factors of p-1 to resist known attacks. Specifically, , with generation involving probabilistic primality testing like the Miller-Rabin algorithm applied over multiple rounds to verify primality with overwhelming probability.[1] The subgroup order is a prime number of 160 to 256 bits that exactly divides , forming a large prime factor of to create a suitable cyclic subgroup for the discrete logarithm problem. Specifically, for approved values of 160 (with ), 224 (with ), or 256 (with or 3072). Like , undergoes primality testing via Miller-Rabin, and its selection ensures the subgroup provides adequate security without excessive computational cost. NIST recommends parameter sets from FIPS 186-4, such as (2048-bit , 224-bit ) for 112-bit security strength and (3072-bit , 256-bit ) for 128-bit security, aligning with symmetric key equivalents per SP 800-57.[1][11][1] The generator is an integer between 1 and that serves as a primitive element of the subgroup of order in the multiplicative group modulo . It is computed by selecting a random base (where ) and setting ; if , a new is chosen until . To verify that the order of is exactly , check that and that no smaller positive exponent divides to yield 1 (since is prime, this primarily confirms , but full verification tests against divisors ensure the subgroup property). The generation process for all parameters uses a seed and hash function (e.g., SHA-256) in a deterministic manner, as specified in FIPS 186-4 Appendix A, to allow reproducible validation.[1][1]| Approved Parameter Sets (L, N) | Bit Length of p (L) | Bit Length of q (N) | Security Strength (bits) |
|---|---|---|---|
| (1024, 160) | 1024 | 160 | 80 |
| (2048, 224) | 2048 | 224 | 112 |
| (2048, 256) | 2048 | 256 | 128 |
| (3072, 256) | 3072 | 256 | 128 |
Key Generation
The key generation process in the Digital Signature Algorithm (DSA) produces a pair of mathematically related keys: a private key for signing and a public key for verification, derived from the shared system parameters , , and . The private key is selected as a random integer in the interval , where has bit length (approved values: 160, 224, or 256 bits), ensuring has sufficient entropy to resist brute-force attacks.[1] This selection must employ a cryptographically secure pseudorandom number generator (CSPRNG), approved by standards such as those in NIST SP 800-90A, to provide uniform distribution and unpredictability, matching the security strength of the parameter set (e.g., at least 112 bits for ).[1] The public key is then computed as where has bit length (1024, 2048, or 3072 bits), resulting in being an -bit integer in .[1] This exponentiation leverages the discrete logarithm problem's hardness in the subgroup generated by modulo , ensuring that recovering from , , and is computationally infeasible for appropriately chosen parameters.[1] Upon generation, the key pair undergoes validation to confirm integrity: specifically, verify that (indicating ) and that the discrete logarithm remains intractable, which holds under the system's security assumptions without explicit computation of the logarithm.[1] The private key must be stored securely, using mechanisms like hardware security modules or encrypted storage as per key management guidelines, to prevent exposure that could compromise signatures.[12] Conversely, the public key is disseminated openly, typically embedded in digital certificates conforming to standards like X.509 for trust anchoring in public key infrastructures.[12]Core Operations
Signature Generation
The signature generation process in the Digital Signature Algorithm (DSA) produces a digital signature as a pair of integers for a given message , using the signer's private key and the domain parameters , , and . This step ensures the message's authenticity and integrity by binding it cryptographically to the private key, which corresponds to the public key . The process is probabilistic, relying on a fresh random value to achieve security against forgery. To begin, preprocess the message by computing its hash value using an approved cryptographic hash function, such as SHA-256, which outputs a fixed-length digest. If the hash output length exceeds the bit length of the prime , truncate to the leftmost bits to obtain the value used in subsequent computations. This hashing step reduces the message to a compact representation suitable for the modular arithmetic in DSA, ensuring efficiency while preserving collision resistance properties essential for security. Next, generate a random ephemeral key as an integer uniformly selected from the interval , using an approved random bit generator to ensure unpredictability and high entropy. The value serves as a per-signature secret nonce and must be kept confidential; it is discarded after use and never reused for another signature. Compute as follows: If , discard and select a new one, repeating the computation to avoid invalid signatures. Then, compute the modular multiplicative inverse of modulo , and use it to derive : If , discard and select a new one, recomputing both and . The resulting signature is the ordered pair , where both components are integers in . The requirement for a fresh per signature is critical, as reusing the same across multiple signatures enables an attacker to recover the private key through algebraic manipulation of the signature equations.Signature Verification
The signature verification process in the Digital Signature Algorithm (DSA) uses the signer's public key to validate the authenticity and integrity of a message without revealing the private key. This procedure ensures that the signature was generated by the holder of the corresponding private key and that the message has not been altered. The verification relies on the mathematical properties of the discrete logarithm problem in a finite field, confirming the signature components through probabilistic computations.[1] To perform verification, the inputs consist of the message , the signature pair , the public key , and the domain parameters , , and , where is a large prime modulus, is a prime divisor of , and is a generator of the subgroup of order modulo . An approved hash function, such as those specified in FIPS 180, is also required to compute the message digest. The verifier first checks that both and are integers in the interval ; if either is outside this range, the signature is rejected as invalid.[1] Next, compute the modular inverse , which exists since is coprime to . Then, derive and , where is the integer representation of the hash output (typically the leftmost bits of the hash, with being the bit length of ). The verification value is then calculated as: If , the signature is valid, confirming the message's origin and integrity; otherwise, it is rejected. This step involves efficient modular exponentiation operations, which are the primary computational bottleneck but can be optimized using algorithms like binary exponentiation for large .[1]Security Analysis
Correctness Proof
The correctness of the Digital Signature Algorithm (DSA) is established by demonstrating that the verification equation holds true for a valid signature, ensuring that the computed value equals the signature component when the message and signature are authentic and unaltered. This proof relies on the mathematical structure of the algorithm, substituting the signing equations into the verification process under the assumption of correct modular arithmetic operations modulo the primes and , where is a large prime, divides , and is a generator of the subgroup of order modulo .[1] Consider a valid signature generated for a message with hash value , private key , and ephemeral secret , where and the inverse exists. The signing equations are and , with and . The public key is . In verification, compute , , , and . Substituting yields and .[1] Now substitute the signing equation for into these: since , it follows that . Thus, and . The exponent in the verification computation becomes . Therefore, , so . This confirms , validating the signature.[1] The proof assumes that all inverses exist (i.e., and , enforced during key generation and signing by regenerating if necessary) and that arithmetic is performed correctly in the multiplicative groups modulo and . For invalid signatures, such as those with , , or altered message hashes, the range checks fail or the substitution does not yield , leading to rejection. This ensures the algorithm's integrity under ideal conditions without computational errors.[1]Vulnerabilities and Sensitivity
The Digital Signature Algorithm (DSA) is theoretically secure under the discrete logarithm problem, but practical implementations are susceptible to several vulnerabilities, particularly those arising from the ephemeral nonce used in signature generation. A critical weakness occurs when the same nonce is reused across multiple signatures for the same private key but different messages. In this scenario, an attacker can recover the private key using the signature equations. Specifically, for two signatures on message hash and on , the relation holds, allowing direct computation of modulo the subgroup order . This attack requires only the public signatures and hashes, compromising the entire key pair.[13][14] If the nonce is not fully random but exhibits predictability, such as through biased generation or partial bit leakage, more advanced attacks become feasible. Linear congruence or lattice-based methods, including solutions to the Hidden Number Problem, can exploit known or guessed bits of from multiple signatures to recover the private key. A notable real-world example is the 2010 Sony PlayStation 3 incident, where a flawed random number generator in the ECDSA implementation (analogous to DSA) produced predictable nonces, enabling hackers to extract Sony's private signing key after analyzing a small number of firmware signatures. Such predictability often stems from insufficient entropy in the RNG, amplifying the risk even without full reuse. Side-channel attacks further expose DSA implementations to physical or remote observation. Timing attacks target variations in modular exponentiation during computation, where execution time leaks information about the Hamming weight or bits of , potentially revealing upper bits of the private key through statistical analysis of multiple signatures. Power analysis attacks, including differential power analysis, monitor energy consumption during nonce generation and inversion, as the modular operations in exhibit data-dependent patterns that correlate with secret values. These vulnerabilities are exacerbated in non-constant-time implementations and have been demonstrated on hardware like smartcards.[15][16] Parameter choices also introduce weaknesses. DSA's security relies on the difficulty of the discrete logarithm in the subgroup of order ; small values, such as the original 160-bit specification, are vulnerable to Pollard's rho algorithm, which solves the problem in approximately operations for 160 bits—now feasible with modern computing resources. NIST has disallowed generation of DSA signatures with 160-bit (providing only 80-bit security) after December 31, 2013, while verification of existing signatures remains allowed for legacy use, recommending transitions to at least 224-bit paired with 2048-bit for 112-bit security (though 112-bit security is planned for deprecation after 2030).[17][18] DSA is particularly sensitive to flaws in random number generation, as the nonce must be uniformly random and unpredictable. The Dual_EC_DRBG, once standardized by NIST, contained a potential backdoor allowing prediction of outputs if certain elliptic curve points were known, which could generate biased or foreseeable values, facilitating key recovery attacks similar to nonce reuse. This concern led to its withdrawal in 2014, underscoring the need for vetted RNGs like those in SP 800-90A. To mitigate these vulnerabilities, deterministic nonce generation per RFC 6979 derives from the private key and message hash using HMAC, ensuring uniqueness without relying on RNGs and preventing reuse or predictability issues. Implementations should employ constant-time arithmetic to resist timing and power analysis, such as Montgomery ladders for exponentiation. Additionally, adopting larger parameters as per NIST guidelines—e.g., 256-bit with 3072-bit for 128-bit security—bolsters resistance to discrete logarithm attacks like Pollard's rho. These strategies maintain DSA's utility while addressing practical risks.[14][18]Applications and Implementations
Software and Library Support
The Digital Signature Algorithm (DSA) is implemented in several widely used cryptographic libraries, providing APIs for key generation, signing, and verification compliant with standards such as FIPS 186-4. OpenSSL includes comprehensive DSA support through functions such asDSA_generate_key for key pair generation, DSA_sign for producing signatures, and DSA_verify for validation, with parameter handling aligned to FIPS 186-4 requirements for finite field cryptography (FFC) generation and validation.[19][20][21]
In the Bouncy Castle Java library, the DSAKeyPairGenerator class facilitates DSA key pair creation and supports initialization with custom parameters, including user-specified prime moduli (p), subgroup order (q), and generator (g), enabling flexible deployment in Java-based applications.[22]
The Crypto++ C++ library provides a full DSA implementation per FIPS 186 up to 3072-bit moduli, featuring classes like DSAPublicKey and DSAPrivateKey with built-in parameter validation via the Validate method to ensure primes meet length constraints (e.g., multiples of 8 bits between 512 and 3072 bits).[23]
Python's cryptography library exposes DSA operations through its hazmat primitives layer, where generate_private_key(key_size) creates a key pair (with supported sizes of 1024, 2048, 3072, or 4096 bits) and the sign(data, algorithm) method on DSAPrivateKey instances produces DER-encoded signatures using hashes like SHA-256.[24]
In the Rust programming language, the RustCrypto project provides the 'dsa' crate, a pure Rust implementation of DSA compliant with FIPS 186-4, supporting key generation, signing, and verification. However, due to DSA's deprecation in FIPS 186-5 for generating new signatures and security concerns with insecure parameter sizes (e.g., 160-bit q providing only 80-bit security), its use is discouraged for new applications; refer to the Security Analysis section for details on vulnerabilities.[25][26]
DSA finds practical use in protocols such as SSH via the ssh-dss key type for authentication, though it is deprecated and disabled by default in OpenSSH 7.0 and later due to security concerns.[27] In legacy TLS implementations (up to version 1.2), DSA signatures appear in cipher suites like TLS_DHE_DSS_WITH_AES_128_CBC_SHA, but TLS 1.3 removes support for DSA entirely.[28] For PGP, GnuPG supports DSA keys primarily for signing messages and subkeys, often paired with ElGamal for encryption, adhering to OpenPGP standards.[29]
Performance-wise, DSA with a 2048-bit prime p requires larger keys than equivalent-strength ECDSA (e.g., over a 224-bit curve), resulting in slower signing and verification.
Standards and Recommendations
The Federal Information Processing Standard (FIPS) 186-5, published by the National Institute of Standards and Technology (NIST) in February 2023, specifies algorithms for digital signatures but removes the Digital Signature Algorithm (DSA) as an approved method for generating new signatures due to limited industry adoption and security analyses indicating better alternatives.[5] Instead, FIPS 186-5 retains DSA solely for verifying existing signatures, while emphasizing migration to more efficient schemes like the Elliptic Curve Digital Signature Algorithm (ECDSA) or Edwards-curve Digital Signature Algorithm (EdDSA); it supports hash functions including SHA-2 and SHA-3 families for compatible algorithms, though DSA verification inherits prior pairings.[30] For legacy DSA implementations, approved parameter sets from FIPS 186-4 (superseded but referenced for verification) define domain parameters based on finite-field cryptography, with specific bit lengths for the modulus (L bits) and subgroup order (N bits) to achieve target security levels. These sets ensure at least 112-bit security for ongoing verification, as smaller parameters like L=1024, N=160 (80-bit security) are legacy-only and discouraged. The table below summarizes the approved (L, N) pairs:| Security Strength (bits) | L (bits of p) | N (bits of q) |
|---|---|---|
| 112 | 2048 | 224 |
| 112 | 2048 | 256 |
| 128 | 3072 | 256 |
