How Digital Signature Algorithm DSA Works: Complete Analysis

Introduction and Core Concepts

The Digital Signature Algorithm (DSA) is a Federal Information Processing Standard for digital signatures, originally proposed by the National Institute of Standards and Technology (NIST) in 1991 and standardized as FIPS 186. Unlike encryption algorithms that focus on confidentiality, the digital signature algorithm dsa is designed to provide authenticity, integrity, and non-repudiation for digital messages and documents. It allows a sender to generate a signature that can be verified by anyone with the sender's public key, proving that the message originated from the holder of the private key and has not been altered in transit.

At its core, DSA is based on the mathematical difficulty of the discrete logarithm problem in a finite field. The security of the scheme relies on the fact that given a large prime modulus p, a prime divisor q of p-1, and a generator g of a subgroup of order q, it is computationally infeasible to determine the private exponent x from the public value y = g^x mod p when the parameters are sufficiently large. This one-way relationship forms the foundation of the public-private key pair. The signer keeps x secret and publishes y, p, q, and g as part of the public key or domain parameters.

Understanding digital signature algorithm dsa matters because it underpins trust in countless systems where tampering must be detectable. While modern systems increasingly use ECDSA and EdDSA for efficiency, DSA remains historically significant and conceptually foundational. It introduced the idea of per-message randomness, modular arithmetic with two primes, and the separation of signing and verification operations that influenced all subsequent ElGamal-based signature schemes. For developers, system architects, and security engineers, understanding DSA clarifies how signatures differ from message authentication codes (MACs), why key management and random number generation are critical, and how standards like FIPS 186-4 govern parameter selection for real-world deployment.

What DSA Guarantees and What It Does Not

DSA provides three core security guarantees. First, authentication ensures the verifier can be confident the signature was created by the entity possessing the private key. Second, integrity ensures any modification to the signed message, even a single bit flip, will cause verification to fail. Third, non-repudiation prevents the signer from later denying they signed the message, assuming the private key has not been compromised. These properties are achieved without encrypting the message itself, so DSA can be used with plaintext that remains readable while still being verifiable.

DSA does not provide confidentiality, it does not hide the message content, and it does not by itself provide protection against replay attacks or guarantee freshness unless combined with timestamps or nonces. It also requires a cryptographically secure hash function, typically SHA-2 or SHA-3, to compress the message to a fixed size before signing. The security of the signature is therefore bounded by both the discrete logarithm strength and the collision resistance of the hash function. If either is broken, signatures can be forged.

Key Participants and Artifacts

A DSA system involves domain parameters (p, q, g), a private key x, a public key y, a message m, its hash H(m), a per-message secret k, and the signature pair (r, s). Domain parameters can be shared across many users or generated per user, though sharing is common in practice for efficiency. The private key is a random integer in the range 1 to q-1, while the public key is derived via modular exponentiation. The signature is not the encrypted hash, but a pair of numbers computed using the hash, private key, and ephemeral secret, which is why DSA signatures are randomized even for the same message.

How It Works

The operation of the digital signature algorithm dsa can be divided into three phases: parameter and key generation, signature generation, and signature verification. Parameter generation creates the global values p, q, and g. p is a large prime, typically 1024 to 3072 bits, q is a smaller prime, typically 160 to 256 bits, that divides p-1, and g is a generator of the subgroup of order q in the multiplicative group modulo p. This is done by choosing h randomly in the range 2 to p-2 and computing g = h^{(p-1)/q} mod p, repeating until g is not equal to 1. The resulting g has the property that g^q mod p = 1 and g^k mod p cycles with period q.

Key generation is straightforward once parameters exist. The signer selects a private key x uniformly at random where 0 < x < q and computes the public key y = g^x mod p. The private key must remain secret and be protected with the same rigor as an encryption key, while y can be distributed via certificates, such as X.509, and authenticated through a public key infrastructure. The security of the entire scheme collapses if x is exposed or if the random number generator used to select x is predictable.

Signature generation is where DSA's unique design appears. To sign a message m, the signer first hashes m with an approved hash function to produce H(m), then reduces it modulo q. Next, the signer generates a fresh, random, secret integer k where 0 < k < q for every single signature. This k must be unpredictable and never reused. The signer computes r = (g^k mod p) mod q and s = k^{-1} * (H(m) + x * r) mod q, where k^{-1} is the modular inverse of k modulo q. If either r or s equals zero, the process restarts with a new k. The output (r, s) is the signature, typically 320 to 512 bits total depending on parameter sizes.

