How tScrub signs reports (SHA-256 + Ed25519)

Every tScrub report produces three artefacts: the CSV itself, a manifest (a JSON sidecar describing the job), and — where a signing key is available — a signature. Together they let anyone confirm the report is genuine and unaltered.

How it works

1. tScrub computes a SHA-256 hash of the report CSV.
2. It signs that hash with an Ed25519 key, producing a sidecar .sig file.
3. A manifest records the hash, the public key, and the drive list.

To verify, anyone recomputes the hash and checks it against the signature using the public key. If a single byte of the CSV changed, the hash changes and the signature no longer matches.

Self-signed vs vendor-signed

The difference between tScrub's tiers is which key signs the report:

• Self-signed (free) — the appliance generates an ephemeral key. The report is tamper-evident (any change breaks the signature) but not attributable: the key isn't tied to tScrub, so a third party can't confirm who signed it.
• Vendor-signed (paid) — the report is signed with a vendor-issued key, so it's both tamper-evident and attributable. Certificates from these reports can be independently verified.

Why signing matters for certificates

When tScrub generates a certificate of destruction, it verifies the report's hash and signature first. The certificate is only as trustworthy as the record it certifies — and the signature is what makes the record trustworthy. The verification QR code then ties the certificate back to an independently checkable record.

FAQ

What if the appliance has no signing key?

tScrub degrades gracefully to a checksum-only report — the SHA-256 hash is still recorded, so tampering is still detectable, just without an attributable signature.

Can I verify a report myself?

Yes. The tscrub verify command checks the hash and signature against a public key, and the result is shown as part of the report's integrity state.