How it works

Existence Proof gives you evidence that an exact file existed no later than a certain moment. This page explains how, in plain English, and is candid about the limits.

1. The fingerprint: a hash of your file

A cryptographic hash is a short code calculated from every byte of a file. We use SHA-256, the same function used across banking, software distribution and digital signatures. Its result is 64 characters long, for example:

9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

Three properties make it useful as evidence:

• Same file, same hash. Anyone can recompute it from the file with free, standard tools and get the same result.
• Any change, different hash. Changing a single character, or even re-saving a document in another program, gives a completely different hash.
• No way back. The hash reveals nothing useful about the file's contents, and nobody can construct a different file with the same hash.

Your browser computes the hash on your own device. The file itself is never uploaded. Only the hash is sent when you stamp.

2. From file to stamp

1. Your browser computes the file's SHA-256 hash.
2. The hash is sent to us. We record it, with the current time, as a new numbered entry in our public log, and sign a timestamp token stating "this hash existed at this time".
3. About once a second, we sign a checkpoint: a summary of the entire log, including your entry.
4. Independent organisations then anchor those checkpoints in time, so that the log's history is fixed by parties other than us.
5. You download an evidence package that contains everything needed to check the stamp later, without our help.

3. What a stamp proves, and what it does not

In practice: keep the original file unchanged, together with its evidence package. If you need to prove authorship, combine the stamp with other evidence (drafts, correspondence, witnesses). Stamping early drafts as you go builds a stronger record than a single stamp at the end.

4. The public log

Every stamp we issue is added to a public, numbered, append-only log. The log is built as a Merkle tree, the same structure used by Certificate Transparency, which protects the certificates behind HTTPS on the web.

The log's contents are summarised by a single root hash, computed from every entry. We sign that summary as a checkpoint. Because the root hash depends on every entry, changing, removing or reordering any past entry would change it. Anyone holding an old checkpoint could then show that the log was rewritten.

Your evidence package includes an inclusion proof: a short list of hashes showing that your entry is part of the tree summarised by a checkpoint. It can be checked in seconds, without downloading the whole log. The full log is also free to download and mirror from /tile/, in the standard C2SP tlog-tiles layout.

5. Independent anchors

A log signed only by us could, in principle, be quietly rebuilt by us. Anchors prevent that by tying our checkpoints to the outside world:

• DigiCert and FreeTSA are independent RFC 3161 timestamping authorities. Every 10 to 60 minutes (when the log has grown) we ask both of them to timestamp our latest checkpoint. Their signed tokens prove that the checkpoint, and therefore every entry in it, existed no later than their time.
• drand is a public randomness beacon run by the League of Entropy, a group of independent universities and companies. It publishes a new unpredictable random value every few seconds. We write the latest value into each checkpoint, which proves the checkpoint was created no earlier than the moment that value was published, because nobody could have known it beforehand.

Together they bracket each checkpoint in time from both sides, using parties that do not answer to us.

6. The clock and its accuracy

The time in a stamp comes from the Cloudflare edge server that handles the request. Cloudflare synchronises these clocks over NTP to its own time service, which is in turn based on GPS-disciplined reference clocks.

Each stamp states its accuracy (for example ± 1 second) inside the signed token. The figure is deliberately conservative: the server only reads its clock at certain points while handling a request. The clock source is also written into the token.

We continuously cross-check the clock against independent sources (other servers' clocks, drand round times, and the times in DigiCert's and FreeTSA's tokens) and publish the results at /v1/clock.

7. Why backdating would be detected, even by us

Suppose someone at Existence Proof wanted to issue a stamp today but date it last month. To be believed, that stamp would have to appear in the public log. But:

• Entries are numbered in the order they are added, and the number is inside the signed token. A stamp issued today gets today's number, which sits after entries from last month.
• Checkpoints from last month were already timestamped by DigiCert and FreeTSA. Their root hashes do not include today's entry. Placing the fake entry among last month's numbers would change those roots, and the mismatch with the independent anchors would be visible to anyone.
• If the fake stamp is simply not added to the log at all, it fails verification, because it has no valid inclusion proof.

In short: a backdated stamp is either missing from the log, or sits at a position in the log that contradicts its claimed time. Neither can be hidden from someone who checks. This is why the stamp holds up even if you do not trust the operator.

We cannot prevent our signing key from being misused if it were stolen. The public log and anchors are what make such misuse detectable. Witness cosigning by independent parties is planned as a further safeguard.

8. Standards and compatibility

• Tokens are standard RFC 3161 timestamp tokens (CMS SignedData, ECDSA P-256 with SHA-256), the format used throughout the industry for signed documents and code.
• They can be checked with OpenSSL (openssl ts -verify) and other RFC 3161 tools. The verification guide gives exact commands.
• Software that can use an RFC 3161 timestamping server (for example document-signing and code-signing tools) can use https://existence-proof.com/tsa directly.
• The log follows the RFC 6962 / RFC 9162 Merkle tree design and C2SP formats for checkpoints and tiles.
• Each log entry is the signed timestamp data itself (the token's TSTInfo), so the log alone is enough to reconstruct what was stamped and when.

9. Keys and certificates

Tokens are signed by a timestamping certificate that is issued by the Existence Proof Root CA. The root's private key is kept offline. Our current and past certificates, and the public key that signs log checkpoints, are published at /.well-known/existence-proof-keys.

So that you don't have to take this website's word for which root certificate is genuine, its fingerprint is also published in several independent places: in the DNS record _root-cert.existence-proof.com, in our source code repository, in an Internet Archive snapshot, and in entry #0 of the log. The root certificate itself was timestamped by DigiCert and FreeTSA when it was created. The verification guide shows how to compare them.

10. Privacy

• Your file never leaves your device when you use this website. The page computes its hash locally.
• The hash you stamp, its time and its token are public, by design. A hash does not reveal the file's contents, but anyone who already has an identical copy of the file can compute the same hash and find your stamp.
• For very short or guessable content (for example a single word or a phone number), a hash can be guessed by trying candidates. Stamp the document, not a short secret.
• This website uses no cookies, no analytics, and no third-party scripts or fonts.

Stamp a file Verification guide