The Mathematics of Verification

Verification reverses the signing equation without requiring knowledge of x or k. The verifier obtains the signer's authentic public key y and domain parameters, hashes the received message to get H(m), and checks that 0 < r < q and 0 < s < q. If not, the signature is immediately rejected. The verifier then computes w = s^{-1} mod q, u1 = H(m) * w mod q, and u2 = r * w mod q. Finally, it computes v = ((g^{u1} * y^{u2}) mod p) mod q. The signature is valid if and only if v equals r. This works because y = g^x, so g^{u1} * y^{u2} = g^{H(m)*w} * g^{x*r*w} = g^{(H(m)+x*r)*w} = g^{k} when w = s^{-1}, and thus v recovers r.

The elegance of this construction is that verification proves knowledge of both x and k without revealing either. An attacker who does not know x cannot produce an s that will satisfy the verification equation for a given r, and an attacker who does not know k cannot derive x from a captured signature without solving the discrete logarithm. The requirement that k be unique per message is absolute. If the same k is used to sign two different messages, an attacker can solve for x directly using simple algebra, which has led to real-world private key compromises in the past.

Role of the Hash Function and Modular Reduction

DSA does not sign the raw message directly because messages are variable length and may be larger than q. Instead, it signs the hash, which provides a fixed-size, collision-resistant fingerprint. FIPS 186-4 specifies that the hash output should be truncated or reduced appropriately: if the hash is longer than q, it is truncated to the leftmost N bits where N is the bit length of q. This ensures the hash fits within the arithmetic modulo q. Using a weak hash like MD5 or SHA-1 with DSA undermines security, as collisions allow an attacker to find two messages with the same hash and thus the same signature.

Implementation

Implementing the digital signature algorithm dsa correctly requires careful attention to big integer arithmetic, secure random number generation, and constant-time operations where possible. Python's built-in pow with three arguments provides efficient modular exponentiation, and the hashlib library offers standard hash functions. In production, you should never implement DSA from scratch for sensitive data; instead, use well-audited libraries such as cryptography, PyCryptodome, or OpenSSL bindings. The following examples are for educational purposes and use small parameters to make the arithmetic transparent.

The first step is domain parameter handling. Real DSA parameter generation involves generating provable primes and verifying subgroup order, which is computationally intensive and requires primality tests like Miller-Rabin. For demonstration, we use small, insecure primes where the relationships are easy to verify. The code below shows the conceptual structure of parameter generation and how g is derived to have order q.

import random
import hashlib

