Skip to main content
Orilami

Choose a file, pick a sanitization standard, and shred it in your browser. You'll get a cryptographically signed Certificate of Destruction with pre/post digests — as JSON and a branded PDF.

Digital Shredder & Verifiable Certificate of Destruction

A local-first data sanitization tool for engineers who need a defensible audit trail. It overwrites a file's in-browser working copy with standards-shaped multi-pass patterns, confirms the buffer is all-zero, and issues a Certificate of Destruction signed with an asymmetric key pair. Every byte of work happens in a Web Worker on your device — no upload, no network, no server.

The destruction state machine

  1. Pre-hash — SHA-256 over the source bytes captures the pre-destruction digest.
  2. Multi-pass overwrite — fixed patterns, bitwise complements and CSPRNG entropy are written in place over the Uint8Array, chunked so gigabyte files never freeze the UI.
  3. Zeroization — a final .fill(0) pass leaves the buffer deterministic.
  4. Verification re-hash — a linear scan proves zero residual bytes and the post digest equals SHA-256 of an all-zero buffer.
  5. Signing — a canonical JSON payload is signed with Ed25519 (or ECDSA P-256) via WebCrypto and the public key is embedded.
  6. Teardown — the working buffer is zeroed and detached; no blob URLs, IndexedDB or localStorage retain the data.

Standards

  • NIST SP 800-88 Rev. 1 (Clear) — single CSPRNG pass.
  • DoD 5220.22-M (E) — 0x00 → 0xFF → random, three passes.
  • Paranoid (7-pass) — 0x00 · 0xFF · 0xAA · 0x55 plus three CSPRNG passes.

What the certificate honestly claims

The Certificate of Destruction attests that the in-browser working copy of the asset was overwritten with the stated sequence and verified all-zero, then signed. Because a web page cannot reach the storage controller, it does not claim firmware Secure-Erase, inode unlinking, or purge of a drive's spare/over-provisioned blocks. For NIST SP 800-88 Purgeon physical media, pair this with device-level tooling. The wording in the JSON and PDF states this scope so the artifact stays truthful for auditors.

Verifying a certificate

The certificate is canonicalized (recursively key-sorted, minimal-whitespace JSON — orilami-jcs-v1) before signing, so any third party can re-derive the exact signed bytes, import the embedded JWK public key, and verify the signature with standard WebCrypto/JOSE. The Verify tab does this offline, and also recomputes SHA-256 of an all-zero buffer of the asset's size to confirm the post digest independently.

FAQ

Does this delete the original file from my disk?
No. Browsers cannot reach the filesystem or storage controller. This overwrites and verifies the in-memory copy of the bytes you select, then certifies exactly that. To physically purge a drive, use device- or firmware-level tools alongside this certificate.
Is anything uploaded?
Never. Reading, hashing, overwriting and signing all run in a Web Worker in your browser. No network request is made and nothing is written to IndexedDB, localStorage or a blob cache.
Which signature algorithms are used?
Ed25519 where the platform's WebCrypto supports it, otherwise ECDSA P-256 with SHA-256. The algorithm actually used is recorded in the certificate and the public key is embedded as a JWK.
How does an auditor verify the certificate?
Canonicalize the certificate block (orilami-jcs-v1), import the embedded JWK public key, and verify the base64 signature with WebCrypto. Independently, SHA-256 of an all-zero buffer of the asset's size must equal the post-sanitization digest. The Verify tab performs both checks.
Is the PDF a PDF/A archive?
It is a portable, branded PDF with the signed JSON attached and a fingerprint QR — not a certified PDF/A-1b file, which would require embedded fonts and ICC/XMP metadata. The certificate never claims PDF/A conformance.