Signature verification checks whether data matches a signature produced with the appropriate secret. A recipient detects modification because an attacker without the signing secret cannot produce a valid signature. With asymmetric signatures, signing uses a private key while verification uses the corresponding public key, so verifiers cannot forge signatures themselves. section 1.2.2 section 9.1
The verification role differs by construction:
- Symmetric signing and MACs let parties holding the shared secret reconstruct or check the authenticated result, but every verifier can also create messages. section 1.2.2 section 9.1
- ECDSA verification computes P = (h(m)G + rA) / s and accepts the signature (r, s) when P_x equals r. section 9.5.1
- Verification can be correct while signing is catastrophically unsafe: reusing an ECDSA nonce produces valid signatures with the same r value, and weak PKCS#1 v1.5 parsing enables forgery. section 9.5.1 section 9.6.2
Validating vulnerable ECDSA signatures
A Go test signs an empty message, “Hello World!”, a pangram, and a timestamp using a fixed nonce, then verifies each signature with ecdsa.Verify. Every signature verifies, but repeated r values expose the nonce-reuse failure. Go’s standard signing API mixes a supplied RNG with a CSPRNG, so this attack fails against that implementation. section 9.5.1
Equation 9.7
\[\begin{aligned} \begin{aligned} (P_x, P_y) &= \frac{h(m)G + rA}{s} \end{aligned} \label{equation:ecdsa-4} \end{aligned}\]Use the verification equation to trace how the message hash, signature values, and public key reconstruct the point checked against r. section 9.5.1