def generate_dsa_parameters_demo():
    # DEMO ONLY: Insecure small primes for clarity
    # Real DSA uses L=2048/3072 and N=224/256 with FIPS 186-4 generation
    p = 787  # large prime modulus
    q = 101  # prime divisor of p-1, q divides p-1
    # Find generator g of subgroup order q
    # Choose h randomly and compute g = h^{(p-1)/q} mod p
    for h in range(2, p):
        g = pow(h, (p - 1) // q, p)
        if g != 1:
            # Verify g^q mod p == 1 (order divides q)
            if pow(g, q, p) == 1:
                return p, q, g
    raise ValueError("No generator found")

p, q, g = generate_dsa_parameters_demo()
print(f"Domain parameters: p={p}, q={q}, g={g}")

Key generation and signing demonstrate the core DSA equations. Note the critical requirements: x must be random in [1, q-1], k must be cryptographically random, never reused, and invertible modulo q, and r and s must be non-zero. The use of pow(k, -1, q) for modular inversion requires Python 3.8 or later; otherwise, use the extended Euclidean algorithm. The hash is reduced modulo q to fit the field.

def dsa_key_generation(p, q, g):
    # Private key x: 0 < x < q, must be uniform and secret
    x = random.randint(1, q - 1)
    # Public key y = g^x mod p
    y = pow(g, x, p)
    return x, y

def dsa_sign(message: str, p, q, g, x):
    # Step 1: Hash message and reduce mod q
    hash_bytes = hashlib.sha256(message.encode('utf-8')).digest()
    hash_int = int.from_bytes(hash_bytes, 'big') % q

    # Step 2: Generate per-message secret k, 0 < k < q
    # WARNING: k must be from a CSPRNG and never reused
    k = random.randint(1, q - 1)

    # Step 3: Compute r = (g^k mod p) mod q
    r = pow(g, k, p) % q
    while r == 0:
        k = random.randint(1, q - 1)
        r = pow(g, k, p) % q

    # Step 4: Compute s = k^{-1} * (H + x*r) mod q
    k_inv = pow(k, -1, q)
    s = (k_inv * (hash_int + x * r)) % q
    while s == 0:
        # Extremely rare, but must retry with new k
        k = random.randint(1, q - 1)
        r = pow(g, k, p) % q
        k_inv = pow(k, -1, q)
        s = (k_inv * (hash_int + x * r)) % q

    return r, s, hash_int, k

# Example usage
x_priv, y_pub = dsa_key_generation(p, q, g)
msg = "Transaction: Alice pays Bob $100"
r, s, h, k_used = dsa_sign(msg, p, q, g, x_priv)
print(f"Private x={x_priv}, Public y={y_pub}")
print(f"Signature (r={r}, s={s}) for hash {h}")

Verification is the counterpart that anyone can perform with public information. It validates the range of r and s, recomputes the hash, and checks the verification equation. A failure at any point means the signature is invalid, which could indicate tampering, a wrong public key, or a corrupted signature. The implementation must handle large integers efficiently and avoid timing side channels when comparing v and r, though Python's integer comparison is generally constant-time for fixed sizes.

def dsa_verify(message: str, r, s, p, q, g, y):
    # Step 1: Validate ranges 0 < r < q and 0 < s < q
    if not (0 < r < q and 0 < s < q):
        return False

    # Step 2: Hash message same way as signer
    hash_bytes = hashlib.sha256(message.encode('utf-8')).digest()
    hash_int = int.from_bytes(hash_bytes, 'big') % q

    # Step 3: Compute w = s^{-1} mod q
    try:
        w = pow(s, -1, q)
    except ValueError:
        return False  # s not invertible, invalid

    u1 = (hash_int * w) % q
    u2 = (r * w) % q

    # Step 4: Compute v = ((g^{u1} * y^{u2}) mod p) mod q
    # Use pow with mod for efficiency: O(log exponent) multiplications
    g_u1 = pow(g, u1, p)
    y_u2 = pow(y, u2, p)
    v = (g_u1 * y_u2 % p) % q

    return v == r

# Verify the previous signature
is_valid = dsa_verify(msg, r, s, p, q, g, y_pub)
print(f"Verification result: {is_valid}")  # Expected True

# Tamper test: should fail
is_valid_tampered = dsa_verify("Transaction: Alice pays Bob $1000", r, s, p, q, g, y_pub)
print(f"Tampered verification: {is_valid_tampered}")  # Expected False

A complete educational walkthrough with tiny numbers makes the arithmetic fully traceable. This example uses p=23 and q=11, which are small enough to compute by hand but preserve the required divisibility property. Never use such small parameters in production; they can be broken by brute force in milliseconds. The example also shows why k must remain secret and why reusing k is catastrophic.

# Complete traceable DSA with tiny insecure parameters
# For learning: every intermediate value is printable

p_small = 23
q_small = 11
g_small = 4   # 4 = 2^{(23-1)/11} mod 23 = 2^2 mod 23
x_small = 7   # private key
y_small = pow(g_small, x_small, p_small)  # 4^7 mod 23 = 8

# Simulated hash value H(m) mod q
H_demo = 5
k_demo = 3    # ephemeral secret, 0 < k < q

# Signing
r_demo = pow(g_small, k_demo, p_small) % q_small  # 4^3 mod 23 = 18, 18 mod 11 = 7
k_inv_demo = pow(k_demo, -1, q_small)             # 3^{-1} mod 11 = 4
s_demo = (k_inv_demo * (H_demo + x_small * r_demo)) % q_small  # 4*(5+49) mod 11 = 7
print(f"Demo signature: r={r_demo}, s={s_demo}")

# Verification
w_demo = pow(s_demo, -1, q_small)          # 7^{-1} mod 11 = 8
u1_demo = (H_demo * w_demo) % q_small      # 5*8 mod 11 = 7
u2_demo = (r_demo * w_demo) % q_small      # 7*8 mod 11 = 1
v_demo = (pow(g_small, u1_demo, p_small) * pow(y_small, u2_demo, p_small) % p_small) % q_small
print(f"Computed v={v_demo}, r={r_demo}, valid={v_demo == r_demo}")

# Demonstrate k reuse attack (why k must never repeat)
# If same k signs H1 and H2 with signatures (r,s1) and (r,s2):
# s1 = k^{-1}(H1 + x*r) and s2 = k^{-1}(H2 + x*r)
# Subtract: s1 - s2 = k^{-1}(H1 - H2) => k = (H1 - H2)/(s1 - s2) mod q
# Then x = (s*k - H)/r mod q is recovered

Step-by-Step Example

To make the digital signature algorithm dsa concrete, we walk through a full example with small numbers that can be verified manually. While real deployments use 2048-bit p and 256-bit q, the arithmetic is identical. We choose domain parameters p=59, q=29, and g=3. Check that q divides p-1: 59-1=58, and 58/29=2, so the condition holds. Verify that g has order q: compute g^q mod p = 3^29 mod 59. Using repeated squaring, 3^29 mod 59 equals 1, confirming g generates a subgroup of order 29.

Next, generate keys. Alice selects private key x=7, which satisfies 0 < x < 29. She computes public key y = g^x mod p = 3^7 mod 59. Compute powers: 3^2=9, 3^4=81 mod 59=22, 3^7=3^4 * 3^2 * 3^1 = 22*9*3=594 mod 59. 59*10=590, remainder 4, so y=4. Alice publishes (p=59, q=29, g=3, y=4) and keeps x=7 secret. Anyone can now verify signatures from Alice using y.

Now Alice signs the message m = "pay 10 coins". First, hash the message. Assume SHA-256 of the message, reduced modulo 29, yields H(m)=12. This step is deterministic; the same message always yields the same hash. Alice then generates a fresh random k=10, where 0 < k < 29. She computes r = (g^k mod p) mod q = (3^10 mod 59) mod 29. Compute 3^10 = 59049. 59049 mod 59: 59*1000=59000, remainder 49, so g^k mod p=49, and 49 mod 29=20, so r=20. Since r is not zero, she proceeds.

Next, compute k^{-1} mod q. Need the inverse of 10 modulo 29. Find integer inv such that 10*inv mod 29=1. Testing, 10*3=30 mod 29=1, so inv=3. Then compute s = k^{-1} * (H(m) + x*r) mod q = 3 * (12 + 7*20) mod 29 = 3 * (12+140) mod 29 = 3*152 mod 29. 152 mod 29: 29*5=145, remainder 7, so 3*7=21 mod 29, thus s=21. The signature is (r=20, s=21). Alice sends m and (20,21) to Bob.

Bob verifies. He first checks 0 < r < 29 and 0 < s < 29, both true. He recomputes H(m)=12 independently by hashing the received message. He computes w = s^{-1} mod q = 21^{-1} mod 29. Find w: 21*? mod 29=1. 21*7=147 mod 29: 29*5=145 remainder 2, not 1. 21*11=231 mod 29: 29*7=203 remainder 28. 21*18=378 mod 29: 29*13=377 remainder 1, so w=18. Then u1 = H(m)*w mod q =12*18=216 mod 29: 29*7=203 remainder 13, so u1=13. u2 = r*w mod q =20*18=360 mod 29: 29*12=348 remainder 12, so u2=12.

Finally, Bob computes v = ((g^{u1} * y^{u2}) mod p) mod q = ((3^13 mod 59 * 4^12 mod 59) mod 59) mod 29. Compute 3^13 mod 59: 3^8=6561 mod 59: 59*111=6549 remainder 12, 3^4=22 as before, 3^1=3, so 12*22*3=792 mod 59: 59*13=767 remainder 25. So g^{u1} mod p=25. Compute 4^12 mod 59: 4^2=16, 4^4=256 mod 59=20, 4^8=400 mod 59=46, so 4^12=4^8*4^4=46*20=920 mod 59: 59*15=885 remainder 35. Then product 25*35=875 mod 59: 59*14=826 remainder 49, and 49 mod 29=20, so v=20. Since v equals r=20, the signature is valid. If Bob changed even one character of the message, H(m) would change, u1 would change, and v would not match r.

Complexity Analysis

The performance of the digital signature algorithm dsa is dominated by modular exponentiation, which is performed using the square-and-multiply algorithm. For an exponent with n bits, this requires O(n) squarings and multiplications, each operating on numbers of size O(L) bits where L is the bit length of p. Using naive multiplication, each multiplication costs O(L^2), but with Karatsuba or FFT-based methods, the cost is lower. In practice, Python and OpenSSL use highly optimized big integer libraries that make these operations fast for standard sizes like 2048-bit p.

Parameter generation is the most expensive operation, but it is performed infrequently. It involves generating large primes and testing primality, which is probabilistic and requires multiple Miller-Rabin rounds. Signing requires one modular exponentiation to compute g^k mod p, one modular inverse, and a few multiplications and additions. Verification requires two modular exponentiations (g^{u1} and y^{u2}) and one modular inverse, making verification roughly twice as expensive as signing. This asymmetry is typical for DSA and influences system design where verification may happen far more often than signing.

Space complexity is modest. Domain parameters and keys require O(L) bits of storage, and intermediate values during signing and verification also fit within O(L) bits. The signature itself is 2*q bits, so for q=256 bits, the signature is 512 bits or 64 bytes. Compared to RSA signatures which are as large as the modulus (256 bytes for 2048-bit RSA), DSA signatures are compact. Memory usage during computation is linear in the size of the numbers, with no large auxiliary structures needed beyond a few big integers.

Best, average, and worst cases for DSA operations are essentially identical in terms of asymptotic complexity because the algorithms always perform the same number of modular exponentiations regardless of input values. There is no early exit that significantly changes the number of steps, except for the rare retries when r or s equals zero, which occur with probability roughly 1/q and are negligible. Therefore, time complexity is deterministic and predictable, which is beneficial for systems requiring consistent latency.

In concrete terms, on a modern CPU, DSA signing with 2048-bit p and 256-bit q takes on the order of 1-2 milliseconds in optimized C, and verification takes 2-4 milliseconds. Python implementations are slower by a factor of 10-50 due to interpreter overhead, but still complete in tens of milliseconds for the same sizes. For the small demo parameters used in educational examples, operations complete in microseconds. The dominant factor remains the exponentiation, so optimizations that reduce exponentiation cost, such as using elliptic curves, yield significant speedups.

Variations and Optimizations

Several important variations and optimizations have evolved from the original DSA. The most significant is the Elliptic Curve Digital Signature Algorithm (ECDSA), which transplants the DSA equations onto an elliptic curve group. Instead of operating modulo a large prime p, ECDSA operates on points of an elliptic curve where the discrete logarithm problem is believed to be harder, allowing much smaller keys for equivalent security. A 256-bit elliptic curve provides roughly the same security as 3072-bit DSA, with faster operations and smaller signatures, which is why ECDSA is widely used in TLS, Bitcoin, and modern PKI.

Deterministic DSA, defined in RFC 6979, addresses the catastrophic failure mode of weak or repeated k values. Instead of generating k randomly for each signature, deterministic DSA derives k deterministically from the private key and the message hash using HMAC. This ensures that the same message and key always produce the same k, but different messages produce unrelated k values, and k never repeats unless the same message is signed twice, which is safe because the signature will be identical. This construction eliminates the need for a strong random number generator at signing time and prevents the Sony PlayStation 3 attack where a faulty RNG reused k and leaked private keys.

Another optimization is precomputation of k and r. Since r depends only on k and domain parameters, not on the message, a signer can precompute many (k, r, k^{-1}) triples offline and consume them quickly when signing. This reduces signing latency to just a hash and two modular multiplications, which is valuable for high-throughput servers or embedded devices. However, precomputed values must be stored securely and never reused, and the storage must be protected as carefully as the private key itself, because knowledge of k directly leads to key recovery.

Batch Verification and Performance Tweaks

When many signatures need to be verified, batch verification techniques can reduce total work. Instead of verifying each signature with two exponentiations, batch methods combine multiple verification equations using random linear combinations, allowing a batch of n signatures to be verified with roughly n+1 exponentiations rather than 2n. This is useful for certificate transparency logs or blockchain nodes that validate thousands of signatures per second. The trade-off is that if the batch fails, individual signatures must be checked to identify the invalid one.

Additional optimizations include using fixed-base exponentiation tables for g, since g is constant for a given domain, and using simultaneous exponentiation algorithms like Shamir's trick to compute g^{u1} * y^{u2} in a single multi-exponentiation rather than two separate exponentiations. Libraries also use Montgomery multiplication and constant-time implementations to avoid side-channel leaks where timing or power analysis could reveal bits of k or x. These low-level improvements are invisible to the API user but critical for secure, high-performance deployments.

DSA2 and Larger Parameter Sets

FIPS 186-4 updated DSA to support larger hash functions and parameter sizes, often called DSA2. Original DSA was limited to 1024-bit p and 160-bit q with SHA-1, which is now considered insecure due to SHA-1 collisions and the 1024-bit discrete logarithm being within reach of well-funded attackers. DSA2 allows L=2048 or 3072 and N=224 or 256, paired with SHA-224, SHA-256, SHA-384, or SHA-512. This aligns DSA security with modern symmetric security levels of 112 and 128 bits. While DSA2 is secure, most new systems prefer ECDSA or EdDSA for better performance at these security levels.

Real-World Applications

The digital signature algorithm dsa has been deployed in numerous real-world systems, particularly where standards compliance and interoperability with government systems were required. In the early 2000s, DSA was the default signature algorithm for many federal systems in the United States, including secure email, document signing, and software distribution for government contractors. Its inclusion in the Digital Signature Standard meant that any system needing FIPS 140 validation had to support DSA, leading to broad adoption in cryptographic libraries and hardware security modules.

In web infrastructure, DSA was historically supported in TLS and SSH. OpenSSH and many TLS libraries implemented DSA host keys and certificates, though they have since been deprecated in favor of RSA and ECDSA due to performance and security concerns with 1024-bit parameters. In databases, DSA signatures are used to sign audit logs and replication streams to ensure that log entries have not been tampered with by an insider or an attacker who gained write access. The compact signature size and fast signing make it suitable for signing each log record without excessive overhead.

In network protocols, DSA has been used in DNSSEC to sign DNS records, in SNMPv3 for authenticating management messages, and in code signing for firmware updates on embedded devices. For example, a router manufacturer might sign firmware images with a DSA private key kept offline, and devices verify the signature before installing the update, preventing malicious firmware from being loaded. Similarly, in financial networks, DSA has been used to sign transaction batches and inter-bank messages where non-repudiation is legally required.

Today, direct use of finite-field DSA is declining, but its elliptic curve descendant ECDSA dominates in cryptocurrencies. Bitcoin, Ethereum, and many other blockchains use ECDSA over the secp256k1 curve to sign transactions. The principles are identical to DSA, but the group operation is elliptic curve point addition. Understanding DSA therefore directly translates to understanding how blockchain signatures work, why transaction malleability was an issue, and why deterministic k generation is critical for wallet security.

Comparison with Alternatives

Choosing a signature algorithm involves trade-offs among security, performance, key size, and ecosystem support. The digital signature algorithm dsa is one of several options, each based on different hard problems. RSA signatures rely on the integer factorization problem, while DSA, ECDSA, and EdDSA rely on discrete logarithms in different groups. Understanding these differences helps architects select the right tool for their threat model and constraints.

RSA is the oldest and most widely supported signature scheme. It can use the same key pair for encryption and signing, which is convenient, but RSA signatures require padding schemes like PSS to be secure, and key sizes are large. DSA was designed specifically for signing and cannot encrypt, but it has smaller signatures than RSA for equivalent security and was free of patent restrictions when introduced, which drove early adoption. ECDSA improves on DSA by using elliptic curves, dramatically reducing key and signature sizes while maintaining security. EdDSA, particularly Ed25519, further improves on ECDSA by using a different curve formulation that allows faster, constant-time implementations and deterministic signatures without requiring a separate RNG.

From a performance perspective, RSA verification is very fast when using a small public exponent like 65537, often faster than DSA verification, but RSA signing is slower due to large private exponent operations. DSA signing is relatively fast, but verification is slower than RSA. ECDSA and EdDSA are fast for both signing and verification at high security levels and are preferred for constrained devices. In terms of security assumptions, all discrete logarithm schemes require strong random number generation for k, while RSA requires strong prime generation and padding. EdDSA's deterministic design removes the RNG requirement at signing time, making it more robust against implementation errors.