Security & Privacy

How CryptKit protects your data — and why you can trust it.

Our Core Promise

All cryptographic operations happen entirely in your browser. When you type a password, encrypt a file, or generate a key pair, the data never leaves your device. There is no server to compromise, no network request to intercept, and no database to breach.

How It Works

  • Web Crypto API — For AES, RSA, ECDSA, SHA-256/512, PBKDF2, and other standard algorithms, we use the browser's built-in cryptographic module. This is the same API used by banking websites and enterprise applications.
  • Audited JavaScript Libraries — For algorithms not supported by the Web Crypto API (such as ChaCha20, Blowfish, secp256k1, and Ed25519), we use well-maintained, audited open-source libraries: @noble/ciphers and @noble/curves by Paul Miller, and openpgp.js.
  • Web Workers — Computation-heavy operations (RSA key generation, AES encryption, SHA hashing) run in background threads to keep the UI responsive. Workers execute in the same browser context — your data still does not leave your device.

What We Don't Do

  • No data collection from tool inputs. We do not log your passwords, keys, encrypted messages, or any other data you process with our tools.
  • No user accounts. There is no sign-up, no login, and no server-side storage of any kind.
  • No third-party tracking of cryptographic operations. Our analytics (if enabled) only track page views — never what you type or compute.
  • No ads that execute cryptographic code. All ad content is isolated from the tool's execution context.

Cryptographic Libraries

All libraries used in CryptKit are open-source and publicly auditable:

Library Used For Source
Web Crypto API AES, RSA, ECDSA, SHA, PBKDF2 Browser built-in
@noble/ciphers ChaCha20, Salsa20, XChaCha20 GitHub
@noble/curves secp256k1, ECC point operations GitHub
openpgp.js PGP encryption / decryption GitHub
bcryptjs Bcrypt password hashing GitHub
crypto-js Blowfish, DES/3DES (legacy) GitHub
zxcvbn-ts Password strength estimation GitHub

Security Headers

CryptKit enforces strict HTTP security headers to protect against common web vulnerabilities:

  • Content-Security-Policy (CSP) — Restricts resource loading to trusted sources, preventing XSS and data injection attacks.
  • X-Frame-Options: DENY — Prevents the site from being embedded in iframes, blocking clickjacking attacks.
  • X-Content-Type-Options: nosniff — Prevents MIME-type sniffing, reducing drive-by download risks.
  • Referrer-Policy: strict-origin-when-cross-origin — Limits referrer information sent to external sites.
  • Permissions-Policy — Disables access to camera, microphone, and geolocation APIs.
  • Cross-Origin-Opener-Policy: same-origin — Isolates the browsing context to prevent cross-origin attacks.

Best Practices When Using CryptKit

  1. Verify the URL. Always check that you are on https://cryptkit.dev before entering sensitive data.
  2. Use HTTPS. CryptKit only works over HTTPS. If your connection is not encrypted, your browser will block the Web Crypto API.
  3. Clear your clipboard. After copying a key or password, clear your clipboard as soon as possible. Clipboard data can be read by other applications.
  4. Use strong inputs. Cryptographic security depends on the quality of your keys and passwords. Use our password generator to create strong, random credentials.
  5. Keep your browser updated. Web Crypto API implementations are improved with each browser release. Using an outdated browser may expose you to known vulnerabilities.

Open Source

CryptKit is open-source software. The source code is available for public audit on GitHub. We believe that security through transparency is the only valid approach for cryptographic tools.

If you find a vulnerability or have a security concern, please report it responsibly. We take all security issues seriously and will address them promptly.

Contact

Questions about our security model? Want to report a vulnerability? Visit our contact page.