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 a small amount of operational metadata for the note: its slug (which is its URL and therefore never private), a creation timestamp, a last-updated timestamp, and a schema version. That is the complete list. A note record carries no expiry field and no view counter — those belong to share links, which are stored separately and described below. What the server does not hold, for either, is any password, any password hash, any derived key, or any plaintext.

If the distinction between this arrangement and the more common one — where a server encrypts data it has already read — is unfamiliar, we set it out at length in client-side vs server-side encryption.

Sharing does not hand out your note's password. A share link is a separate, encrypted snapshot of one note, protected by its own key, and the note it came from is never exposed by it. Because the two use different keys, revoking or expiring a share has no effect on the note, and holding a share link tells the holder nothing about the note's own password.

Two properties of this design have real consequences worth understanding before you rely on them, including how share passwords are stored. Both are set out in known limitations we accept.

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.

When you password-protect a share link, the server stores a single-round, unsalted SHA-256 of that password so it can check what a recipient types. That is a weak way to store a password: it is fast to compute, so it can be attacked with precomputed tables or at very high guess rates, unlike the 310,000-iteration derivation used for the content itself.

What it does not mean: the hash is not the decryption key, and it is not what the ciphertext is protected with. The snapshot is still AES-256-GCM under a PBKDF2 key with a fresh salt. What it does mean is that for a password-protected share, the password you choose is also the content key — so if that password is short or guessable, recovering it from the stored hash recovers the content, and the 310,000 iterations do not save you.

The practical advice follows directly: for a password-protected share, use a long random passphrase rather than a memorable one. If you do not need a second factor on the link, prefer a passwordless share, where the key is a random value generated in your browser and never sent to us at all.

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.