Technology

How PublicEvidence works behind the scenes

Fingerprint, timestamp, proof package: the technology behind PublicEvidence – explained clearly, with data flow, limits and ways to verify independently.

Updated: 29 October 2026

This page describes the technical concept. Features that are not live yet are marked as “Planned” or “Draft”.

IDEA

One fingerprint. One timestamp. One proof that belongs to you.

Every digital file can be converted into a short code – its fingerprint. Change just one character and a completely different code appears.

We have public systems record this fingerprint in time. Later, that proves this exact file existed at a certain point at the latest. The file itself stays with you.

The proof is saved as a proof package and belongs to you. It can be verified with open tools, even without PublicEvidence.

Only the fingerprint travels

Your file, its name and your password never leave your device.

The proof stays with you

The proof package can be verified independently and is not tied to an account.

Standards instead of a walled garden

OpenTimestamps, SHA-256 and open formats remain usable without us.

PROCESS

From click to verifiable proof package

Choose a file

You select a document on your device. It is not uploaded.

Calculate fingerprint

Your browser calculates a SHA-256 fingerprint locally.

Request timestamp

Only the fingerprint goes to public timestamping services. They anchor it in the Bitcoin blockchain.

Save proof package

You download the package, keep it with your file and can verify it at any time.

Lifecycle of a proof

Stage	What happens
Created	Fingerprint calculated and proof file generated.
Submitted	One or more calendar servers have accepted the fingerprint.
Anchored	The fingerprint is part of a Bitcoin transaction included in a block.
Verified	The entire chain has been checked independently.

It usually takes a few hours between “Submitted” and “Anchored”, because many fingerprints are written to Bitcoin together.

For nerds: MVP sequence

Browser                        PublicEvidence backend         Calendar server        Bitcoin
  | 1. read file locally             |                              |                    |
  | 2. SHA-256(file) = h             |                              |                    |
  | 3. request proof (h) ----------->| 4. forward h --------------->|                    |
  |                                  |<-- 5. pending proof ---------|                    |
  |<-- 6. proof (.ots, pending) -----|                              | 7. collect, Merkle-|
  | 7. download proof package        |                              |    tree, tx ------>| block
  |                     ... hours ...                                |                    |
  | 8. request upgrade ------------->| 9. fetch upgrade ----------->|                    |
  |<-- 10. complete proof -----------|<-----------------------------|                    |
  | 11. verify against block header (locally or via node/explorer)

BUILDING BLOCKS

The building blocks behind the scenes

Every building block has a clear job. Anything not implemented yet is marked explicitly.

Digital fingerprint

Available

A SHA-256 hash identifies the file uniquely. The file cannot be reconstructed from it.

Technical details

Hash function SHA-256 (FIPS 180-4), 32 bytes, hexadecimal representation.
Calculated in the browser in a Web Worker; large files are hashed in chunks.
File name, date and size are not part of the fingerprint – only the bytes.
Multiple files are combined in a canonical manifest (RFC 8785).

Timestamp via OpenTimestamps

Available

Calendar servers combine many fingerprints in a Merkle tree and anchor the root in a Bitcoin transaction.

Technical details

Open protocol OpenTimestamps with an open-source reference client.
A pending commitment comes first; after Bitcoin confirmation, an upgrade completes the proof.
Several independent calendar servers are queried in parallel.
Statement: the file existed at the time of the block at the latest. Bitcoin block times are not precise UTC timestamps.

Qualified timestamp

Planned

An approved European trust service provider confirms the time with a qualified timestamp.

Technical details

Standard RFC 3161; response as a signed token (.tsr/.tst).
Legal framework eIDAS (Regulation (EU) No 910/2014), Art. 41/42.
Only the fingerprint is transmitted, never the file.
PublicEvidence itself is not a qualified trust service provider.

Proof package

Available

A folder with manifest, timestamp, verification instructions and – if booked – the qualified token. Your file is not included.

Technical details

Open or documented formats so verification remains possible without PublicEvidence.
Contains README, manifest.json, checksums, blockchain proof and verification instructions.
Missing parts are marked in a machine-readable way.
No keys or passwords in the package.

Commit & Reveal

Draft

You can record something without revealing its content and publish it later. A secret random value prevents short content from being guessed.

Technical details

commitment = SHA-256("PE-commit-v1" ‖ salt ‖ fileHash).
The commitment is timestamped, not the file hash.
The salt is not part of the public package and must be kept like a password.

