HKDF Info: Bind Protocol Context to Derived Keys

DEV Community

HKDF info is where protocol context becomes key identity

HKDF info is where protocol context becomes key identity A key derivation function turns one secret into several keys. HKDF separates that work into an extract step and an expand step. RFC 5869 defines an optional info input for the expand step and describes it as context and application-specific information. The field is optional in the API. Treating it as optional in a shared-key deployment is a different decision. The extract step computes a pseudorandom key from input keying material and an optional salt. The expand step uses that pseudorandom key, the info value, and an output length. If two applications use the same input secret and the same output length but different info values, they receive different output keys. The info value is not secret. Its job is to make the intended use unambiguous. Make the context a fixed grammar A useful info value identifies the protocol version, key purpose, sender or receiver role, algorithm, and any identifier that changes the key's meaning. Encode fixed fields with lengths or a canonical serialization. Do not concatenate user-controlled strings in a way that lets ("ab", "c") and ("a", "bc") produce the same input. Examples include myproto/v2/ingress/session-key and a structured binary context with a protocol label, a 32-bit version, a direction byte, and a bounded identifier. The exact format matters less than consistency across languages and versions. Publish test vectors for the language implementations and keep old contexts readable during migration. Do not put a password, token, or other secret into info. It is a public domain label. If the deployment needs to bind a key to a secret identifier, derive a separate value or use a construction designed for that purpose. Keep extraction and expansion deliberate RFC 5869 warns against skipping the extract step when the input is a Diffie-Hellman value. The details belong to the protocol design. The operational review is simpler: identify every place that calls an HKDF API and confirm that it follows the protocol specification rather than a copied helper with different defaults. Check the output length against the hash function. HKDF-Expand has a limit related to the hash output size. A caller that asks for an excessive length should receive a deterministic error, not a truncated key. Enforce the same limit in every language binding. Salt values also need a policy. They can be public, but a missing salt and a fixed salt are not the same deployment choice. Record whether the protocol uses a random salt, a transcript-derived salt, or an explicit zero value. Do not let a retry silently choose a different salt if the protocol expects a reproducible derivation. Test key separation Build a small matrix with two contexts that share the same input secret. Verify that the output keys differ, that each context produces the same key on every implementation, and that a context from one service is rejected by the other service. Include a context-version change and a key-rotation case. Logging should record the protocol, context label, algorithm, and output length, not the secret or the derived key. That information is enough to compare configuration and diagnose a mismatch without creating another data store full of key material. HKDF does not authenticate a peer, encrypt a message, or choose an application identifier. It provides a controlled expansion from a secret. The info field is the place where the team states what that secret is for. References RFC 5869, HMAC-based Extract-and-Expand Key Derivation Function RFC 8619, Algorithm Identifiers for HKDF

Powered by Readybot.io