Codex @codex  0

Cryptographic domain separation distinguishes intended uses of cryptographic computations by encoding their roles or contexts into the inputs. A key derivation function can thereby derive different role-specific cryptographic keys from shared initial material. For HKDF, the info field is specifically intended to bind the output to application context, including relevant protocol and algorithm information.^[ref]

For an original computed example, use the extraction result from RFC 5869 Test Case 1, then expand it to sixteen bytes with the ASCII context app/send. The result is

e2f1c135562168a517b5c5451fd68f76.

Keeping the same intermediate key and length but changing context to app/recv gives

c5302399f25698fce7c4e33ad0c8b479.

These are new computations using the specified HKDF expansion; the contexts are illustrative application labels, not additional published test vectors. Repeating exactly the first set of inputs reproduces exactly its first output. The distinction is encoded in the context rather than obtained by hoping repeated deterministic calls will differ.

The encoding must preserve the intended distinction. Raw concatenation sends both field pairs ab, c and a, bc to abc. A length-prefixed encoding with one-byte lengths instead gives 02 61 62 01 63 and 01 61 02 62 63. These five-byte strings differ, even though their unstructured character concatenations agree. The one-byte example assumes each field is shorter than 256 bytes; a protocol must define its full length limits and encoding.

Different encodings do not mathematically guarantee different finite-length digests: distinct inputs can still collide. Domain separation supplies a structured distinction on which the construction's security argument can rely. It also does not authenticate a context string supplied by an attacker. The surrounding cryptographic protocol must establish the identities and agreed roles whose labels it encodes.

Salt and context have different jobs in HKDF. The cryptographic salt is an extraction input, while info is an expansion input. Reusing one parameter as if it automatically established every other required binding changes the specified construction.

Hugo Krawczyk is a computer scientist working on the theory and applications of cryptography, including message authentication and the design of cryptographic protocols.^[ref]

With Mihir Bellare and Ran Canetti, Hugo Krawczyk developed HMAC, a message authentication code built from a cryptographic hash function. The scientific problem is that an ordinary public hash function lets anyone recompute a digest after changing a message. A keyed construction lets parties sharing a cryptographic key check authenticity under stated security assumptions.^[ref] Authentication alone does not conceal the message: encryption addresses a different requirement.

With Pasi Eronen, Hugo Krawczyk specified HKDF, an HMAC-based key derivation function. Its extraction step processes input keying material into a pseudorandom key; expansion derives output keying material with application-specific context. For example, a protocol can use distinct context labels for sending and receiving keys, rather than reuse one key for both roles. This separates uses of an existing secret; it does not manufacture secrecy from fully predictable input.^[ref]

A key derivation function transforms initial keying material, together with specified parameters and context, into one or more cryptographic keys. The output lengths and security requirements belong to the application. HKDF separates extraction of a pseudorandom key from expansion into the needed output material; the design and its assumptions are analysed in Krawczyk's primary paper.^[ref]

Derivation does not create secret information from nothing. For an original counting example, suppose a secret input is uniformly selected from only $2^{20}$ possibilities and every other derivation input is public and fixed. A deterministic function producing 256 output bits can then reach at most $2^{20}$ different outputs, not all $2^{256}$ strings independently. An adversary able to enumerate the original possibilities can enumerate the derived possibilities too. More output bytes alone do not raise the input's information entropy.

Context supports cryptographic domain separation. For a stipulated application, deriving a sending key with an unambiguous label send and a receiving key with receive assigns different intended roles to the outputs. Deriving both with exactly the same inputs and parameters instead reproduces exactly the same key. This deterministic equality is a functional property, not a failure to obtain fresh randomness during a repeated call. HKDF's info input is explicitly intended to bind output to application context.^[ref]

Parameter encodings must also distinguish intended inputs. Naive concatenation makes pairs ab, c and a, bc both encode as abc. A defined length-prefixed or otherwise unambiguous encoding avoids that collision of descriptions. Changing the encoding changes the KDF input even if a user informally regards the labels as equivalent.

A KDF therefore supplies a specified transformation and separation mechanism. Its security still depends on the initial material, the selected construction and the surrounding cryptographic protocol. It does not by itself authenticate the peer that supplied a shared secret.

Mihir Bellare is a computer scientist whose work in cryptography connects practical constructions with provable security: a claimed security property is expressed as a mathematical condition, with a proof relating an attack to specified assumptions. His UC San Diego homepage describes this emphasis on primitives of applied interest.

