Reference
Encryption Glossary
41 terms, defined in plain English. Each entry also says why it matters in practice — because knowing what a salt is is less useful than knowing what goes wrong without one.
Security vocabulary is a barrier to good decisions. People end up choosing tools based on which marketing copy sounds most confident, because the words needed to evaluate the claims are unfamiliar. This page exists to remove that barrier.
- AES
The Advanced Encryption Standard, a symmetric block cipher selected by NIST in 2001 following an open international competition. It operates on 128-bit blocks and supports 128-, 192- and 256-bit keys.
In practice: AES protects the majority of encrypted data in the world and is implemented in hardware on modern processors. No practical break of full AES exists.
See also: AES-256-GCM explained
- AES-256-GCM
AES with a 256-bit key, operating in Galois/Counter Mode. GCM is an authenticated mode: alongside ciphertext it produces an authentication tag that is verified before decryption.
In practice: The 'GCM' part matters more than most people realise. Without an authenticated mode, an attacker can modify ciphertext and the recipient decrypts altered data without any warning.
See also: AES-256-GCM explained
- Argon2
A modern password-hashing and key-derivation function, winner of the 2015 Password Hashing Competition. Its Argon2id variant is the current general recommendation.
In practice: Argon2 is memory-hard, meaning it demands significant RAM as well as CPU time. That blunts GPU and ASIC attacks in a way PBKDF2 cannot. It is not yet exposed by the Web Crypto API.
- Asymmetric encryption
Encryption using a mathematically linked key pair: a public key that encrypts and a private key that decrypts. RSA and elliptic-curve cryptography are the common examples.
In practice: Asymmetric encryption solves key distribution — you can publish a public key safely. It is far slower than symmetric encryption, so it is normally used to exchange a symmetric key rather than to encrypt bulk data.
See also: AES vs RSA encryption
- Authenticated encryption
Encryption that provides integrity and authenticity as well as confidentiality, so that any modification of the ciphertext is detected. GCM, ChaCha20-Poly1305 and encrypt-then-MAC constructions all qualify.
In practice: Confidentiality without integrity has caused many real-world breaks, including padding-oracle attacks. If a service names a cipher but no authenticated mode, that is worth asking about.
- Authentication tag
A short value produced during authenticated encryption — 128 bits in AES-GCM — computed over the ciphertext and verified before decryption proceeds.
In practice: If the tag does not verify, decryption fails outright rather than returning corrupted plaintext. This is why a wrong password and a tampered note look identical to the user.
- Base64
An encoding that represents binary data using 64 printable ASCII characters. Not encryption and not obfuscation — it is trivially reversible by anyone.
In practice: Ciphertext is base64-encoded purely so it can be stored in text fields and transmitted in JSON. Data that is 'base64 encoded' is not protected in any way.
- Block cipher
A cipher that transforms fixed-size blocks of data — 128 bits for AES — under a key. A mode of operation extends it to messages of arbitrary length.
In practice: The choice of mode has historically caused far more real-world failures than any weakness in the cipher itself.
- Brute-force attack
Trying every possible key or password until one works. Its feasibility depends entirely on the size of the space being searched.
In practice: Brute-forcing a 256-bit key is physically impossible. Brute-forcing the password a human chose to protect it is often very possible — which is why key derivation and password strength matter far more than key size.
- Ciphertext
The output of encryption: data transformed so that it is unreadable without the correct key.
In practice: When a service says it stores only ciphertext, the meaningful follow-up question is who holds the key.
- Client-side encryption
Encryption performed on the user's own device before data is transmitted, so the service provider only ever receives ciphertext.
In practice: This is what makes provider-blind storage possible. You can verify it in seconds: watch your browser's Network tab while saving, and check whether your text appears in the request body.
See also: Client-side encryption, Client-side vs server-side
- Cryptographically secure random number generator (CSPRNG)
A random number generator whose output is unpredictable even to an attacker who has seen previous output. Browsers expose one via the Web Crypto API.
In practice: Ordinary random functions such as JavaScript's Math.random are not suitable for cryptography — their output can be predicted, which would make salts and IVs worthless.
- Data minimisation
The principle of collecting and retaining only the personal data actually required for a stated purpose. A core requirement of the GDPR and similar regimes.
In practice: Expiring notes support this directly: sensitive text stops existing when it is no longer needed, rather than sitting in an inbox by default.
- Decryption
Reversing encryption using the correct key to recover the original plaintext.
- End-to-end encryption (E2EE)
Encryption in which only the communicating parties can read messages; intermediaries — including the service carrying them — cannot.
In practice: E2EE describes who can read something. Client-side encryption describes where the operation runs. They overlap heavily but are not synonyms.
- Entropy
A measure of unpredictability, usually expressed in bits. A password with 60 bits of entropy would take roughly 2^60 guesses to find by exhaustive search.
In practice: Entropy comes from genuine randomness, not from looking complicated. 'P@ssw0rd!' has far less entropy than four randomly chosen words, despite appearing more complex.
- Ephemeral data
Data designed to exist only for a limited period before being deleted.
In practice: The security value is not in any single deletion but in the change of default: nothing accumulates unless someone deliberately decides it should.
See also: Self-destructing notes
- Forward secrecy
A property of some protocols whereby compromise of a long-term key does not expose previously recorded sessions, because each session used an ephemeral key.
In practice: A property of transport protocols such as TLS rather than of stored-data encryption. Password-encrypted notes do not have forward secrecy: the password decrypts the note whenever it is obtained.
- GCM (Galois/Counter Mode)
An authenticated mode of operation for block ciphers, providing confidentiality and integrity in a single pass.
In practice: GCM has one catastrophic failure mode: reusing an initialisation vector with the same key. Correct implementations generate a fresh random IV for every operation.
- Hash function
A one-way function mapping input of any size to a fixed-size output, where finding two inputs with the same output should be infeasible. SHA-256 is a common example.
In practice: Hashing is not encryption — it cannot be reversed, so it cannot be used to store data you need to read back. It is used for integrity checks and inside key-derivation functions.
- HMAC
Hash-based Message Authentication Code: a construction that combines a hash function with a secret key to produce a value proving both integrity and authenticity.
In practice: PBKDF2-HMAC-SHA256 uses HMAC as its internal building block, repeated once per iteration.
- HSTS
HTTP Strict Transport Security: a response header instructing browsers to contact a site only over HTTPS for a stated period.
In practice: Prevents downgrade attacks where an attacker forces an initial plaintext HTTP request.
- Initialisation vector (IV)
A value combined with the key at the start of encryption so that encrypting identical plaintext twice produces different ciphertext. Twelve bytes in standard AES-GCM.
In practice: IVs are not secret and are stored alongside ciphertext. What matters is that they are never reused with the same key — in GCM, reuse can allow message forgery.
- Key derivation function (KDF)
A function that turns a low-entropy input such as a password into a cryptographic key, deliberately consuming time and sometimes memory to make guessing expensive.
In practice: The KDF and its parameters usually matter more than the cipher. AES-256 says nothing about how the key was produced, which is where most real weakness lives.
See also: Password-protected notes
- Key escrow
An arrangement where a copy of a decryption key is held by a third party, typically to permit recovery or lawful access.
In practice: Key escrow and zero-knowledge are mutually exclusive. A service offering account recovery that preserves your existing content necessarily has some form of escrow.
- Keyspace
The total number of possible keys for a given algorithm. AES-256 has a keyspace of 2^256.
In practice: A large keyspace is only meaningful if keys are drawn from it uniformly. A 256-bit key derived from a common password effectively occupies a keyspace the size of a wordlist.
- Metadata
Data about data — timestamps, sizes, addresses, access counts — as distinct from content.
In practice: Encryption protects content, not metadata. A provider that cannot read your notes can still see when they were created and how often they were fetched.
See also: Threat model
- Mode of operation
The scheme by which a block cipher is applied to messages longer than a single block. GCM, CBC and CTR are examples.
In practice: 'AES-256' without a named mode is incomplete information. The mode determines whether tampering is detectable.
- Non-extractable key
A key object the browser's cryptographic layer will use for operations but will not export as raw bytes into JavaScript.
In practice: Closes an entire category of accidental leakage — a non-extractable key cannot end up in an error report or a log line, even by mistake.
- Offline attack
An attack in which the adversary holds the encrypted data and can attempt decryption at their own pace, without interacting with the service.
In practice: Rate limiting and lockouts are useless against offline attacks. Only key-derivation cost and password strength apply, which is why both matter so much.
- PBKDF2
Password-Based Key Derivation Function 2, defined in RFC 8018. Repeatedly applies a pseudorandom function — usually HMAC-SHA256 — over a password and salt.
In practice: Well established and available natively in every browser, but not memory-hard, so it resists GPU acceleration less effectively than Argon2id. OWASP's current minimum is 310,000 iterations for HMAC-SHA256.
- Plaintext
Data in its original readable form, before encryption.
- Rainbow table
A precomputed lookup table mapping candidate passwords to their hashes or derived keys, used to reverse them quickly.
In practice: Entirely defeated by salting. Because each note gets a unique random salt, no precomputed table can apply to it.
- Salt
Random data mixed into key derivation so that the same password produces a different key each time. Not secret, and stored alongside the ciphertext.
In practice: Per-item salts mean cracking one item gives an attacker no head start on any other, and precomputed tables are worthless.
- Server-side encryption
Encryption performed by the service after data arrives, using keys the service manages.
In practice: Protects against stolen hardware and some breach scenarios, but not against the provider, since the provider holds the keys and handles plaintext in memory.
See also: Client-side vs server-side
- Side-channel attack
An attack that extracts secrets from physical or timing characteristics of an implementation rather than from the algorithm itself.
In practice: A reason to prefer native cryptographic implementations such as the Web Crypto API over hand-rolled JavaScript, which is much harder to make constant-time.
- Symmetric encryption
Encryption where the same key both encrypts and decrypts. AES is the dominant example.
In practice: Fast and well suited to bulk data. Its difficulty is key distribution — both parties need the same key, which is exactly the problem secure sharing addresses.
- TLS
Transport Layer Security, the protocol securing data in transit over the internet. The 'S' in HTTPS.
In practice: TLS protects data on the wire and terminates at the server, which then sees plaintext. 'Encrypted in transit' is therefore a much weaker statement than 'encrypted before transit'.
- View limit
A cap on how many times encrypted content may be retrieved before it is deleted.
In practice: Also functions as a tripwire: if a recipient reports a one-view link already dead, someone or something fetched it first. Automated link scanners are the usual culprit.
See also: Self-destructing notes
- Web Crypto API
The browser's native cryptography interface, exposed as `crypto.subtle`, providing key derivation, encryption, signing and secure random generation.
In practice: Implemented in the browser engine rather than JavaScript, so it is faster and far better positioned to resist timing side-channels.
- Zero-knowledge
In industry usage, a design in which the service provider structurally cannot read user content because no decryption key ever exists on its systems.
In practice: Distinct from the formal cryptographic term 'zero-knowledge proof'. The practical test is whether the provider can restore access to your existing data after you forget your password — if yes, it holds a key.
See also: Zero-knowledge encryption, What it means, in depth
A
B
C
D
E
F
G
H
I
K
M
N
O
P
R
S
T
V
W
Z
Related reading
Security architecture
These terms applied to a real system, with exact parameters.
Read moreSecurity insights
Long-form articles on encryption, privacy and secure sharing.
Read moreThreat model
What our design defends against, and what it does not.
Read moreHow Inkrypt works
The end-to-end walkthrough of a note's life.
Read moreLast reviewed . Spotted a definition we have got wrong? Tell us.
Write your first encrypted note
No account, no email address, no download. Type a note, set a password, and share the link.
Open the notepad