A spreadsheet that says "wiped: yes" proves nothing. Anyone with edit access can change "yes" after the fact, or write it before the wipe ever ran. If a compliance reviewer, a client, or an auditor has to take that row on faith, it isn't evidence — it's a claim.
A signed erasure certificate is different: it's built so that any change to it is detectable, and — optionally — so that the party who issued it can be cryptographically tied to it. Here's what those two guarantees actually rest on, and how to check one yourself.
Two separate claims, two separate mechanisms
A trustworthy erasure record has to answer two different questions:
- Has this record been altered since it was issued? (tamper-evidence)
- Who issued it? (attribution)
FileX's certificate format answers the first one always, and the second one only if the person generating it chooses to sign. They're independent layers, and conflating them is the most common way "signed certificate" claims get oversold.
Layer one: the integrity hash (always present, no key required)
Every certificate — from the in-browser Eraser tool or the downloadable FileX Eraser Tool CLI — is a JSON record: an operation ID, a timestamp, the erasure method used, the list of items and their status, and a plain-language disclaimer about what the method does and doesn't guarantee.
To make that record tamper-evident, FileX serializes it with a canonical form — object keys sorted recursively, then compact JSON — and hashes that with SHA-256. The result is stored on the record itself as integritySha256. Anyone can recompute the hash over the same canonical form and compare it to what's stored: if a single byte of the operation details changed after the fact, the hash won't match.
This costs nothing to check — no key, no trust in FileX, no network call. It's the same reason a checksum can prove a download wasn't corrupted; here it proves an erasure record wasn't edited after it was generated. (If checksums are new to you, see how SHA-256 verification works.)
What the hash alone doesn't prove is who generated the record. Anyone can run the eraser and get a validly-hashed certificate — the hash says "unaltered," not "issued by a specific person or organization."
Layer two: the signature (optional, proves who)
For that, FileX offers an optional digital signature using ML-DSA-65, a post-quantum signature algorithm standardized as FIPS 204. When you sign a certificate, FileX signs the certificate's integritySha256 digest with your FileX ID — the same identity used elsewhere in FileX for quantum-safe encryption — and attaches the signature alongside a kid (a short fingerprint of your FileX ID's public keys) and the public key needed to verify it.
Two details matter here:
- The signature covers the hash, which already commits to the entire canonical record — so signing the hash is equivalent to signing the whole certificate.
- The signing context string is domain-separated (
FileX-cert-sig-v1) from FileX's other ML-DSA uses, like signed audit reports or signed FXQ files. A signature made for one purpose can't be replayed as proof for another.
Because signing is tied to your FileX ID's kid, a recipient who already recognizes that fingerprint — say, from a past encrypted exchange — has a second, independent reason to trust the signer, not just the hash.
An unsigned certificate is still fully tamper-evident; it's just not attributable to anyone in particular. Whether you need the signature depends on whether the person receiving the certificate needs to know it was you specifically who ran the wipe, versus just that the record wasn't altered.
Verifying one yourself
You don't need FileX's servers to check a certificate — there aren't any in this flow, and there's nothing to trust but math. The Verify Certificate tool takes a certificate JSON file, recomputes the canonical hash locally, and reports:
- whether the hash matches (tamper-evidence intact or broken)
- if a signature is present, whether it verifies against the embedded public key, and the signer's
kid
Recomputing happens entirely in your browser. Nothing about the certificate you're checking gets uploaded anywhere.
Where the guarantee stops
A signed certificate proves the record wasn't altered, and optionally who signed it. It does not upgrade what the underlying erasure method actually achieved. The certificate's own disclaimer says this plainly: the in-browser Eraser performs a best-effort logical wipe — overwrite, then delete — which is NIST SP 800-88 "Clear." On SSD and flash media, wear-leveling can leave the original data in cells the software overwrite never reached, so this isn't a forensic destruction guarantee. For NIST 800-88 "Purge" — cryptographic erase or a drive's native secure-erase command — you need the downloadable FileX Eraser Tool, which can also produce a certificate in the exact same format.
That "exact same format" detail is deliberate: the browser tool and the desktop CLI hash their certificates identically, byte for byte, so a certificate from either one verifies the same way and neither format needs its own tooling.
The takeaway
A deletion log is a claim. A hashed record is tamper-evident. A signed record is tamper-evident and attributable. Know which one you're holding, and don't assume a "certificate" implies more than its own disclaimer states.
Run an erasure with the in-browser Eraser tool, optionally sign it with your FileX ID, and check the result with the Verify Certificate tool — all locally, nothing uploaded.
Top comments (0)