Encrypted Notes: How They Work and When to Use One

What an encrypted note actually is

What happens when you write a note on Inkrypt

1. 1

   You name the note

   The name becomes the URL slug. Q3 vendor credentials becomes /q3-vendor-credentials. Nothing has been stored yet — the slug is just an address.
2. 2

   You write and set a password

   The password is the only input to the encryption key. It is never sent to our servers, never logged, and never stored in any form we can reverse.
3. 3

   Your browser derives a key

   A 256-bit key is derived from your password using PBKDF2-HMAC-SHA256 at 310,000 iterations, with a fresh 16-byte random salt. This step is intentionally slow — see why iteration count matters.
4. 4

   Your browser encrypts the text

   AES-256-GCM encrypts the note with that key and a fresh 12-byte random IV. GCM also produces an authentication tag, so any later tampering with the ciphertext is detected rather than silently decrypted into garbage.
5. 5

   Only the ciphertext is uploaded

   The server receives the ciphertext, the salt, the IV, and a label recording which key-derivation parameters were used. It does not receive the password or the plaintext.

What encryption protects — and what it does not

Encryption does protect you against

• A breach of our database. An attacker who exfiltrates every row gets a pile of AES-256-GCM ciphertext and per-note salts. Without your password there is no shortcut.
• Us. Not as a promise, but as an architectural fact. There is no code path in which our servers hold a decryption key.
• A legal demand for content. We can only hand over what we hold, which is ciphertext.
• Network interception. The plaintext never crosses the network at all.

Encryption does not protect you against

• A weak password. The strongest cipher in the world is a formality if the key is derived from letmein. Key derivation slows an attacker down; it does not fix a guessable password.
• A compromised device. Malware or a keylogger on your machine sees the plaintext as you type it, before encryption happens. Browser-based encryption cannot defend below its own layer.
• The recipient. Once someone can read a note, they can screenshot it, copy it, or forward it. No expiry setting changes that.
• Losing the password. There is no recovery. That is the direct cost of the guarantee.

When an encrypted note is the right tool

Common mistakes

1. Sending the link and the password through the same channel. If both arrive in the same Slack message, anyone with access to that message has the note. Split them across two channels — link by email, password by phone.
2. Reusing a password you use elsewhere. A note password should be single-purpose. If it matches your email password and the note is brute-forced offline, you have lost far more than the note.
3. Treating expiry as deletion from the recipient's memory. Expiry removes the ciphertext from our servers. It does not remove the screenshot the recipient took.
4. Using a guessable note name. The slug is part of the URL and is not secret. Do not name a note acme-corp-root-password.
5. Assuming an encrypted note is a backup. It is not. There is no redundancy guarantee and no recovery path.

Practical tips

• Generate the password rather than inventing it. Four or five random words is stronger and more typeable than a short string of symbols.
• Set the shortest expiry that still gives the recipient time to read it. A note that lives for two hours has a much smaller exposure window than one that lives for thirty days.
• Use a view limit of one when the note is genuinely single-use. If the recipient reports the link is dead, that is a signal worth investigating — someone opened it first.
• Delete the note manually once you have confirmed receipt, rather than waiting for expiry.
• Rotate the secret afterwards where you can. A password that was shared, even securely, has a wider blast radius than one that never left its origin.