Threat Model

"Is this secure?" is not an answerable question. "Secure against whom, doing what?" is. A tool that comprehensively defeats a database breach may be useless against malware on your laptop, and saying so is the difference between a security product and a security-flavoured one.

The cost of vagueness is real. Someone who believes a tool protects them against an adversary it does not defend against will take a risk they would otherwise have avoided. That is a worse outcome than using nothing.

Strongly defended. An attacker who exfiltrates every row obtains AES-256-GCM ciphertext, per-note random salts and IVs. There is no master key to steal, because none exists. Each note must be attacked independently, offline, against whatever password protects it — and per-note salting means cracking one gives no advantage on the next.

Strongly defended. All traffic is TLS, but more importantly the plaintext never enters the network at all. Even a complete break of TLS on a given connection would reveal only ciphertext, a salt and an IV.

Strongly defended, structurally. There is no code path in which our servers hold a decryption key. This is not a promise not to look; it is the absence of the capability to look. It follows that a legal demand can only produce ciphertext.

Defended, provided you split the channels. A share token retrieves ciphertext; the password decrypts it. Someone with just the link holds unreadable data. This protection evaporates entirely if you send both in the same message — see secure link sharing.

Defended by expiry. The specific risk that a credential shared in 2023 is still readable in a chat archive today is addressed directly: expiry and view limits make deletion the default outcome rather than a manual chore nobody performs.

Partially mitigated. PBKDF2 at 310,000 iterations multiplies the cost of every guess, and per-note salts prevent precomputation and amortisation. But an attacker holding your ciphertext can grind at their own pace with no rate limit we can impose. Against a weak password, key stretching buys time and nothing more.

Your password is the binding constraint on this entire system. Four or more random words moves it from "hours" to "not worth attempting".

Partially mitigated. Corporate mail filters and chat link-preview bots fetch URLs automatically, which can consume a view-limited link before the human clicks. They obtain only ciphertext, so this is an availability problem rather than a confidentiality one — but it is a real and common annoyance. Allow two or three views when sending into a filtered environment.

Partially mitigated. We cannot read notes, but we necessarily observe that a request occurred, when, and against which slug. Slugs are not encrypted. An observer with access to our logs learns nothing about content but does learn that a note by a given name existed and was fetched.

Not defended. A keylogger or infostealer on your machine sees plaintext as you type it and captures the password as you enter it. Encryption happens after that point. No browser-based tool can defend below its own layer — if your endpoint is compromised, nothing running on it can be trusted.

Not defended, and not defensible. Once someone can read a note they can screenshot it, copy it, photograph the screen or simply remember it. Expiry controls availability from our servers; it has no reach into anyone's memory or clipboard. Any product implying otherwise is misleading you.

Not defended. We serve the JavaScript that performs the encryption. A compromised operator — or an attacker with control of our delivery pipeline — could serve modified code that exfiltrates passwords. This is the fundamental limitation of all browser-delivered cryptography, and it applies to every web-based encryption tool without exception.

Not defended, by design. There is no recovery. If we could restore access, we could read your notes — the two capabilities are identical. Availability is deliberately traded away for confidentiality.

Not defended. Nothing here helps if someone can compel *you* to reveal the password. There is no duress mode and no plausible-deniability construction.

If your situation falls in the bottom half of that table, the honest answer is that Inkrypt is not the right tool, and we would rather tell you that here than have you find out later.