# signature malleability allows replay by computing complementary ECDSA signatures without the private key The secp256k1 elliptic curve has a symmetry property: for any valid signature `(r, s, v)`, there exists a complementary signature `(r, -s mod n, flipped_v)` that is also valid for the same message. An attacker who observes a valid signature can compute this complement without knowing the private key. If the contract uses the raw signature (rather than the message hash) as a uniqueness check, the complementary signature passes verification as a "new" signature, enabling replay. OpenZeppelin's ECDSA library enforces that `s` is in the lower half of the curve order, eliminating malleability. Since [[signature replay attacks succeed when contracts verify signatures without tracking processed message hashes]], malleability is one mechanism (but not the only one) that enables replay. The [[ecrecover returns address zero on invalid signatures which matches uninitialized address variables creating false authorization|ecrecover address(0) bug]] is a separate but related failure mode where invalid signatures bypass authorization entirely. **EIP-2098 compact signatures** introduce an additional bypass vector. Compact signatures use an alternative 64-byte encoding where the recovery bit `v` is packed into the high bit of `s`. Malleability checks designed only for the standard 65-byte signature format may not handle the compact encoding — a contract that rejects `(r, high_s, v)` in standard format may accept the equivalent compact signature `(r, packed_s)` that encodes the same high-s value differently. Libraries must explicitly validate both formats or reject compact signatures entirely. **Best-practice checklist for signature verification:** 1. Use OpenZeppelin's ECDSA library (enforces lower-s, validates v in {27, 28}, rejects zero-length signatures) 2. Never use raw signatures as uniqueness identifiers — track message hashes instead 3. Explicitly check that `ecrecover` returns a non-zero address 4. If accepting EIP-2098 compact signatures, ensure the library validates both standard and compact forms consistently 5. Include chain ID, contract address, and nonce in signed data to prevent cross-chain and cross-contract replay --- Relevant Notes: - [[signature replay attacks succeed when contracts verify signatures without tracking processed message hashes]] — the broader replay problem - [[access control vulnerabilities are the leading cause of smart contract financial losses]] — the category this falls under - [[ecrecover returns address zero on invalid signatures which matches uninitialized address variables creating false authorization]] — another signature verification failure mode - [[ECDSA nonce reuse directly reveals the private key because two signatures sharing the same r value expose k algebraically]] — extends this: nonce reuse enables key recovery, a more severe outcome than malleability-based replay Topics: - [[vulnerability-patterns]]