What Is Cryptographic Timestamping?

Cryptographic timestamping is the practice of producing evidence that a specific piece of data existed at a specific time, in a form nobody can forge or backdate. It rests on two ideas: a hash function that fingerprints the data, and a trust anchor that fixes the time.

Understanding which anchor you are relying on is the whole subject.

The hash half

Every scheme starts the same way. Run the data through a cryptographic hash function — SHA-256 is the usual choice — and you get a fixed-length fingerprint, 64 hexadecimal characters, unique to those exact bytes.

Three properties make this work:

• Deterministic. The same input always gives the same hash, on any machine.
• One-way. You cannot recover the data from the hash, so publishing the hash discloses nothing.
• Collision-resistant. Nobody can construct a different document with the same hash.

So the hash stands in for the document: publish the hash and you have committed to the document without revealing it. You can compute one yourself with our SHA-256 generator.

The time half, and the trust question

Fixing the time is where approaches diverge, and where you have to ask who you are trusting.

Timestamp authorities (RFC 3161)

The traditional answer, standardised in RFC 3161. You send your hash to a Timestamp Authority; it appends its own clock reading, signs the combination with its private key, and returns a signed token.

• You trust: the TSA's honesty, its clock, and its key hygiene.
• Verification needs: the TSA's certificate chain to still be valid and resolvable.
• Failure modes: the TSA colludes or is compromised and issues a backdated token; or it shuts down and its chain becomes hard to validate years later.
• Strengths: fast, standardised, embedded directly in PDFs and code signatures, and recognised in regulation such as eIDAS.

Blockchain anchoring

Instead of a signature from a named party, the hash is written into a public blockchain transaction. The block's position in the chain fixes the time, and the chain is maintained by a network with no single operator.

• You trust: that a public, widely-replicated chain cannot be rewritten.
• Verification needs: a block explorer, or your own node. No certificate chain.
• Failure modes: essentially reorganisation of a mature chain, which for Bitcoin or Ethereum is not a practical concern at any depth.
• Weaknesses: the timestamp is only as precise as block times, and each write costs a transaction fee.

Linked timestamping

The oldest idea in the field, from Haber and Stornetta's 1991 paper — the work Bitcoin's whitepaper cites. Each timestamp incorporates the previous one, forming a chain where altering any entry breaks every entry after it. Modern services combine this with Merkle trees so thousands of hashes share a single anchor, which is how OpenTimestamps can be free.

Comparing the anchors

What any of them actually proves

All of them prove the same narrow thing, and it is worth stating precisely: this data existed no later than this time, and has not changed since.

They do not prove:

• Who created it. A timestamp names no author. See proof of existence vs proof of authorship.
• That the content is true. You can timestamp a lie; the record shows only that you had it.
• How much earlier it existed. The bound is one-directional.

That sounds limited until you notice how often the disputed fact is exactly the bounded one: which version, and by when.

Choosing

Use an RFC 3161 TSA when you need a signature inside a document, or when a regulation names the standard — qualified electronic signatures, long-term archival formats, code signing.

Use blockchain anchoring when the record must outlive any company, when you want a third party to verify without special tooling, or when you would rather not depend on an authority's continued good behaviour.

Use both for anything genuinely valuable. They fail in unrelated ways, which is precisely why belt and braces works.