Security Architecture

Inkrypt is built around a single constraint: our servers must never be able to read a note's contents, even under compulsion, even if fully breached, even if we wanted to. Everything else in the design follows from that, including the features we cannot offer.

The way to achieve that is not policy but arithmetic. If the decryption key never exists on our infrastructure, then reading your note is not a matter of access control — it is a matter of breaking AES-256, which nobody can do.

These are the values currently in use. They are recorded here so the documentation can be checked against behaviour, and so any future change is visible on the changelog.

The password you type is never used directly as a key. It is stretched through PBKDF2-HMAC-SHA256 with a fresh 16-byte random salt and 310,000 iterations, producing a 256-bit AES-GCM key.

The derived key is created as a non-extractable CryptoKey. The browser's crypto layer will use it to encrypt and decrypt, but will not export the raw bytes back into JavaScript — including to our own code. That closes an entire category of accidental key leakage through logging or error reporting.

The iteration count is stored alongside each note as a label such as pbkdf2-310000, and decryption uses the parameters the note was created under. This means the count can be raised for new notes without stranding older ones — the mechanism for a future migration is already in place.

Per note, exactly four values relating to content. None of them, alone or together, permits decryption.

Salts and IVs are not secret in any correctly designed system — they exist to guarantee uniqueness, not confidentiality, and both must be available to reproduce decryption. Their security value comes entirely from being fresh and random, which they are.

Alongside these, the server holds operational metadata: the note's slug (which is its URL and therefore never private), creation time, expiry configuration, and a view counter where limits are set. What the server does not hold is any password, any password hash, any derived key, or any plaintext.

A security page that lists only strengths is marketing. These are the real constraints of this design, in rough order of how much they should affect your decision.

This is the fundamental limitation of all browser-delivered cryptography. Your browser fetches our JavaScript on every visit and runs it. A compromised or malicious operator could serve a modified script that captures passwords before encryption. No amount of correct cryptography inside the page defends against the page itself being replaced.

Installed applications with signed, independently verifiable builds are genuinely stronger here. If your adversary is capable of compelling or compromising a service provider at the delivery layer, no browser-based tool — including this one — is the right choice.

PBKDF2 at 310,000 iterations makes each guess expensive; it does not make a weak password strong. An attacker holding exfiltrated ciphertext can attack it offline at their own pace. A note protected by a dictionary word is protected by a dictionary word, whatever the cipher.

Argon2id resists GPU and ASIC attacks better because it demands memory as well as time. We use PBKDF2 because it is the only password-based KDF exposed natively by the Web Crypto API across all browsers we support, and a native constant-time primitive is preferable to a JavaScript Argon2 for the threats most users face. This is a considered trade-off, not an oversight.

Malware or a keylogger on your device observes plaintext as you type, before any encryption occurs. Client-side encryption cannot defend below its own layer.

Inkrypt has not been through a third-party cryptographic audit. The algorithms and parameters are standard and documented here so they can be evaluated, but you should weigh the absence of external review. We would rather state this than let the omission be inferred.

If you believe you have found a vulnerability, our responsible disclosure policy explains how to report it and what to expect. We would much rather hear from you than not.