A trusted timestamp is one of the few things in this field that is genuinely cheap. A third party signs a statement that a particular fingerprint was presented to it at a particular moment, without receiving your document, without being able to read it, and without charging you. The exchange takes about a minute.

The protocol is not the hard part. Custody is. The proof arrives as a small separate file, and a year later that file is the thing people cannot find. This post covers what a timestamping authority is, when reaching for one pays, which endpoints answer, where the proof goes missing, and the routes that need no command line.

A companion post covers who else can hold the record and for how long , and another covers how the dates on a document get changed .

What a Timestamping Authority Is

A timestamping authority is a third party whose entire job is to sign one statement: that it saw a particular fingerprint at a particular moment. It does not receive your document, cannot read it, and takes no position on whether anything in it is true.

The public ones are there largely to serve code signing. DigiCert publishes its own timestamp server for exactly that [1 ], because software has a problem documents do not. A signature made with a certificate that later expires has to stay distinguishable from one applied after the expiry, and a trusted timestamp is how that distinction is kept. Documents ride on infrastructure built for something else, which explains a caution further down.

Start with the hash: a fixed-length fingerprint computed from a file’s exact bytes, where any change produces a different fingerprint. There is a fuller treatment in digital hashing for lawyers .

When You Would Actually Reach for One

An agreement you will need to stand behind years from now. The contract, the lease, the settlement, the board resolution. Almost none will ever be questioned, which is the argument for covering all of them rather than guessing which.

Work whose priority date matters. A design, a manuscript, a source tree, a research notebook, a proposal you sent to a prospect. Anything where “I had this before they did” is a claim you might one day make.

Evidence you gather yourself, before anyone asks for it. Photographs of a condition, screen captures, records you export from a system somebody else runs. The date is worth anchoring precisely because you produced it and you hold it.

Anything you may need to show was in force, or show you handed over. Handbooks, retention schedules, published terms, safety procedures, and any document where what matters later is what you sent rather than what they say they received.

This is the option with the fewest dependencies, which is a different claim from being the best proof.

What the Token Contains, and What It Proves

RFC 3161 defines a request and response protocol between a client and a Time Stamping Authority [2 ]. You send a hash. You do not send the document, and the authority has no way to examine what the hash represents. For privileged material that property is the whole point, because what leaves your machine is a fingerprint rather than the document. Satisfy yourself that a given service actually works that way before you rely on it.

The token that comes back always carries a version, a policy identifier, the fingerprint you submitted and the algorithm used, a serial number, and a generation time in UTC, all covered by the authority’s signature. The authority’s name may appear as an optional field, which the RFC treats as a hint rather than identification. The binding identification is the signing certificate.

What it proves: that a hash matching this exact file was submitted to and signed by that authority no later than the stated time, and that the token has not been altered since. What it does not prove: who authored or possessed the document, that its contents are true, or that anyone did anything on that date.

RFC 5816 updated the signer-certificate identifier used alongside these tokens, and nothing else [3 ].

Which Service, and What It Costs

Several public endpoints answer without an account, and the distinction that matters is what each one publishes and what it commits to.

FreeTSA operates a general-purpose endpoint and publishes its certificate chain [4 ]. Read what it does and does not commit to before you depend on it, and price that answer against what it costs, which is nothing.

DigiCert and Sectigo both run standard servers that are free to query, and both answered ordinary requests in September 2026, which is an observation rather than a promise to anyone. The caution is not technical. Whatever either of them runs the service for, it is not a commitment to you. Read the current terms of use yourself before relying on one for documents, and do not read today’s open access as a promise.

Where People Lose the Proof

After the minute is over, the work is small and boring. Most of it is filing. The last of it is a habit, and that is the part good filing cannot cover.

Do not lose the token. It is a separate file. Lose it and you are holding a document with nothing attached to it. Store it beside the document and back it up with the document.

Do not re-save the document. The timestamp covers the exact bytes you hashed and nothing else, so opening the file and saving it breaks the proof even when nothing you can see has changed. Tested on a 763-byte agreement for this post: writing a single metadata field grew it to 4,048 bytes, and a plain rewrite produced 1,313. Both then failed verification with message imprint mismatch, while the untouched original still verified. “It only added a title” and “the bytes are unchanged” are different statements. Acrobat was not used here; both were reproduced with exiftool and qpdf on Linux.

Keep the authority’s certificate chain. Download it at the moment you take the timestamp and store it with the token. Verification needs a trust source named explicitly, and the chain as published at the time is the one that will match.

