Proof of Existence Before Sharing Confidential Files

Proof of Existence Before Sharing Confidential Files: What It Does and Doesn't Cover

Before you send a confidential file to someone, you can create a timestamped record showing that a file with that exact content existed at or before a certain moment, without handing the file to anyone. You do it by generating a cryptographic hash of the file on your own device and recording that hash on a blockchain. The record contains a fingerprint, not the document. If a dispute ever comes up about what you had and when, you can show the original file, and anyone can check that it produces the same fingerprint.

That is useful. It is also narrower than people tend to assume, so this guide covers both sides.

Why people do this before sharing?

The moment you send a file, you lose some control over the story. An investor passes on your deck, then a similar product appears. A client receives your concept designs and "goes in another direction." A partner reads your draft specification and later describes the idea as theirs.

In most of these situations, nobody can prove much, because everything lives in email threads and file metadata, and both are easy to dispute. File metadata is editable. Email timestamps depend on servers you don't control. A neutral, independently checkable date attached to the exact file you sent gives you something firmer to point to.

It doesn't stop anyone from misusing your material. It just means that if the question "what did you have, and when?" comes up, you aren't relying on your own word alone.

How it works, in plain terms

A hash function takes a file of any size and produces a short, fixed-length string. SHA-256, the function Certelo uses, produces a 64-character hexadecimal result. Two properties matter here:

* The same file always produces the same hash.

* Change even a single byte and the hash comes out completely different.

It also works one way. You can't reconstruct the file from its hash.

With Certelo, the hash is calculated locally, on your device, so the original file doesn't need to be uploaded just to create the proof. That hash is then anchored to the Electra Protocol blockchain. The resulting record gives you a verifiable indication that this particular fingerprint existed at or before the recorded blockchain time.

Later, anyone you give the original file to can calculate its hash and compare it with the recorded one. If they match, the file is identical to the one that was fingerprinted. If they don't, it isn't.

A sensible order of operations

The sequence matters more than people expect.

1- Finalize the file you intend to send. Not a draft, not "roughly this."

2- Create the proof for that exact file.

3- Keep that exact file safe. You'll need it for verification.

4- Send it, ideally under an NDA or other written confidentiality terms.

The reason for step one is that hashing is byte-exact. If you timestamp a Word file and then send a PDF export of it, the PDF has a different hash, and the record says nothing directly about the PDF. Even re-saving a document in the same program can alter its bytes. Decide what you're actually sending, and hash that.

Is it safe to record a hash of a confidential file?

Mostly yes, with one caveat worth understanding.

Because SHA-256 can't be reversed, the hash doesn't reveal your document's contents. For a typical file, such as a 40-page deck or a design package, nobody can work backwards from the hash to the content.

The caveat is guessable files. If the file is short and predictable, say a one-line statement, a standard form with a few blanks, or a number from a small range, someone could try candidate inputs, hash each one, and look for a match. This is a dictionary-style guess, and it only works when the possible contents are limited.

If your file falls into that category, you can fix it by including something unpredictable in the file itself, such as a long random string in a cover page or a small extra file inside a zip archive. That makes guessing impractical. For ordinary, substantial documents this isn't something to worry about.

Practical situations

Pitching to investors

Timestamp the deck you're about to send. If you later need to show what the deck contained in a given week, you have a reference point that doesn't depend on email metadata.

Sending design or creative work to a client

Fingerprint the concept files before delivery. If the client rejects the work and a similar design appears later, you can show your files existed first. That supports your account of events; it doesn't settle who owns the rights.

Sharing research data or a draft paper

Recording a fingerprint before sending a draft to reviewers or collaborators gives you a dated record of that version.

Sending different versions to different people

If you give each recipient a slightly different copy, each copy has its own hash. Recording all of them lets you later show which version went to whom. It won't prove a leak happened, but it can help narrow questions about which version surfaced.

What it doesn't do

