Skip to main content
Orilami

Contract Date Stamper: before and after

An illustration with sample files; your own files show their own results.

BeforeSigned, but nothing proves when

  • NDA: no proof of date

  • Lease: no proof of date

  • 50 files: no proof of any

AfterProof that each one existed

  • NDA: RFC 3161 timestamp

  • Lease: RFC 3161 timestamp

  • 50 files, one root hash

Contract Date Stamper — Prove When a Contract Existed

Prove that a contract, NDA or agreement existed in a particular form at a particular moment, without showing it to anyone. Documents are hashed in your browser, a batch is committed to one Merkle root, and only that root is bound to a signed timestamp from an RFC 3161 Timestamp Authority. The receipt and certificate can be verified years later, offline, without trusting you or this website.

Almost everything runs locally, and the one network step carries no document. Hashing, the Merkle tree, the receipt, its signature and the verifier run in your browser; offline mode uses no network. A trusted timestamp sends a request of about sixty bytes (the batch’s 32-byte Merkle root and a random nonce) and nothing else: no filename, no identity, no individual document digest. The request exists only because public RFC 3161 authorities allow no direct browser calls.

The chain of custody

  1. Streaming multi-digest: the file is read in chunks in a Web Worker and absorbed by incremental SHA-256, SHA-384 and SHA-512, so memory stays flat even for very large files.
  2. Domain-separated Merkle commitment: leaf = SHA-256(0x00 ‖ digest), node = SHA-256(0x01 ‖ left ‖ right). The distinct prefixes stop an interior node being passed off as a document, and an unpaired node is promoted, not duplicated.
  3. RFC 3161 request: a DER TimeStampReq is built in the browser from the root and a 63-bit nonce, then relayed to the authority.
  4. Verification before trust: the returned token is checked before it enters a receipt. The imprint must equal our root, the nonce must be echoed, the CMS signature must verify, and the certificate must carry id-kp-timeStamping as its only extended key usage and have been valid at genTime.
  5. Signed receipt: a canonical JSON payload (orilami.poe.v1) with every digest, inclusion path, the raw token and the limits of the claim, signed with Ed25519 or ECDSA P-256 via WebCrypto.

Why a Merkle root instead of one stamp per file

Fifty individual stamps would mean fifty requests and fifty fingerprints disclosed. A tree stamps one value, and each contract keeps a short inclusion path proving it belonged to the batch. The path holds only hashes of other branches, so one document can be proven without revealing or naming the others.

What the proof establishes

A proof of existence binds bytes to a time: the exact document you hashed existed no later than the authority's asserted moment, and any later revision is a different document. It does not establish who wrote it, who agreed to it or whether it is enforceable. Revocation status is not fetched and the authority's chain is not anchored to an operating-system root store, because a web page has access to neither; the receipt says so in its own signed text.

Verifying without this tool

The PDF certificate carries the signed receipt JSON and the raw .tsr token as attachments, so the proof survives independently of this site. The token verifies with standard tooling (openssl ts -verify -token_in), and the receipt's signature verifies with any WebCrypto or JOSE implementation after re-canonicalizing the payload (orilami-jcs-v1).

Frequently asked questions

