Paid service, in pilot
The WORM ledger
An append-only record of what was sealed and when, built so that editing or removing an entry shows up. Tamper-evident. Not secret. Not encrypted.
Said plainly: the ledger is not secret and it is not encrypted. Anyone who has the ledger file can read it. It is tamper-evident, which means changes can be detected. It does not mean changes are impossible, and it is not a vault. Protect the files you seal the way you already protect them.
What WORM means here
WORM stands for write once, read many. In this ledger each record carries the hash of the record before it. Edit or remove a record in the middle and every link after it breaks, which a check will find. New records are added at the end. Nothing is edited in place.
We seal fingerprints of your files and a short label you choose, so the ledger does not need to contain your documents. Choose labels carefully: a label that contains a name is readable by anyone who sees the ledger.
The ledger concept is patent pending (a U.S. provisional application has been filed).
What makes it more than a hash chain
A bare hash chain has a known weakness: someone can cut entries off the end and what remains is still a valid chain. Three things address that.
- A signed tip. The ledger's latest position (record count and last hash) is signed. If the ledger is cut back, the signature no longer matches. The design calls for the signing key to be held in a hardware token, where it cannot be copied out (hardware-key signing). A receipt alone does not show how its key was stored, so for your matter we state in writing which kind of key signed.
- Independent timestamps. We have an outside timestamp authority sign a small file stating the ledger's record count and last hash (RFC 3161). Only that hash leaves the machine. Each token is re-checked offline against the authority's certificate. It shows the ledger had at least that many records, ending in that exact hash, no later than the authority's signed time.
- Evidence reports. A single readable file with an INTACT or PROBLEMS FOUND box, what was checked, a timeline of timestamps, and what the result does not prove. It never says INTACT for a ledger that fails a check. See the sample report, made from made-up data.
What can and cannot be detected
| What happens to the ledger | Detected? |
|---|---|
| An entry in the middle is changed or removed | Yes. The links after it break. |
| Newest entries are cut off the end | Only with a signed tip or a timestamp that covers them. A bare chain cannot show it. |
| The ledger is rolled back to an earlier signed state | A signature alone cannot rule it out. A timestamp over a later tip does. |
| Entries added after the latest timestamp | They have no independent time yet. The report says how many. |
| The newest timestamp records are deleted along with their files | Not from the journal alone. Keep a copy of the journal somewhere else. |
Time, and where it comes from
The time written on each record comes from the machine that wrote it, so treat it as a claim. Only an authority's signed time is independent. By default we use the free public service FreeTSA, which has no uptime or accuracy promise and is fine for low-stakes records. For something you may need to rely on in a dispute, a commercial authority under contract can be used instead.
Bitcoin anchor: in progress. We are adding an additional public anchor on the Bitcoin network. It is not live and we do not rely on it anywhere yet. Timestamps today are RFC 3161.
How you get it, today
During the pilot we run the ledger and the timestamps for you and hand you the receipts and an evidence report. It is not a self-service product, and there is no hosted dashboard. A hosted service that runs scheduled timestamping for customers is not built yet.
After the pilot, the price is a flat fee per matter, agreed in writing before work starts.