Encryption

Planned

Documents are encrypted on your device before they are stored. Only you know the key.

Technical details

AES-256-GCM via the Web Crypto API, no custom cryptography.
Password derivation with Argon2id (WASM), fallback PBKDF2-HMAC-SHA-256.
Chunked encryption with authenticated metadata in the file header.
No recovery by the operator. Losing the password means losing the data.

Copies in several places

Planned

Proofs and encrypted documents can be stored redundantly. If one location fails, the others remain.

Technical details

Addressing via the SHA-256 of the ciphertext (content addressing).
By default only the proof is distributed, not the document.
Every copy is checked again when retrieved.
Distributed content is technically very hard to recall or delete.

DATA FLOW

What leaves your device?

In the MVP, only the fingerprint leaves your device. Not the file, not its name, not your password.

Data	Stays local	To PublicEvidence	To timestamp services
Your file	✓	–	–
File name, size, date	✓	–	–
Fingerprint / commitment	✓	✓	✓
Proof package	✓	–	–
Salt, password, key	✓	–	–
IP address and request time	–	✓	✓

In the MVP, PublicEvidence only accepts fixed-length hex strings and does not store files. Calendar servers and operators see the request IP address for technical reasons.

For nerds

The backend is a relay to the calendar servers and stores pending proofs for a limited time.
Fingerprints are strictly validated (^[0-9a-f]{64}$).
No third-party scripts, fonts or analytics in the frontend.
Logs do not contain fingerprints together with IP addresses longer than necessary.

TRUST

Whom do you have to trust?

The goal is to need as little trust in us as possible. Where trust is still required, it is listed here.

You trust …	… for	How it is limited
Mathematics (SHA-256, AES-256-GCM)	Fingerprint, encryption	Standardised, extensively reviewed methods
Bitcoin network	Time boundary and immutability of the entry	Decentralised; block headers can be verified independently
Calendar servers	Commitment until anchoring	Several independent servers; complete only after anchoring
Qualified provider (planned)	Official time statement	Approval in the EU Trusted List; token and certificates in the package
Your browser and device	Correct local calculation	Your own responsibility; verification with independent tools possible
PublicEvidence (web frontend)	Delivery of the program code	CSP, SRI, reproducible builds, offline client later

The honest point: program code from the web

With a website, the server delivers the code that hashes or encrypts your file. A compromised server could deliver malicious code. This can be reduced, but not completely ruled out.

Web app

You trust the code currently being delivered.

Open-source client

Code and build are publicly verifiable; published checksums allow comparison.

Signed offline client (planned)

Independent of web-delivered code, recommended for especially confidential documents.

VERIFY WITHOUT US

Verify it yourself – without PublicEvidence

You need neither us nor an account. Anyone can verify a proof with freely available software.

Have the file and proof package ready.
Calculate the file fingerprint and compare it with manifest.json.
Verify the blockchain proof after anchoring.
Optionally verify the qualified timestamp (planned).

Commands (examples)

1) Calculate fingerprint

sha256sum contract.pdf
# macOS: shasum -a 256 contract.pdf
# Windows PowerShell:
Get-FileHash -Algorithm SHA256 contract.pdf

2) Upgrade proof

ots upgrade blockchain/proof.ots

3) Show and verify proof

ots info blockchain/proof.ots
ots verify blockchain/proof.ots

Verification results

Result	Meaning
Passed	Fingerprint matches, proof is valid, time is stated.
Pending	Not yet anchored in a Bitcoin block – upgrade later.
File differs	The file is no longer the timestamped version.
Not verifiable	Data is missing or infrastructure is unreachable.
Invalid	Proof is damaged or does not match the package.

The concrete commands will be tested before launch with real sample proofs on Linux, macOS and Windows. Instructions are included in the proof package.

SECURITY

Security and privacy

We build on proven standards, store as little as possible and openly state what we cannot do.

Manipulated web code

CSP, Subresource Integrity, reproducible builds, signed releases and a planned offline client reduce the risk.

Malicious files

File contents are not processed on the server. Only hashing happens in the browser.

Backend input

Strict validation, size limits and parameterised database queries.

Abuse and load

Rate limits, limited concurrency and optional protection measures when anomalies occur.

Calendar server outage

Several independent servers, retries and a visible status indicator.

Supply chain

Few, pinned dependencies and automated checks before every release.

Privacy in practice

