Derive keys for distinct purposes
A key derivation function creates one or more cryptographic keys from input keying material and context. A standard KDF can extract a strong pseudorandom key from suitable input and expand it into separate keys for encryption, authentication, directions, sessions, tenants, or protocol stages.
Purpose separation prevents one key from being reused directly across incompatible algorithms and operations.
Input, salt, and context
The input must have the strength required by the construction. A shared secret from a key agreement can feed a protocol KDF. A user password needs a password-hashing function with salt and work factor, not ordinary HKDF alone.
A salt can separate instances and strengthen extraction assumptions. It is generally not secret. Context or info binds output to protocol, version, role, direction, algorithm, tenant, or purpose. Use an unambiguous encoding and fixed labels. Two purposes must not accidentally derive the same key.
Output and lifecycle
Request only the output length and key types the construction supports. Keep derived keys within their intended scope and lifetime. Destroy them when the session or object ends. Avoid storing a derived key when it can be safely regenerated from protected root material and stable context.
Rotate or replace the root material through a versioned design. Understand which old data or sessions require old derived keys. Protect root material more strongly because it can recreate every descendant key.
Failure and residual risk
A KDF cannot add entropy that the input does not have. Reusing the same context can recreate the same key. Ambiguous concatenation can collapse distinct contexts. Deriving many keys from one root joins their compromise and recovery domain. A compromised endpoint can still invoke or read derived keys.
Pomerium boundary
Pomerium protocols use their defined key schedules and derivation behavior. Applications must not derive their own application keys from Pomerium cookies, assertions, request IDs, or signing keys. Use a dedicated root or key-management service and a standard KDF for the application's explicit purpose.
Evaluation checklist
- Is the input keying material suitable and strong for this KDF?
- Does the use need a password-hashing function instead?
- Are salt and context encoded unambiguously and bound to purpose, version, role, and direction?
- Can two call sites derive the same key for different purposes?
- Is root-key compromise broader than the design can tolerate?
- How are derived-key lifetime, destruction, rotation, old data, and recovery handled?
