A service that signs evidence about your data has an obvious temptation: put the data into the evidence. It would make search easier, support easier and a richer dashboard possible. We decided early that Trustvice receipts would not do it: a receipt carries the hash of what it describes, not the content.
This post explains why, and where the design stops protecting you without your help.
Evidence that has to travel#
A receipt is only useful if you can give it to someone: an auditor, a counterparty, a mediator. Anything inside it is readable by whoever you hand it to. If receipts carried content, every receipt you shared would leak something, and you would have to think about redaction each time.
A SHA-256 hash avoids that. It is 64 hexadecimal characters that identify the exact bytes of your content without revealing them. The receipt then says, in effect: at this time, these bytes were presented under this label. You keep the bytes. When it matters, you produce them, anyone hashes them, and the hash either matches the receipt or it does not.
Where hashing is not enough#
We would be misleading you if we stopped there. Hashes protect content well under one condition, and a few fields of a receipt are not hashes at all.
A hash hides content only as well as the content is unpredictable#
SHA-256 cannot be reversed, but it can be guessed. If the input has few possibilities, such as a yes or no answer, an email address, a short code or a known template, anyone holding the receipt can hash the candidates and compare. For content like that, include a random value, a nonce, in what you hash, and keep the nonce with the original. The receipt then proves existence without letting a reader guess.
Some fields are written in clear text#
Labels and other free-text fields you choose are written in clear text, and once signed into a receipt they stay there. Use opaque identifiers, such as an order number or an internal id, and keep the lookup table on your side.
Hash the exact bytes#
A hash identifies bytes, not meaning. A trailing newline, \r\n instead of \n, or a different Unicode normalisation is a different hash. For text, decide the encoding and line endings once and keep to them. For structured records, store the exact bytes you hashed, not a re-serialisation: a later JSON.stringify with a different key order has a different hash. For several files, hash a manifest that lists each file's own hash, and attest the manifest.
Keep your originals#
Plan for one consequence: a receipt cannot reproduce the content. If you lose the original, the receipt still verifies, but it no longer proves anything useful about a document you can show. Store originals write-once, beside their receipts.
Deletion and the nature of evidence#
There is a limit no design can remove. A receipt you already handed to someone else remains verifiable by them whatever we do, because verification needs only the receipt and a public key. That is the property that makes it evidence. It is also why the advice above matters: keep personal data out of the clear-text fields, and the question of erasing a receipt rarely becomes difficult. Erasing the original in your own store is usually enough, because the receipt keeps only its hash.
In short#
We sign facts about your data, not the data. Hashing first means receipts can travel, and means verification never requires trusting our storage. It does not make a guessable value private, and it does not protect what you write in clear-text fields. Use nonces for small inputs, opaque ids for labels, and keep your originals.
Read more in What a receipt proves, and what it does not and on our security page.
Live demo