Signature Forgery

A digital signature is created by signing a message hash with a private key. Forgery attacks aim to either:

• Recreate a valid signature without the private key.
• Trick a user or system into signing a malicious message.
• Exploit flaws in the signature algorithm or its implementation. The security relies on the computational infeasibility of reversing the cryptographic functions.

A critical vulnerability in the Elliptic Curve Digital Signature Algorithm (ECDSA) used by Bitcoin and Ethereum. If the same random number (nonce, k) is used to sign two different messages, an attacker can mathematically derive the signer's private key.

• Famous Example: The 2010 Bitcoin Android wallet bug reused nonces, leading to stolen funds.
• Mitigation: Use RFC 6979 for deterministic, nonce derivation.

An attack where the signature in a transaction is altered without changing its validity or intent, creating a different transaction ID (txid). This can be exploited to:

• Double-spend by invalidating the original transaction's confirmation.
• Disrupt payment tracking in systems relying on unconfirmed txids.
• Bitcoin fixed this with Segregated Witness (SegWit), which separates signature data from the transaction identifier.

An attack where a valid signature is intercepted and reused (replayed) in a different context to execute an unauthorized action. Common in:

• Cross-chain bridges: A signature proving assets are locked on Chain A is replayed to mint assets again on Chain B.
• Smart contracts: A signature for a one-time authorization is reused.
• Prevention: Use nonces, chain IDs, and deadlines in signed messages to ensure context uniqueness.

A social/technical engineering attack where a user is tricked into signing a message that grants unintended permissions. This exploits the opaque nature of signed data.

• Examples: Signing a seemingly harmless "verification" message that is actually a token approval for all funds, or a delegate call to a malicious contract.
• Defense: Wallet UX improvements that clearly decode and display the implications of a signature request.

Attacks targeting weaknesses in the signature scheme itself or its software implementation.

• Fault Injection: Using physical means (voltage, clock glitches) to cause a device to produce an erroneous, exploitable signature.
• Lattice Attacks: On poorly chosen parameters for post-quantum schemes.
• Side-Channel Attacks: Extracting private key bits by analyzing power consumption, timing, or electromagnetic leaks during the signing process.

In December 2021, BadgerDAO users suffered losses when the protocol's frontend was compromised. The attacker injected malicious code that prompted users to grant infinite token approvals via a malicious signature request. This was a social engineering attack that tricked users into signing a valid but malicious transaction, effectively forging their consent. The incident underscores that signature security depends not just on cryptography, but also on the integrity of the user interface and the clarity of what is being signed.

Some early Ethereum contracts were vulnerable to signature malleability attacks due to improper handling of v, r, s values. An attacker could alter a valid signature's s value to its complementary value (s' = secp256k1_n - s), creating a different but still valid signature for the same message. If a contract only checked for signature uniqueness based on the raw (v, r, s) tuple and not the recovered address, funds could be drained. The EIP-155 replay protection and standardized libraries like OpenZeppelin's ECDSA.recover now mitigate this.

The EIP-2612 permit function allows token approvals via off-chain signatures, improving UX. However, it introduces a new attack surface: signature replay across chains and phishing for signatures. A user might sign a permit for a small amount on a testnet, but the same signature could be replayed on mainnet if chain ID is not properly included in the signed message. Phishing sites can also trick users into signing a permit that grants access to all their tokens, a common vector in wallet-draining attacks.

To prevent signature forgery exploits, developers must implement robust verification:

• Use audited libraries like OpenZeppelin's ECDSA.
• Always include chain ID and contract address in signed messages (EIP-712 for structured data).
• Implement deadlines for signed messages to prevent replay.
• For multisigs and governance, use timelocks and require a quorum of signers.
• Frontends must clearly display human-readable details of what is being signed to prevent social engineering.

This attack allows an attacker to alter the cryptographic signature of a transaction without changing its validity or intent, creating a different transaction ID (txid). This can disrupt tracking in systems relying on unconfirmed txids. Bitcoin fixed this with Segregated Witness (SegWit), which separates the signature from the transaction data used for the txid hash. Ethereum's use of (v, r, s) signature tuples is inherently non-malleable.

An attacker re-uses a valid signature from a legitimate transaction in a new, unauthorized context. Common vectors include:

• Cross-chain replay: Using a signature from one fork (e.g., Ethereum) on another (e.g., Ethereum Classic).
• Cross-contract replay: Replaying a signature meant for one smart contract on a different, similar contract. Mitigations include incorporating chain IDs, nonces, and contract-specific addresses into the signed message hash.

Future quantum computers using Shor's algorithm could theoretically break the elliptic curve cryptography (ECC) underlying today's signatures, allowing forgery. This is a long-term threat requiring proactive migration. Mitigation paths include:

• Hash-based signatures (e.g., Lamport, SPHINCS+).
• Lattice-based cryptography (e.g., Dilithium).
• Multi-signature schemes to increase the attack complexity. The transition to post-quantum cryptography (PQC) is a major focus for blockchain protocol upgrades.

Most forgery stems from flawed implementation, not the cryptography itself. Critical practices include:

• Secure random number generation for nonces, avoiding predictable PRNGs.
• Using audited libraries (e.g., libsecp256k1) instead of custom implementations.
• Implementing strict signature verification, checking the s value is in the lower half of the curve order to prevent malleability.
• User education on verifying EIP-712 message details before signing.

A replay attack occurs when a valid, previously signed transaction is maliciously or fraudulently repeated. While the signature itself is not forged, the context of its use is. Defenses include:

• Nonces: Sequence numbers that make each signature unique.
• Chain IDs: Network identifiers (e.g., in EIP-155) that bind a signature to a specific blockchain.
• Timestamp windows: Limiting the validity period of a signed message.

Signature malleability is a property where a valid signature can be non-destructively altered into another valid signature for the same message and key, without knowing the private key. This is a flaw in some signature schemes (like early Bitcoin's ECDSA) that could allow an attacker to change a transaction's ID, potentially disrupting blockchain tracking. Modern implementations use strict DER encoding or schemes like Schnorr signatures which are non-malleable.