Format. This webapp reads and writes the file format used by the original Crypt3 app for MacOS: a tar archive of the source file, gzipped, then encrypted with AES-256-CBC. The output begins with OpenSSL's Salted__ magic followed by an 8-byte random salt, then the ciphertext. The AES key and IV are derived from the password and salt via EVP_BytesToKey with MD5 — the default in OpenSSL 0.9.8, which is what Crypt3 shipped with. The encrypted filename embeds the first 4 hex chars of SHA-1(password), so a wrong password can be rejected before the AES step.

Implementation. Everything runs in the browser. AES-256-CBC and SHA-1 come from the built-in Web Crypto API; MD5 (which Web Crypto doesn't expose) and a small single-file tar reader/writer are implemented inline in plain JavaScript. The only third-party library is pako for gzip, and it is inlined into this HTML — so once the page loads, no further code is fetched from anywhere.

Trust model. Your trust reduces to (a) the browser's Web Crypto API and (b) the integrity of this HTML file. For maximum confidence you can save this page, disconnect from the internet, and serve it locally (e.g. python3 -m http.server) — you can then watch the network and verify nothing ever leaves your machine.

Caveats. The key derivation (EVP_BytesToKey + MD5, single round, no iteration count) is required for Crypt3 compatibility but is weak by modern standards. An attacker with a captured .crypt3 file can try millions of password candidates per second offline, so use a long, high-entropy password. (PBKDF2 or Argon2 would be far stronger but would break the format.) The 4-hex-char SHA-1 prefix in the filename leaks ~16 bits — not enough to materially help cracking. Password inputs are cleared after each run, but JavaScript strings are immutable, so the value can linger in memory until garbage collection. This is hobbyware with no formal security audit; if your threat model is serious, use a tool that has had one.