When users protect data with a passphrase, derive a key-encrypting key from it with a slow password-based function, and use that to wrap a random data-encryption key. The data itself is encrypted with the random key. Changing the passphrase then re-wraps one small key instead of re-encrypting everything.
The pattern
OWASP's cryptographic storage guidance describes it: a key derivation function can generate a KEK from user-supplied input such as a passphrase. The KEK then encrypts a randomly generated DEK. Changing the passphrase only requires re-encrypting the DEK, not the data. The KEK should be at least as strong as the DEK and stored separately from it.
The steps for creating:
- Generate a random DEK from a CSPRNG.
- Encrypt the data with the DEK using an AEAD.
- Pick a random salt and derive a KEK from the passphrase with a slow function such as Argon2id, scrypt or PBKDF2.
- Wrap the DEK with the KEK using an AEAD or a key-wrap mode.
- Store the salt, the KDF parameters, the wrapped DEK and the encrypted data. Never store the KEK or the passphrase.
To open: repeat steps 3 and 4 in reverse.
Why not use the passphrase key directly
- Changing the passphrase would force re-encrypting all data.
- You could not add a second unlock method, such as a recovery key, without duplicating data.
- A weak passphrase would sit directly on the bulk data, and you could not raise the work factor later without re-encrypting.
With a wrapped DEK you can store several wrapped copies, one per passphrase or recovery key, all opening the same data.
Choosing the derivation
A fast hash or HKDF alone is wrong here, as covered in HKDF versus password hashing. Store the algorithm name and parameters in a header so you can raise them later, and use a unique random salt per user.
What to remember about recovery
A forgotten passphrase with no other wrapped copy means the data is gone. That is the design working, so decide on recovery up front. Our guide to key backup and escrow lists the choices. A version field in the header lets you migrate formats later.
This is the same structure as envelope encryption, with a passphrase-derived key on top instead of a cloud key service.
Quick check
Does the salt need to be secret?
No, but it must be unique and random per derivation and stored with the wrapped key.
Can I use the same DEK for every user?
Avoid it. Use a separate DEK per user, file or tenant so one wrapped key opening does not expose everything.
Sources
Last reviewed: 19 October 2026.
