How Inkrypt Works

The short version

Creating a note

1. 1

   You choose a name

   The name becomes the note's URL — Project handover becomes /project-handover. Nothing is stored yet. Note names are not encrypted and appear in URLs, browser history and logs, so keep them non-descriptive.
2. 2

   You write the note

   Text stays in your browser's memory. Nothing has been transmitted at this point.
3. 3

   You set a password

   This is the only input to the encryption key. It is never transmitted, never logged, and never stored in any form — including as a hash.
4. 4

   Your browser generates randomness

   A 16-byte salt and a 12-byte initialisation vector are drawn from the browser's cryptographically secure random number generator. Both are new every single time you save.
5. 5

   Your browser derives a key

   PBKDF2-HMAC-SHA256 runs 310,000 iterations over your password and the salt, producing a 256-bit AES key. This is the brief pause you notice when saving — it is deliberate, and it costs any attacker the same on every guess. PBKDF2 is specified in RFC 8018 and recommended for password-based key derivation in NIST SP 800-132.
6. 6

   Your browser encrypts

   AES-256-GCM encrypts the text with that key and IV, producing ciphertext plus a 128-bit authentication tag that will later detect any tampering. AES is specified in NIST FIPS 197 and GCM in NIST SP 800-38D; both run through the browser's Web Cryptography API.
7. 7

   The ciphertext is uploaded

   The encrypted blob, the salt, the IV and a label recording the key-derivation parameters travel to our servers over TLS. Your password and your text do not.

What each party can see

Sharing a note

1. 1

   You choose what to share

   Sharing acts on one note and produces a snapshot of it — a point-in-time copy, encrypted separately. The original note is not moved, unlocked or altered.
2. 2

   A share key is chosen, separate from your note password

   If you set a password on the share, that becomes the key. If you do not, your browser generates a random one. Your note's own password is never reused for this and is never sent.
3. 3

   Your browser encrypts the snapshot

   Title and body are encrypted locally with AES-256-GCM under a PBKDF2 key at 310,000 iterations, using a fresh salt and IV generated for this share alone.
4. 4

   Ciphertext and your settings are uploaded

   The upload carries the encrypted snapshot, its salt and IV, and whatever expiry or view limit you chose. It does not carry the key.
5. 5

   The server returns a link

   It issues a random token for the address and stores only a hash of it, so the database cannot be read back into working links.
6. 6

   For a passwordless share, the key is added after the #

   The finished link looks like /share/<token>#key=<key>. Browsers resolve the part after # locally and never put it in the request, so the key reaches your recipient without ever reaching us.
7. 7

   The recipient's browser does the decryption

   It fetches the ciphertext, takes the key from the fragment or prompts for the share password, and decrypts locally. The plaintext exists only in their tab.

Opening a note

1. 1

   The recipient loads the URL

   Their browser requests the encrypted payload. If a view limit is set, this fetch is what increments the counter — regardless of whether decryption later succeeds.
2. 2

   They enter the password

   It stays in their browser, exactly as yours did.
3. 3

   Their browser re-derives the key

   The same PBKDF2 parameters, using the salt stored with the note, reproduce the identical 256-bit key. This is why the salt must be stored and why it does not need to be secret.
4. 4

   Their browser verifies and decrypts

   AES-GCM checks the authentication tag first. If the ciphertext has been altered in any way, decryption fails rather than returning corrupted text. Otherwise the plaintext appears.
5. 5

   The note reaches its end state

   It remains available until expiry, the view limit, or manual deletion — whichever comes first.

Editing and deleting

• Editing requires the correct password. Saving re-encrypts the note with a fresh salt and a fresh IV, so no two saves ever reuse the same key-and-IV pair — the one failure mode GCM cannot tolerate.
• Changing the password re-derives a new key and re-encrypts. The old ciphertext is replaced.
• Deleting removes the stored record immediately. Because we only ever held ciphertext, there was never a readable copy to remove.
• Expiry does the same thing automatically when the time or view limit is reached.

What this cannot do

• It cannot recover a note whose password you have forgotten. There is no key on our side to recover it with.
• It cannot stop a recipient copying, screenshotting or remembering what they read.
• It cannot protect you if your own device is compromised — plaintext exists before encryption runs.
• It cannot make a weak password strong. Key derivation buys time proportional to how hard the password is to guess.