Browse and seal files
Choose a folder or a file. Create a signed receipt, retain file metadata and commitments, and inspect the custody history.
Your files. A checkable record.Keep the bytes.
Keep the bytes.
Carry the proof.
Sign a file receipt, check what changed, or encrypt for a recipient. Keep the original, the cryptographic record, and the evidence together.
Runs locally in your browser. No server or Node runtime required.
ProofBundle workspaceLocal processing
Original bytes → canonical receipt → independent check
Encrypt for a recipient
ML-KEM-512, 768 or 1024 with AES-256-GCM or ChaCha20-Poly1305. Export the decryption key deliberately and verify before opening.
Check the record
Verify signatures and canonical JSON commitments. Keep recorded authorship, custody signatures, and external timestamp evidence distinct.
Inspectable implementation
A result needs its basis.
Scratch implementations are embedded in the application and linked to their source files. Test receipts identify the vectors, implementation hashes, and observed results.
Published-vector conformance, browser diagnostics, and formal model theorems establish different facts. Implementation-refinement and timing proofs remain open. Passing FIPS-derived vectors is not FIPS module certification.
Read the cryptographic basis →NIST published sample cases855 passing · ML-KEM / ML-DSA
Canonical JSONRFC 8785 · strict input profile
Authenticated encryptionRFC 8439 / SP 800-38D
Local signing identityEd25519 · persistent key
TimestampingSubmitted ≠ verified Bitcoin anchor
Source and test receiptsInspect the evidence ↗
Start with a file.
The application contains the crypto engine. Optional bridge operations have their own connection.