Is my contract uploaded anywhere?
No. The file is streamed and hashed inside your browser. Getting a trusted timestamp sends one thing: the 32-byte Merkle root of your batch plus a random nonce. A hash cannot be turned back into the document, and the authority never sees an individual contract's digest.
Does this tool run locally?
Almost entirely, and the one network step carries no document. Reading, hashing (SHA-256/384/512), the Merkle tree, the receipt, its signature and the verifier all run in your browser; offline mode uses no network. A trusted timestamp sends a request of about sixty bytes, the batch's Merkle root and a nonce, because public RFC 3161 authorities do not allow direct browser calls. No filename or identity is included.
What does a proof of existence actually prove?
A proof of existence shows the exact bytes you hashed existed no later than the moment the authority signed. Change one character afterwards and the digest no longer matches. The proof says nothing about authorship, consent or legal validity.
Why is a timestamp from a Timestamp Authority better than a file date?
File dates and computer clocks are easily changed, and so are screenshots of them. An RFC 3161 authority signs a statement that it saw your digest at a given moment, with a certificate issued for timestamping alone. The signature can be verified from the token itself, without trusting you, us or any ongoing service.
How can someone else check the receipt?
Open the Verify tab and drop in the receipt and the document. The file is re-hashed, the Merkle path is climbed to the root, the root is compared with the signed token's imprint, and the token's signature is checked against its certificate, all offline. The raw token is also attached to the PDF, so OpenSSL can verify it too.
What is the Merkle root for?
The Merkle root commits a whole batch to one 32-byte value, so fifty contracts need one timestamp, not fifty. Each document keeps a short inclusion path that proves it is in the batch and reveals only hashes of other branches, never other documents.
Can I stamp a document without using a timestamp authority at all?
Yes, in offline mode. The receipt then says plainly that it is a fingerprint, not proof of a time, because the only date is your own clock. The digests are identical, so the same documents can be stamped with an authority later.
Does it check whether the authority's certificate was revoked?
No, and the receipt says so. Revocation needs OCSP or CRL lookups and trust anchoring needs the operating system's root store, which a web page cannot reach. Verified offline: the signature, the timestamping key usage, the certificate's validity at the stamped time and that the chain is consistent.
Why can't the browser talk to the Timestamp Authority directly?
Public TSA endpoints send no CORS headers, so a browser blocks the request. A minimal server-side relay forwards the DER request and returns the response unchanged. It is the only network hop, and the token it returns is verified in your browser against the nonce and root generated there.
What stops the authority or the relay returning a token for something else?
The token is verified before it enters a receipt: its message imprint must equal the locally computed Merkle root and its nonce must match the one just generated. A token for other content, or one captured earlier, fails both checks and is discarded with a reason.
Can I prove one contract from a batch without revealing the others?
Yes, that is what the inclusion path is for. It holds the sibling hashes needed to climb from your document's leaf to the root and reveals nothing else about the other documents. Hand over the one document, its path and the receipt.
How large a file can it hash?
There is no fixed ceiling, because nothing is held in memory. The file is streamed and absorbed block by block, so the footprint stays flat whether the input is 4 KB or several gigabytes.
Why implement SHA-2 rather than use the browser's own?
The Web Crypto digest function is one-shot: it needs the entire buffer and has no incremental mode, so large files would have to sit in memory and progress could not be shown. The implementation here is tested against the platform digest for every message length from 0 to 600 bytes and many chunk schedules.
Is the PDF a PDF/A archive?
No. It is a portable PDF with the signed receipt JSON and raw timestamp token attached and a fingerprint QR on the page, not a certified PDF/A-1b file, which needs embedded fonts and ICC/XMP metadata. The certificate never claims PDF/A conformance.
Does verifying cost tokens?
No. Verification is free and offline, even for someone who has never used this site, because a proof nobody else can check would not be worth issuing. Tokens are charged when a receipt or certificate is exported, at 200 per contract covered.
More questions about Orilami

Contract Date Stamper at a glance

Key facts about Contract Date Stamper: where it runs, what it costs, what it accepts and produces, and its limits.
Where it runsEntirely in your browser. Files are never uploaded.
Cost200 tokens per contract (about $2.00 at the base rate); larger batches cost less per contract: 6–10 take 10% off the total, rising to 30% off at 41–50
AcceptsAny file: contracts, NDAs, agreements, scans, archives. Up to 50 per batch, any size
ProducesA signed proof-of-existence receipt as JSON and a PDF certificate, both carrying the RFC 3161 timestamp token, each document's digests and its Merkle inclusion path.
BatchUp to 50 files per run.
Account neededOnly to spend tokens. Browsing and previewing are free.
What it does not doIt proves specific bytes existed at a time. It proves nothing about who wrote them, who agreed to them, or whether the agreement is binding.