Take a fresh timestamp before the old one stops being checkable. The act is the same exchange described earlier: hash the document and the old token together, send that, and keep the new token as a third file. Nothing about the document changes. You do not need a precise deadline to get this right, and that is what a one-minute, no-cost operation buys you: re-stamping early costs nothing at all. What it does need is an occasion, because an undated obligation never gets performed at any price. Two that work: re-stamp whenever you next open the document for some other reason, which is free and needs no reminder, and set one repeating calendar entry five years out for the documents you may never open again. Five years is an arbitrary number chosen to be safe rather than exact, and the repetition is what makes it survive. The outer limit is the expiry of the certificate that signed your token, and for the three services here those expiries fall between June 2037 and February 2040. The reason not to wait for that limit is that a second clock has no date on it at all: a hash algorithm can be retired while every certificate involved is still valid. ETSI’s PAdES standards formalize a version of this inside the PDF itself [5 ], which is a different operation from the detached token described here.

What you keep, and what you ask for

The package handed to an examiner or to counsel in year seven is four items, not one:

  • The exact file, unmodified since it was hashed
  • The timestamp response file
  • The authority’s certificate chain as published at the time
  • A short written note of what was done, with what tool, on what date

Read the list backward and it becomes a request. When a document arrives from somebody else with a timestamp attached, those four items are what to ask for, and the one most often missing is the chain as it stood when the token was made.

A Route With No Command Line

OpenTimestamps needs no command line. Neither does the page described at the end of this post, and the two are worth telling apart, because what they establish is not the same thing. The project’s own page offers in-browser stamping and states that the hash is calculated in your browser [6 ], which would preserve the property that makes hash-only submission workable for sensitive material. The same page also describes a document being uploaded. Those two statements do not plainly agree, and anyone handling privileged material should satisfy themselves on that point rather than take this paragraph’s word or the page’s. Behavior observed September 2026.

What the route buys is worth being exact about. OpenTimestamps aggregates many users’ hashes into a tree and writes only the root into a Bitcoin transaction, so it is free and needs no account. What it establishes is strictly an upper bound: the hash existed no later than the anchoring block, and the proof is not usable until the calendar server completes the path. Confirmation runs in hours rather than minutes. That is a different product from the signed token described earlier, not a cheaper version of it.

The Minute Is Not the Hard Part

A timestamp is a minute of work and no money, and the cryptography behind it has been stable for two decades. What it asks of you afterward is small and boring and almost never done: keep four files together, do not re-save the document, and come back before the old token stops being checkable.

Nothing above proves who wrote a document, who held it, or whether a word of it is true. It proves that these exact bytes existed by a stated time, a narrow thing that happens to be the thing most often in dispute. Take the minute on the documents you would hate to be asked about, then treat the token as part of the document rather than as a receipt.

If You Want to Try It

As a convenience, Lucid Truth Technologies® publishes a web page that carries out this exchange for you, at timestamp.lucidtruthtechnologies.com . There is no account and nothing to install.

You choose a file and it does the rest. The fingerprint is calculated inside your browser, so the document itself is never uploaded. That one fingerprint goes to several independent authorities at once, and what comes back is a single ZIP file holding your document, each authority’s signed token, their full certificate chains, and a plain-English record of what was done, including the exact commands anyone can run to check every claim in it. Those are the signed tokens described throughout this post, not the Bitcoin anchoring described above.

That is the four items listed earlier, packaged together in one archive with the note already written, which is the part people actually lose.

The source is public on GitHub . It is not a validated forensic instrument, which the page and every archive it produces both say on their face.

For the command-line version of all of this, a companion post goes considerably further into the technical detail: it opens the request and all three responses field by field, counts what the certificate chains cost in bytes, and works through the verification failure that makes a perfectly good token look broken. It is One Hash, Three Timestamp Authorities .

References

Endpoint availability, token contents and vendor behavior described here were measured on 2026-09-16, on OpenSSL 3.0.13, and verified in September 2026.

[1] DigiCert, Inc., “RFC 3161 compliant Time Stamp Authority server,” DigiCert Knowledge Base. [Online]. Available: https://knowledge.digicert.com/general-information/rfc3161-compliant-time-stamp-authority-server

[2] Internet Engineering Task Force, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP),” RFC 3161. [Online]. Available: https://www.rfc-editor.org/rfc/rfc3161

[3] Internet Engineering Task Force, “ESSCertIDv2 Update for RFC 3161,” RFC 5816. [Online]. Available: https://www.rfc-editor.org/rfc/rfc5816

[4] FreeTSA, “FreeTSA,” freetsa.org. [Online]. Available: https://freetsa.org/index_en.php

[5] European Telecommunications Standards Institute, “Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures,” ETSI EN 319 142-1. [Online]. Available: https://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf

[6] OpenTimestamps, “OpenTimestamps: a timestamping proof standard,” opentimestamps.org. [Online]. Available: https://opentimestamps.org/