What are the common security and correctness pitfalls when using the Java Signature API, and how do you avoid them?

## Why pitfalls matter The `Signature` API is easy to call but easy to *misuse* in ways that silently destroy its guarantees — the code still runs, but it no longer proves authenticity or integrity. Here is the practical checklist. ### 1. Always check the verify() boolean `verify()` returns `true`/`false`; it does **not** throw on a bad-but-well-formed signature. The classic bug: ```java verifier.verify(sig); // result ignored — every signature is 'accepted' ``` You must branch and **reject on false**: ```java if (!verifier.verify(sig)) throw new SecurityException("bad signature"); ``` ### 2. Verify with a *trusted* public key A signature only means something relative to a key you trust. If the attacker supplies both the data, the signature, **and** the public key, they can sign anything with their own key and it will verify. You must: - **pin** the expected public key, or - validate a **certificate chain** to a trusted CA and then use `cert.getPublicKey()`. ### 3. Byte-for-byte agreement (canonicalization) Signatures cover exact bytes. Spurious `verify()==false` almost always traces to: charset mismatch (UTF-8 vs platform default), non-deterministic serialization (JSON field order/whitespace), line-ending differences, or feeding the wrong slice of a buffer. **Sign the exact serialized bytes you transmit**, and if you must sign a structured object, define a single canonical form both sides use. ### 4. Avoid weak algorithms - Hashes: no **MD5**, no **SHA-1** (collision-broken). Use SHA-256/384/512. - RSA: no **1024-bit** (and PKCS#1 v1.5 is legacy). Prefer **RSA-3072** or **RSA-PSS**. - Prefer **ECDSA P-256+** or **Ed25519** for new systems. - ECDSA needs a unique random *k* per signature; the JCA provider handles this, but never roll your own — a repeated/biased *k* leaks the private key. ### 5. Protect the private key Leaking the private key = anyone can forge. Never log it, never commit it, never put it in plain config. Store it in a **`KeyStore`** (PKCS12) with a passphrase, or in an **HSM/KMS** where signing happens inside the boundary and the raw key never leaves. ### 6. Thread-safety A `Signature` instance is **stateful** (it holds init state and accumulated data) and is **not thread-safe**. Sharing one instance across concurrent requests interleaves their data and corrupts results. Use a fresh instance per operation, a pool, or a `ThreadLocal<Signature>`. ### 7. Don't confuse with HMAC / encryption - A **digital signature** uses asymmetric keys and provides **non-repudiation** (only the private-key holder could have produced it). - An **HMAC** uses a **shared secret**; both parties can produce and verify, so it gives integrity/authenticity *between trusting parties* but **not** non-repudiation. - A signature is **not** confidentiality — the data isn't hidden. Encrypt separately if you need secrecy. ### 8. Signature-wrapping / structure attacks In formats like XML-DSig/JWS, attackers exploit mismatches between *what was signed* and *what the app processes* (e.g., signing one element but reading another). Defenses: process only the signed bytes, reject anything outside the signed region, and never let the message itself dictate the algorithm (the JWS `alg:none` attack — pin the expected algorithm rather than reading it from the token). ### 9. Handle the checked exceptions meaningfully `NoSuchAlgorithmException`, `InvalidKeyException`, `SignatureException` are checked. Don't swallow them into a `return true`; a thrown exception during verification must be treated as **verification failure**, not success. ## Mental model The API gives you the math; *you* supply the trust decisions: check the boolean, trust the right key, agree on the bytes, pick strong algorithms, guard the private key, and don't share the stateful object.