One signature, two spellings: (r, s) and (r, n − s) (Cryptography, Week 11)

The lab's bank names a transaction by hashing the signature: txid = sha256(str(r) + str(s)). Replace s with n − s and you hold a second, equally valid signature for the same message and the same key — with a different txid.

Pick a signature

The signature you hold

message withdraw 100 to attacker · curve secp256k1

r — malleability never touches r

s — edit it freely (decimal; 0x… hex is accepted here as a convenience, though the bank's int() wants decimal)

Submit them to the bank

Each button replays the same request against a model of both banks at once, so the divergence is on one screen. Statuses, bodies and the order the checks run in match the lab's apps. The one thing the model stands in for is VK.verify(): a pair counts as verifying here exactly when the real bank would accept it — a signature it issued, or that signature's twin. Invent an s and you get 403 bad signature, because malleability reshapes a signature you already hold; it does not forge one.

Why it works, in one line each

You must already hold one valid signature. This is the precondition, and it is the part most often skipped. Malleability reshapes a signature into a second valid spelling of the same authorization; it never forges one. Nothing on this page — and nothing in the lab — lets you invent an s and spend someone's money. That is why the contrived presets get 403 bad signature from both banks: they are arithmetic, not authorizations.
Both verify. Verification recovers a point and compares only its x-coordinate to r. Swapping s for n − s negates that point: y flips, x does not. There is no check the bank could add to verification that tells the two apart.
The txids differ. The id is a hash of the decimal digits of s, and those digits changed completely. Deduplicating on the signature means deduplicating on a spelling, not on a transaction.
Low-S ends it. n is odd, so exactly one of {s, n − s} is ≤ n // 2. Accept only that one and a (message, key) pair has exactly one acceptable signature — no twin left to file as a second transaction.
The other fix. Dedup on (message, pubkey) instead. It survives malleability the low-S rule does not cover — non-canonical DER, encoding tricks — because it never asks what the signature looked like.

Real here: n, n − s, the low-S test, and every txid — the digests match hashlib.sha256((str(r)+str(s)).encode()).hexdigest() exactly. Modelled here: the bank's control flow, including where VK.verify() sits in it. No elliptic-curve verification runs on this page; the two sample presets were verified with python-ecdsa beforehand, in both forms.

Do not paste these sample numbers into your own container. Both apps run SigningKey.generate(...) at startup, so your instance has a different key and will answer 403 bad signature to a signature made under someone else's. Get your own pair from GET /sign first — these presets are a captured example to look at, not a payload to replay.

n (secp256k1 order)

n // 2 — the low-S ceiling

One signature, two forms: (r, s) and (r, n − s)

Pick a signature

The signature you hold

Form A — (r, s)

Form B — (r, n − s), the twin

Submit them to the bank

Vulnerable bank · port 8102

Fixed bank · port 8103

Why it works, in one line each