This is the part people get wrong, so it's worth being direct.

It doesn't prove you wrote or own the file. The record shows that a fingerprint existed by a certain time. If someone else created the file and you timestamped it, the record looks identical. Authorship and ownership need other evidence: drafts, working files, correspondence, contracts, registrations.

It doesn't keep your file confidential. Once the recipient has the file, nothing about the timestamp limits what they do with it. That's the job of an NDA and your choice of who to trust.

It doesn't replace an NDA. The two do different things. An NDA creates legal obligations about how the information is used. A timestamp creates a dated record of what existed. They work well together, but neither substitutes for the other.

It doesn't establish legal outcomes. Whether a record is accepted as evidence, and how much weight it carries, depends on the jurisdiction and the case. Under the EU's eIDAS Regulation, for instance, electronic timestamps can't be denied legal effect solely because they aren't qualified, but only qualified electronic timestamps benefit from a legal presumption of accuracy of date and time. Unless a service tells you it is a qualified trust service, don't assume its timestamps carry that presumption. For anything high stakes, ask a lawyer in the relevant jurisdiction.

It doesn't survive changes to the file. If the original is altered, lost, or can't be reproduced exactly, the record can't be matched to it.

How trade secrets and prior art fit in?

Two areas come up often enough to mention briefly.

If you're protecting something as a trade secret, many legal systems expect you to take reasonable steps to keep it secret. A timestamp isn't one of those steps. Confidentiality agreements and access controls are. The timestamp is supporting evidence about what existed when.

For inventions, a dated record can help document that certain information existed on a certain date, which may be relevant to prior-art arguments. It doesn't give you patent rights and doesn't substitute for a patent application. Rules vary a lot by country, so get proper advice before disclosing an invention.

How Certelo handles this?

The workflow follows the steps above. You select your file, the SHA-256 hash is generated locally in the browser, and only that hash is anchored on the Electra Protocol blockchain. The original stays on your device. Afterwards, the certificate information, the hash, or the original file can be used to verify the record.

Two practical habits help. Store the original file and its certificate together, and name them so you can tell which version went to which recipient. If you use cloud storage, treat the original like any other sensitive document, because Certelo's record can only be matched against a file you still have.

How to verify later?

If you ever need to demonstrate the record, you take the original file, recalculate its SHA-256 hash, and compare it with the hash anchored on the blockchain. If they match, the file is byte-for-byte identical to the one fingerprinted at the recorded time. Because the blockchain record is public, a third party can check it without having to trust you or Certelo's say-so. You'd only share the original file with whoever you choose to.

Some more clarifications.

Can I timestamp a file without uploading it?

With Certelo, yes. The SHA-256 hash is calculated on your device and the original file isn't uploaded just to create the proof.

Does the hash reveal what's in my document?

No, not for a normal document. A SHA-256 hash can't be reversed. The exception is very short or highly predictable content, which could be guessed by trying candidates. Adding random data to the file avoids that.

Do I still need an NDA?

Yes, if confidentiality matters. A timestamp records what existed and when. It doesn't restrict how the recipient uses the file.

Does a timestamp prove I created the document?

No. It shows a fingerprint existed by a certain time, not who made the file. Pair it with drafts, working files, and correspondence.

What if I edit the file after timestamping it?

The edited file will have a different hash and won't match the earlier record. Keep the original, and timestamp new versions separately.

Is a blockchain timestamp accepted in court?

That depends on the jurisdiction and the case, and it's not something a timestamp can guarantee. Treat it as supporting evidence and take legal advice for specific disputes.

Should I timestamp before or after sending?

Before. A record made after sending shows less, since the file had already left your control.

Closing

Timestamping before you share is a low-effort way to put a verifiable date on exactly what you sent. It works best as one layer next to confidentiality agreements, good record-keeping, and clear contracts. If you want to try it, you can create a proof for your file on Certelo and keep the original and certificate together for later verification.