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.
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.
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

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.