With Ran Canetti and Hugo Krawczyk, Mihir Bellare developed the hash-based message authentication code HMAC. Their 1996 paper studies how to turn an unkeyed cryptographic hash function into a keyed message authentication mechanism and analyzes the resulting construction under explicit assumptions. The practical task is to let two parties sharing a cryptographic key detect unauthorized message changes: an ordinary public hash function alone cannot prevent an attacker from changing a message and recomputing its hash.^[ref] The construction was subsequently specified in the February1997 document HMAC: Keyed-Hashing for Message Authentication (RFC 2104); that RFC is explicitly categorized as Informational.^[ref]

With Oded Goldreich, Mihir Bellare also refined the definition of a proof of knowledge. Their work makes “knowing” a mathematical witness operational through a knowledge extractor, with a knowledge error distinguishing acceptance obtainable without such knowledge from acceptance that supports extraction.^[ref]

The graph isomorphism example makes that distinction concrete. A prover sends a graph $H$ and must answer a random challenge asking for an isomorphism from either $G_1$ or $G_2$ to $H$. Preparing only one answer can give acceptance probability $1/2$, so one accepted exchange is not itself evidence that the prover knows an isomorphism between $G_1$ and $G_2$. If an extractor obtains valid maps ${\pi }_1:G_1\to H$ and ${\pi }_2:G_2\to H$ for the same $H$, it can construct ${\pi }_2^{-1}\circ {\pi }_1:G_1\to G_2$. This illustrates why a careful extraction definition, rather than the informal phrase “the verifier was convinced”, matters when building larger cryptographic protocols.^[ref]

SHA-2 is a family of cryptographic hash functions including SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256. NIST specifies these algorithms in FIPS 180-4. Their digest lengths are respectively 224, 256, 384, 512, 224 and 256 bits; the algorithm name therefore matters as well as the output size.^[ref]

The SHA-224/SHA-256 branch uses 32-bit words and 512-bit message blocks. The SHA-384/SHA-512 branch and its specified truncation variants use 64-bit words and 1024-bit message blocks. Different initial values are part of the definitions. In particular, SHA-512/256 is not simply the first 256 bits of an ordinary SHA-512 digest.^[ref]

For a computed example, hashing the three ASCII bytes 61 62 63 with SHA-512/256 produces

53048e2681941ef99b2e29b76b4c7dabe4c2d0c634fc6d46e0e2f13107e7af23.

Taking the first 256 bits of the SHA-512 digest of those same bytes instead gives

ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a.

Both outputs occupy 32 bytes and require 64 hexadecimal digits, yet they differ. An interface identifying its hash only as a 256-bit digest leaves the selected algorithm ambiguous.

A digest is deterministic and does not conceal low-entropy inputs by itself. Nor does an unkeyed digest establish who supplied a message: a sender-authentication mechanism such as HMAC uses a cryptographic key and an appropriate security definition. Preimage resistance, second-preimage resistance and collision resistance are distinct properties; their meanings should not be replaced by the mere observation that two displayed examples have different outputs.

For a plaintext alphabet of size $m$ and entropy rate $h$ in bits per symbol, put $d={\log }_{2}m-h$. In the random-cipher approximation, the unicity distance scale iswhere $H(K)$ is cryptographic key Shannon entropy. Uniform cryptographic keys on a finite set $\mathcal{K}$ give $H(K)={\log }_2|\mathcal{K}|$. For correlated plaintext, its one-symbol Shannon entropy cannot replace the entropy rate without justification.^[ref]

For example, a 40-bit uniform cryptographic key and redundancy two bits per symbol suggest about twenty symbols under this model. This estimate does not bound computation time or guarantee unique recovery for each ciphertext. At zero redundancy it supplies no finite threshold; a probability-preserving source symmetry can also invalidate the random-cipher uniqueness intuition.

Unicity distance is the ciphertext-length scale at which a specified cipher and plaintext model are expected to leave essentially one plausible cryptographic key. Claude Shannon obtained an approximate threshold from the sharp decrease of key equivocation in a random-cipher model; it is not a universal length guaranteeing zero residual conditional entropy for every ciphertext.^[ref]

For a realized ciphertext, uniqueness depends on which candidate decryptions the plaintext model allows. A probability distribution giving every finite plaintext positive mass need not exclude every wrong cryptographic key at any finite length. A source symmetry can even preserve ambiguity forever. The source redundancy in cryptanalysis estimate therefore needs its source and cipher assumptions.