Password-protecting a link: PBKDF2 and key stretching explained

MAIN OÜ Updated 10 July 2026 7 min read

A password you can remember and a key that can encrypt data well are two very different things. The first is short, guessable, and drawn from a small pool of habits; the second must be long, random, and unpredictable. Bridging that gap is the job of a key derivation function, and the classic example is PBKDF2. This guide explains why you cannot hand a password straight to a cipher, what PBKDF2 does about it, why the salt and the iteration count matter, and where the technique fits — including its honest limits.

The problem: passwords are low-entropy

Entropy is a measure of unpredictability — how many guesses an attacker would need, on average, to arrive at your secret. A strong encryption key has a lot of it. A 256-bit AES key is a random value chosen from 2²⁵⁶ possibilities; no one is guessing that by trial and error in the lifetime of the universe.

Human passwords are nothing like that. People reuse words, names, dates, and keyboard patterns. Even a "complex" password with a capital letter and a number sits in a search space attackers have mapped in detail, because everyone reaches for the same tricks. So a password, taken as raw bytes, is a poor substitute for a key: it is short, it is not uniformly random, and its shape is predictable.

You also cannot simply feed a password into AES as-is. A cipher expects a key of an exact size — 256 bits for AES-256 — with every bit effectively random. A typed password is the wrong length and the wrong texture. Something has to convert one into the other without pretending the password was stronger than it is.

What a key derivation function is

A key derivation function (KDF) is a function that takes some input material — a password, in this case — and produces a fixed-size key suitable for a cipher. At minimum it reshapes the input to the right length. A KDF built for passwords does more: it is deliberately designed so that turning a password into a key is slow and hard to shortcut, which matters for reasons we will get to.

The output of a good password KDF looks random and is always the same size, regardless of whether you fed it a four-character password or a forty-character passphrase. Same password plus same settings gives the same key every time, which is what lets a recipient who knows the password reproduce the key and decrypt — while anyone who does not know it is left guessing.

PBKDF2, step by step

PBKDF2 stands for "Password-Based Key Derivation Function 2." It is a long-standing, widely implemented standard, and its idea is simple to describe. It takes a keyed hash function — here HMAC-SHA-512, a standard construction that mixes a key and a message into a fixed-size fingerprint — and applies it over and over to your password combined with a random value. Two ingredients do the real work:

• The salt is a unique random value generated for each derivation. It is not secret; it is combined with the password before hashing so that the same password produces a different key each time the salt differs.
• The iterations are the number of times the hashing is repeated — the "work factor." Instead of hashing once, PBKDF2 hashes the result again, and again, thousands of times over, feeding each round into the next before emitting the final key.

Run PBKDF2 with a password, a salt, and an iteration count, and out comes a key of the size you asked for. Change any input and the key changes completely. That is the whole mechanism: an ordinary hash, repeated a controlled number of times, with a pinch of per-derivation randomness.

Why the salt and the iteration count matter

Neither ingredient is decoration. Each defeats a specific attack.

The salt defeats precomputation. Without a salt, an attacker could hash every common password once, store the results in a giant lookup table — a "rainbow table" — and then match any stolen key against it instantly. A unique salt per derivation breaks that economy of scale: the attacker would need a separate table for every possible salt, which is not practical. The salt also means two people who happen to choose the same password still derive different keys, so cracking one tells you nothing about the other.

The iteration count makes guessing expensive. This is the "key stretching" part. A single hash is fast — a computer does millions per second, which is exactly what an attacker guessing passwords wants. By insisting on many iterations per guess, you make each individual attempt slow. For you, deriving your one key costs a fraction of a second, which you never notice. For an attacker running billions of guesses, that same per-guess cost multiplies into something enormous. classified uses 310,000 iterations, so every candidate password an attacker tries carries the full weight of 310,000 rounds of HMAC-SHA-512.

How classified uses PBKDF2

classified shares encrypted notes and files that self-destruct after a single view. Its base encryption is AES-256-GCM run through the browser-native Web Crypto API, with no third-party crypto libraries. (See our guide on AES-256-GCM in the browser.) In the default link mode, the key is derived from a 128-bit random link secret, and that secret rides in the URL fragment of the share link — never near a password.

Turn on the optional password mode and the flow changes. Now your browser runs PBKDF2-HMAC-SHA-512 at 310,000 iterations to derive the AES key from the password you type. The derivation happens entirely on your device. The server never receives the password and never receives the derived key — it only ever stores ciphertext it cannot read. A recipient who knows the password reproduces the same key in their own browser and decrypts locally; anyone who intercepts the link alone gets an opaque blob.

Because the password is the gate, it should travel to your recipient by a different channel from the link itself — the link in an email, say, and the password by phone or a messaging app. Send both together and you have simply reattached the two halves for anyone watching that one channel.

Choose a good password anyway

Stretching raises the cost per guess; it does not shrink the number of guesses an attacker needs. That still depends entirely on your password. "password123" is near the front of every guessing list, and 310,000 iterations will not save it.

The reliable lever is length combined with unpredictability. A passphrase — several unrelated words strung together, ideally chosen at random rather than from a favourite lyric — reaches high entropy while staying possible to remember and to read aloud down a phone line. Four or five genuinely random words beat a short string of substituted symbols, and they are far easier to dictate to the person on the other end.

PBKDF2 in context

PBKDF2 is not the only key-stretching function, and it is worth being honest about the trade-off. Its work factor is purely computational, which means an attacker with specialised hardware — GPUs or custom chips built to hash in parallel — gets more value from their investment than you do. Newer functions such as scrypt and Argon2 are "memory-hard": they deliberately require a large amount of memory per guess, which is expensive to replicate across thousands of parallel cores and so blunts that hardware advantage.

So why use PBKDF2? Because it is a mature, widely supported standard that is available natively in the browser's Web Crypto API, with no extra libraries to ship, audit, or trust. For deriving a key on the client, in the browser, from a password the server must never see, a high-iteration PBKDF2-HMAC-SHA-512 is a defensible, standards-based choice. A memory-hard function would resist dedicated cracking rigs better; PBKDF2 with a strong password and a high iteration count remains a sound line of defence.