BASALT · JOURNAL
What a certificate of redaction is, and what makes one worth having
If you are asked six months from now to show that a produced document was properly redacted, "we used a redaction tool" is not an answer. You need something that ties a specific file to a specific set of operations, that a third party can check without trusting you, and that fails visibly if the file changed.
That is what a certificate of redaction should be. Most things sold under that name are receipts: a page that says the redaction was done, signed by nobody, provable by no one. This post covers the difference and how to evaluate one.
The problem a certificate is solving
Redaction disputes are about the past. Someone alleges that a production was over redacted, under redacted, or altered after the fact. The document in front of the court is a copy that has been emailed, re-saved, uploaded to a review platform, and possibly re-exported.
Three questions follow. Is this file the same one that was produced. What operations were performed on it. Who says so, and can that be checked independently. A certificate that does not let a stranger answer all three is decorative.
The key property is that verification must not depend on the tool that produced the file. If checking the certificate requires installing the same application, you have not produced evidence, you have produced a claim in a proprietary format. Anyone who does not have the application, which includes most opposing counsel and every court clerk, cannot evaluate it.
What has to be in it
A certificate that is actually useful contains four things.
The identity of the file. Not the file name, which is trivially changed and frequently changed in the ordinary course of production. A cryptographic hash of the exact bytes. SHA-256 is the sensible default: widely implemented, present on every operating system, and fast enough on any document size you will encounter. The hash is what pins the certificate to the file. Change one byte anywhere and the hash changes completely.
The file name should be recorded too, because humans navigate by names, but it is documentation, not identity.
What was done. At minimum, the number of redaction marks applied. Better, the page each mark was on and the region it covered. This is what makes a certificate answer the over redaction question as well as the under redaction question. A count of eleven marks across four pages is a factual statement someone can check against the visible document.
Be careful about what a certificate reveals. A certificate that lists the removed text defeats the purpose of the redaction. The certificate should describe the operation, not its input.
The checks that passed. A signature over "we drew some boxes" is worth very little. What gives the certificate weight is an enumeration of the properties that were verified on the written output: no text remains within the marked regions, no image pixels remain under the marks, XMP and document information metadata were stripped, embedded attachments were removed, hidden optional content groups were removed, stale thumbnails were removed, no annotations carry residual values, the file was written as a single generation with no incremental update chain.
Each of those is a testable assertion about the output file. Listing them tells a reader exactly what was and was not checked, which is more honest and more useful than a generic pass.
A signature. A cryptographic signature over the whole certificate, using a scheme a third party can verify with standard tools. Ed25519 is a good choice: small keys, small signatures, no parameter choices to get wrong, and supported by OpenSSL and every mainstream crypto library.
The signature is what makes the certificate resistant to editing. Without it, a certificate is a text file anyone can retype with different numbers.
Verification without the tool
The test of a certificate is whether someone hostile to your position can check it using software they already have.
The two step version looks like this. First, hash the file you were given and compare it to the hash in the certificate:
shasum -a 256 produced-document.pdfIf that value does not match, the file in front of you is not the file the certificate describes. That alone is diagnostically valuable, because it distinguishes "the redaction was wrong" from "this is not the document that was redacted."
Second, verify the signature over the certificate using OpenSSL and the published public key:
openssl pkeyutl -verify -pubin -inkey basalt-public.pem \
-rawin -in certificate.json -sigfile certificate.sigIf that passes, the certificate contents are exactly what was signed, and the assertions in it were made by the holder of the signing key rather than by whoever last had the file.
Note what these two commands do not require: no application install, no license, no network call, no account. shasum and openssl are present on macOS and every Linux distribution and available on Windows. That is the bar.
Machine readable and human readable
A certificate has two audiences with incompatible needs. A person reading it in a filing wants a document with the file name, the date, the mark count, and the check list laid out legibly. A system ingesting it wants structured data it can index, diff, and validate.
Producing both from the same underlying record solves this: a JSON document that carries the fields and the signature, and a PDF rendering of the same facts for the human reader. The JSON is what gets verified. The PDF is what gets attached to a cover letter.
The failure mode to avoid is a certificate that exists only as a PDF with the values baked into rendered text, because then extracting the hash to check it is an OCR problem.
What a certificate does not do
A certificate is a record of what a tool asserted and verified. It is not a proof that your judgment about what to redact was correct. If you missed a name on page fourteen because nobody marked it, the certificate will faithfully attest that the eleven marks you did apply were properly applied.
It also does not make the redaction correct on its own. The verification has to actually happen against the written output, using a parser independent of the writer, before the certificate is issued. A certificate generated from the tool's intentions rather than from the bytes on disk is a self report. The distinction is the whole substance of how to check whether a PDF was really redacted.
Finally, a certificate is most useful in combination with reproducibility. If the same input plus the same marks always produces a byte identical output, then the hash in the certificate is not just an identity check, it is something a reviewer can independently recreate. That is covered in reproducible redaction.
Fitting it into a production workflow
Practically, keep the certificate with the produced file, not in a separate system that will drift. Name it after the document. Include it in the production set if the protective order allows, or hold it and produce it if the redaction is challenged.
If you maintain a privilege log, the certificate and the log answer different questions and should cross reference each other: the log says why material was withheld, the certificate says that the withholding was technically complete. See building a privilege log from your redactions for how the two fit together.
Frequently asked questions
What is a certificate of redaction?
A certificate of redaction is a signed record that ties a specific redacted file to the operations performed on it and the checks that passed. It should contain a cryptographic hash of the file, the number of marks applied, an enumeration of the verified properties, and a signature that a third party can check. Without those four elements it is a receipt rather than evidence.
Is a certificate of redaction legally required?
Generally no, and that is not the reason to produce one. Its value is practical: if a production is later challenged as altered, over redacted, or under redacted, the certificate lets you answer with checkable facts instead of recollection. Protective orders and agency productions increasingly ask for documentation of the redaction process, and a signed certificate satisfies that cleanly.
How do I verify a certificate of redaction?
Hash the file with shasum -a 256 and compare the result to the hash recorded in the certificate, then verify the certificate's signature with openssl against the published public key. If the hash matches, the file is the one described. If the signature verifies, the contents were not edited after they were signed. Neither step requires installing the tool that produced it.
Why does the certificate contain a SHA-256 hash instead of the file name?
Because file names change constantly during production and prove nothing, while a hash is a fingerprint of the exact bytes. Changing a single byte anywhere in the document produces a completely different hash, so the hash pins the certificate to one specific file. The name is recorded as documentation for humans, not as identity.
Does a certificate of redaction reveal what was redacted?
A properly designed one does not. It records the number of marks and the regions they covered, not the text or images that were removed, since listing the removed content would defeat the redaction. The certificate describes the operation and the checks that passed, which is enough to answer both the over redaction and under redaction questions.
Can I verify a certificate if I do not have the redaction software?
Yes, and that is the whole point of the design. Verification should require only shasum and openssl, both of which ship with macOS and Linux and are available on Windows. If checking a certificate requires installing the vendor's application or calling their server, it is a proprietary claim rather than independently checkable evidence.
What is the difference between a certificate of redaction and a digital signature on a PDF?
A PDF digital signature attests that the document has not changed since it was signed and identifies the signer. A certificate of redaction additionally states what redaction operations were performed and which verification checks passed on the output. They answer different questions, and a document can usefully carry both.
Does a certificate mean the redaction was done correctly?
It means the marks that were applied were applied completely and the listed checks passed on the written file. It says nothing about whether you marked the right material, so a name missed on page fourteen will not appear anywhere in it. Certificates cover technical completeness, and human review still covers judgment.
Doing it in Basalt
Basalt issues a signed certificate of redaction using Ed25519 with the file name, the SHA-256 of the output, the mark count, and the specific checks that passed. It is written as machine readable JSON beside a human readable PDF, so one goes to your system and one goes in the envelope.
Verification requires nothing from Basalt: shasum and openssl are enough, and the commands are on the certificate itself. The certificate is only issued after a built in verifier re-opens the written bytes with an independent parser and proves the redaction, and if it cannot prove it, no file is written and no certificate is issued.
Basalt is $29 once for up to three Macs, free for 24 hours, and a 17 MB download.
Redaction that proves itself
Basalt destroys the content you mark, then re-opens the file it wrote and proves the content is gone before it saves anything. Your documents never leave your Mac.