Data minimisation: no accounts in the MVP, no tracking cookies, no third-party integrations.
Logs contain only what is technically necessary and are kept briefly.
The blockchain contains only cryptographic values, no files or names.
EU hosting; data processing agreements and retention periods are documented before launch.

LIMITS

What a proof can do – and what it cannot

A proof is strong, but not omnipotent. These limits are part of being honest.

Topic	What applies
What is proven	A specific file existed at a certain point at the latest and has been unchanged since.
What is not proven	Truth of the content, authorship, ownership, identity, location or recording date.
Time accuracy	Blockchain: upper time boundary, no precise clock time. Qualified timestamp: signed time statement by the issuer.
Waiting time	The complete blockchain proof is usually available after a few hours.
Legal effect	Technical proof. A special legal presumption applies only to qualified timestamps.
No certification	No replacement for a notary, authority, electronic signature or legal advice.
Scans	A proof shows the existence of the scan, not the authenticity of the document.
Long term	Proofs can be verified with open tools. Active long-term evidence preservation is not part of the MVP.
Cryptographic ageing	Algorithms can become weaker. Proofs name their method; guaranteed renewal is not provided.
Irreversible	Anchored proofs and distributed copies cannot be recalled.
Role of PublicEvidence	Software platform for proofs – not a qualified trust service provider and not an archive service in the legal sense.

Whether and how a proof can be used in proceedings is decided by the competent court in each individual case.

STANDARDS

Open standards and sources

PublicEvidence relies on documented, independently verifiable methods.

Topic	Standard / project
Hash function	SHA-256, FIPS 180-4 (NIST)
Canonical JSON	RFC 8785 (JSON Canonicalization Scheme)
Timestamp (blockchain)	OpenTimestamps (open protocol and open-source client)
Qualified timestamp	RFC 3161, eIDAS (EU) No 910/2014, EU Trusted Lists
Encryption	AES-GCM (NIST SP 800-38D), Web Crypto API, Argon2 (RFC 9106)
Randomness	crypto.getRandomValues() (Web Crypto)
Website security	OWASP ASVS, Content Security Policy, Subresource Integrity
Long-term proofs	ETSI standards for evidence records and archive timestamps, RFC 4998

The goal is to publish the client and verification tool. Licence and release date are still open.

DEVELOPMENT

Technology roadmap

The order follows risk and benefit: the verifiable base proof first, then convenience and additional protection layers.

Base

First

Local fingerprint, OpenTimestamps proof, proof package download, upgrade and verification without an account.

Verification

First

Browser verification page, offline instructions and test cases with manipulated files.

Secret proof

Commit & Reveal with salt.

Qualified timestamp

After approval

RFC 3161 connection to an external QTSP, token and validation data in the package.

Encryption

After review

Client-side encryption, open format and offline decryption.

Copies

After review

Distributed storage of proofs, later of encrypted documents.

Offline client

Later

Signed desktop and CLI application.

Own aggregator

As needed

Own calendar infrastructure at high volume.

The roadmap describes the planned order, not committed dates.

TECHNICAL FAQ

Questions from nerds

Why Bitcoin and not our own blockchain?

Our own chain would only be as trustworthy as its operator. Bitcoin is public, decentralised and widely observed. PublicEvidence deliberately does not operate its own blockchain.

Can PublicEvidence read my data?

In the MVP we only receive the fingerprint. With planned encrypted storage, we should not be able to read plaintext either. Because web code is delivered by a server, this promise is subject to the limitations described in the Trust section.

What if the calendar servers fail?

The proof is requested from several servers. Already anchored proofs can be verified independently of calendar servers. Only upgrading a pending proof needs a server.

Why not simply a signature?

A signature proves who signed something, not when it existed at the latest. Timestamps prove existence at a point in time. Both can be combined.

What happens if SHA-256 is broken one day?

Proofs name their algorithm. For older proofs, renewal through additional timestamps with stronger methods is planned while the old proof is still considered valid. There is no guarantee.

Is the code open?

The goal is an open client and an open verification tool with a public format specification. Licence and timing are still open.

Why not use an official timestamp service for everything right away?

The qualified timestamp costs money and ties you to a provider. The blockchain variant is free and independent. Both complement each other; the qualified timestamp is intended for cases where legal evidentiary value matters.

Technology understood? Then secure your first proof.

Start for free, no account required. Your file stays on your device.

Create proof →Back to home