The use cases are concrete. A researcher wants to prove priority on an invention without publishing it yet. A journalist needs to show that a leaked document was in their possession before a takedown order. A software vendor wants verifiable proof that a release binary existed at build time, so a later compromise cannot be passed off as the original. In each case the question is the same: can you prove this exact data existed at or before time T, in a way a skeptical third party will accept?
The Hash Is the Whole Trick
The foundation is a cryptographic hash. You compute the hash of your file, a short fixed-length fingerprint, and that is what gets timestamped. The contents never leave your hands. Because a good hash is collision-resistant, nobody can construct a different file that produces the same fingerprint, so a timestamp on the hash is as good as a timestamp on the file. And because the hash reveals nothing about the data, you can get a public, verifiable timestamp on a secret document without disclosing a single byte of it.
A timestamp says "this fingerprint existed at this time." Since no one can find a second file with the same fingerprint, that is equivalent to "this exact file existed at this time." The timestamp authority learns only a meaningless-looking hash, never your content.
The RFC 3161 Model: A Trusted Authority Signs
The most widely deployed scheme is RFC 3161, the Time-Stamp Protocol. It uses a Time-Stamping Authority, a TSA, which is a server that holds a signing key and a trusted clock. The flow is simple:
- You hash your file and send the hash to the TSA as a timestamp request.
- The TSA appends its current time to your hash, signs the combination with its private key, and returns a signed timestamp token.
- Anyone can later verify the token against the TSA's certificate, confirming the hash existed at the stated time.
This is the model behind code-signing timestamps, which solve a real practical problem: when a software signing certificate expires, signatures made while it was valid should stay valid. An RFC 3161 timestamp proves the signature was made during the certificate's lifetime, so the software does not silently become untrusted the day the certificate lapses.
The weakness is structural. You are trusting the TSA. If its signing key is stolen, an attacker can forge timestamps for any date the certificate covers. If the TSA colludes or is compelled, it can issue a false time. RFC 3161 moves the trust problem rather than eliminating it, in the same way a certificate authority concentrates trust in a single signer. For many purposes that is acceptable. For adversarial ones it is worth wanting better.
Linking Schemes: Removing the Single Point of Trust
The older and more robust idea, predating RFC 3161, is linked timestamping. Instead of relying on one authority's signature, you chain timestamps together so that each one depends on all the ones before it. The classic construction, from Haber and Stornetta in 1991, hashes each new request together with the previous token, forming a chain where altering any single entry breaks everything after it.
Modern versions batch many requests into a Merkle tree. All requests in a time window become leaves; the tree is folded down to a single root hash; and only that root needs to be anchored somewhere public and hard to alter. To verify your timestamp, you present the short path from your hash up to the published root. This is the same tamper-evident structure that powers Certificate Transparency logs, and the appeal is that the security no longer rests on one key staying secret. It rests on the published root being widely witnessed.
A signed timestamp is only as honest as the authority's key. A linked timestamp is as honest as the historical record everyone already saw, which is much harder to rewrite.
Comparing the Approaches
| Scheme | Trust anchor | Main risk |
|---|---|---|
| RFC 3161 TSA | Authority's signing key and clock | Key theft or compulsion forges timestamps |
| Linked / Merkle | A widely published root hash | Needs a credible public anchor and witnesses |
| Blockchain anchoring | An append-only public ledger | Ties existence to a chain's continued security |
Blockchain-anchored timestamping, used by tools like OpenTimestamps, takes the linked idea to its conclusion: it publishes the Merkle root into a public ledger whose history is expensive to rewrite. The proof becomes "this hash was committed in a block mined at this time," and verifying it requires no trust in any company, only the assumption that the ledger's history holds. The trade-off is the dependency on that ledger's long-term survival and security.
What Timestamping Is Not
Two honest limits are worth stating. First, a timestamp proves existence-before, not authorship. It says the data existed by time T, not who made it or that any claim in it is true. Pair it with a digital signature when you need both who and when. Second, timestamping is about time and integrity, not secrecy. It does not encrypt anything. If your file is sensitive, the privacy comes from the fact that only its hash is ever submitted, never the file itself.
Trusted timestamping is one of those primitives that is invisible until you need it, then suddenly load-bearing: protecting evidence integrity, anchoring software supply chains, proving prior art, and underpinning long-term archival signatures. It pairs naturally with the broader integrity toolkit, alongside reproducible builds and transparency logs, all of which share one goal: making the historical record something you can verify rather than something you have to take on faith.