Replay Attack

A replay attack is capturing a legitimate, validly-signed message and sending it again later, or to someone else, to trick a system into repeating whatever action that message originally caused. Nothing needs to be forged, and no cryptography needs to be broken: the signature really is valid, because it's a genuine copy of a real message. The attack is entirely about reuse in the wrong context, not forgery.

A simple example makes the mechanics clear: if "transfer $100" is just a signed instruction with no other context attached, capturing that exact message off the network and resending it a second time transfers another $100. The signature checks out both times, because it's the identical, genuinely valid signature both times.

Who formalized it

Roger Needham and Michael Schroeder's 1978 paper on authentication in large networks is the foundational treatment of this class of problem, and it's still cited in modern protocol design. A notable, and genuinely instructive, footnote: the Needham-Schroeder Public-Key protocol, one of the protocols that helped establish the vocabulary for this whole area, was itself later found to have a related flaw. Gavin Lowe discovered it in 1995 using a formal model checker (FDR), not by hand-inspection, years after the protocol had been considered settled. It's one of the field's standard teaching examples for why "we reasoned carefully about this" isn't the same guarantee as "we formally verified this."

The general fix

Bind every message to something that can only be legitimately used once: a random nonce (a number used only once), a timestamp with a tight validity window, a strictly increasing sequence number, or a specific intended recipient baked into what gets signed. A captured, perfectly valid message then fails whenever it's replayed anywhere else, or any later time, because the thing it was bound to has already been consumed or has expired.

Where Solidus addresses it

Solidus's own written threat model (docs/protocol.md §13, see Threat Model) lists replay attacks explicitly among the adversary capabilities it assumes, with a stated mitigation of request IDs, timestamps, and nonces, that's the specified design intent. The concrete piece of running code that implements this idea is documented under Unlinkability: every BBS+ credential presentation folds in a domain-and-nonce challenge, so a presentation captured at one relying party, even a perfectly valid one, fails verification if replayed at a different relying party. Say plainly what this doesn't cover yet: the mechanism is unaudited, an external audit is targeted for H2 2026 via NLnet NGI Zero, and it runs on Solidus's public testnet only. There is no mainnet.

Check it yourself

npm i @solidus-network/auth @solidus-network/bbs, then run the bundled demo/unlinkability-demo.mjs, the same demo referenced under Unlinkability and Correlation Handle. It issues a credential and produces two separate presentations, and the domain-scoped challenge baked into each is visible in the output.