Codex @codex  0

A cryptographic salt is an additional input used by a cryptographic construction to vary or condition its processing of secret material. Its required properties depend on the construction. In HKDF, the salt is the key input to the extraction HMAC, while the initial keying material is the HMAC message. The salt is normally non-secret, and the specification permits reuse and defines a default when no salt is provided.^[ref]

For HKDF extraction,Fixing both inputs gives a deterministic intermediate key. Changing salt changes the HMAC computation even if the initial material is unchanged. The public salt can therefore distinguish extraction contexts; it does not need to be counted as another secret shared by the participants. The RFC's security discussion also requires attention to how salts are obtained and to adversarial control of inputs.^[ref]

An original counting argument separates public variability from secret uncertainty. Suppose secret $X$ is uniform over $2^{20}$ values and independent public salt $S$ is uniform over $2^{16}$ values. There are $2^{36}$ possible input pairs before either value is known. Once $S=s$ is public, however, only $2^{20}$ candidate secrets remain. For any deterministic derived key $K=f(X,S)$,where $H$ is information entropy and the conditioning uses conditional entropy. Producing a 256-bit key string does not turn that twenty-bit secret source into 256 bits of conditional uncertainty.

The same example shows why per-target guessing and preparing a table for every possible salt are different tasks. A table enumerating every stipulated secret/salt pair would have $2^{36}$ entries, while enumeration for one known salt still has $2^{20}$ candidate secrets. This counts the toy input space, not the cost or guarantee of a particular password-processing scheme.

A salt is also distinct from a cryptographic nonce, whose permitted reuse is specified by the consuming algorithm, and from the expansion context used for cryptographic domain separation. Parameter names alone do not make their requirements interchangeable.

A cryptographic test vector is a specified collection of algorithm inputs, parameters and expected outputs used to check an implementation. Exact byte encodings are part of the vector: a key displayed in hexadecimal represents bytes, not necessarily the displayed characters. A known-answer test compares a computed result with the supplied answer. RFC 4231 provides such vectors for several HMAC instantiations.^[ref]

For its Test Case 1, use a key of twenty bytes each equal to hexadecimal 0b, and the eight ASCII message bytes spelling Hi There. HMAC with SHA-256 must produce

b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7.

The output has 64 hexadecimal digits, hence 32 bytes. The key has twenty bytes; using the forty ASCII characters obtained by writing 0b twenty times supplies a different key. Adding a newline to the message supplies different message bytes too.^[ref]

A good vector identifies the complete algorithm variant. An unkeyed SHA-256 digest of that message is not the expected HMAC result, and SHA-512/256 is a different hash operation despite its equal digest length. HKDF additionally needs its salt, initial material, context and requested output length; its primary specification supplies all those fields together with the expected extraction and expansion results.^[ref]

Passing a vector establishes agreement for those inputs. It does not prove collision resistance, key secrecy or a cryptographic protocol's security. Nor does one short input exercise every implementation path. Vectors covering long keys, truncation and boundary lengths can reveal mistakes that a single example misses; RFC 4231 includes separate cases for those behaviours.^[ref]

HKDF is an HMAC-based key derivation function with extraction and expansion stages. Extraction combines initial material $\mathrm{IKM}$ with a cryptographic salt to produce an intermediate key $\mathrm{PRK}$. Expansion uses that key, context info and an output length $L$. RFC 5869 specifies the construction as an Informational RFC.^[ref]

Writing $\Vert$ for concatenation, its equations areThe output is the first $L$ bytes of $T_1\Vert \cdots \Vert T_N$, where $N=\lceil L/h\rceil$ and $h$ is the digest length in bytes. The counter occupies one byte, giving $L\le 255h$. The first HMAC argument is the key; swapping its two arguments changes the construction.^[ref]

For SHA-256, $h=32$. Requesting $L=42$ therefore requires two expansion blocks, using all 32 bytes of the first and ten of the second. The maximum specified length is $255\times 32=8160$ bytes. Requesting a longer output under that one-byte counter rule is not an additional iteration of the same specification.

RFC 5869 Appendix A.1 supplies a reproducible example: 22 input bytes each equal to hexadecimal 0b, salt bytes 00 through 0c, and info bytes f0 through f9, with $L=42$. The resulting output, written as hexadecimal, is

3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865.

That is 84 hexadecimal digits representing 42 bytes. Each expansion block depends on its predecessor as well as the context and counter; independently hashing the counter would describe a different function.^[ref]

A salt need not be secret, while the derived key material must receive the protection required by its role. Context can distinguish protocol uses through cryptographic domain separation. Neither changing a label nor asking for more bytes supplies additional secret entropy to a weak input.

HMAC constructs a message authentication code from a cryptographic hash function and a shared secret key. For a hash $H$ with input block size $B$ bytes, normalize the key to a $B$-byte string $K_0$: first hash it if it is longer than $B$, then pad with zero bytes. The construction isHere $\oplus$ is bytewise exclusive or, $\Vert$ is concatenation of strings, ipad repeats byte 0x36, and opad repeats byte 0x5c. The inner and outer keyed hashing stages are part of the construction, rather than interchangeable placements of a key beside a message.^[ref]

A concrete interoperability example uses SHA-256, a member of SHA-2. Its block size is64 bytes while its full digest is32 bytes. With a key of20 0x0b bytes and the ASCII message Hi There, the hexadecimal tag is b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7.^[ref]

The receiver recomputes the tag using the shared key and checks the received tag. HMAC authenticates the message without concealing its contents; encryption is a separate operation. Because both parties know the key, both can make valid tags. A valid tag also remains valid when the same authenticated message is sent again, so replay handling belongs to the surrounding cryptographic protocol.

HMAC's original analysis and design are due to Mihir Bellare, Ran Canetti and Hugo Krawczyk.^[ref]

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 known-answer test checks a cryptographic implementation by supplying fixed, completely specified inputs and comparing its output with an independently established expected value. The input and expected output together form a cryptographic test vector; the test is the act of executing the implementation and checking that agreement. Published HMAC vectors explicitly support conformance testing.^[ref]

For example, take the four key bytes 4a 65 66 65, representing Jefe, and the 28 ASCII message bytes representing what do ya want for nothing?. The published HMAC with SHA-256 result is

5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843.

A known-answer test decodes that 64-digit hexadecimal value to 32 expected bytes, computes the keyed result, and compares all 32 bytes. Neither the message's terminating string-storage zero nor a newline is part of these input bytes.^[ref]

Several different errors can cause failure: decoding hexadecimal as text, including an extra byte, using the wrong key, selecting another cryptographic hash function, or serializing the result incorrectly. A failure establishes disagreement with the vector; it does not identify the responsible step by itself. A useful test harness reports the selected function, input lengths and first differing output position.

Passing also has a precise limit. A defective implementation that returns this expected value for this one input and zero for every other input passes this test. Thus a finite set of known-answer tests is evidence about those cases, not a proof of correctness for all inputs or a proof of cryptographic security. Boundary cases complement ordinary short examples: the primary vector set includes output truncation and keys longer than a hash's input block.^[ref]

An independently fixed expected value is essential. Computing the “expected” output with the same implementation under test can reproduce the same defect on both sides. Known-answer tests are especially useful for reproducible checks of exact byte conventions across different implementations.

Magnus Nystrom is a computer scientist working in computer security and cryptography. An ITU-hosted speaker biography uses the spelling Magnus Nyström and describes his work on security architectures, cryptographic protocols and standards at RSA Security. The biography and RFC identify a security specialist of the same name at RSA Security.^[ref]

Magnus Nystrom authored RFC 4231, which supplies identifiers and cryptographic test vectors for HMAC used with several members of the SHA-2 family. This is a practical contribution to reproducibility and interoperability: two implementations given the same key and message should produce exactly the same authentication value.^[ref]

For a concrete published check, Test Case 1 uses twenty bytes of hexadecimal 0b as the key and the eight ASCII characters Hi There as data. The HMAC-SHA-256 output starts b0344c61. A developer must decode 0b as one byte rather than submit the two text characters 0 and b; confusing those representations changes the input.^[ref]

A cryptographic test vector is an exact check of specified behavior. Passing one example cannot establish the absence of implementation errors for every input, and conformance does not itself prove resistance to every attack. The value of a published collection is that its fixed inputs expose disagreements that informal descriptions of an algorithm can leave hidden.

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]

Pasi Eronen is a computer scientist contributing to Internet security and cryptographic protocols. His IETF author record links a series of protocol specifications; RFC 5869's author-contact section gives his full name and a Nokia Research Center affiliation at publication.^[ref][ref]

With Hugo Krawczyk, Pasi Eronen specified HKDF, an HMAC-based key derivation function. It separates extraction of an intermediate pseudorandom key from expansion into output keying material, with cryptographic salt and application context supplied as specified inputs.^[ref]

An original output-length calculation illustrates the design. With SHA-256, each expansion block has 32 bytes. Requesting 42 bytes therefore requires two blocks: all 32 bytes of the first and the first 10 of the second. The one-byte block counter limits expansion to 255 blocks, hence 8160 bytes for this hash. These are construction limits, not claims that a longer output contains more independent secret information than its input.^[ref]

The context input supports cryptographic domain separation. A protocol can distinguish two intended roles by unambiguous labels rather than silently reuse identical derived material. The surrounding cryptographic protocol must still authenticate its parties and provide suitable input secrets; HKDF does not establish those properties by itself.^[ref]

Ran Canetti is a computer scientist whose work in cryptography concerns the design and analysis of cryptographic protocols. His institutional biography records a doctorate from the Weizmann Institute.^[ref]

With Mihir Bellare and Hugo Krawczyk, Ran Canetti developed the HMAC message authentication code. The construction turns a cryptographic hash function into a keyed mechanism for detecting unauthorized message changes; its analysis connects a concrete algorithm with explicit security assumptions.^[ref]

Ran Canetti also introduced the framework of universal composability. It addresses a difficulty that appears when security mechanisms are combined: analyzing one isolated execution does not automatically establish security when many executions interact. His framework provides a composition guarantee for cryptographic protocols satisfying its definitions and assumptions, allowing larger systems to be reasoned about through suitable component guarantees.^[ref]

For motivation, imagine an application running two authenticated conversations at once. An attacker may schedule their messages and attempt to reuse information from one conversation in the other. A proof limited to a single isolated conversation leaves this interaction outside its stated model. Universal composability makes such surrounding activity part of the security question; it does not declare every component secure merely because the component has been called cryptographic. The report began in 2000 and an extended abstract appeared in 2001; the linked full report includes later revisions.^[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.

SHA-224 is a SHA-2 cryptographic hash function producing a 224-bit digest. It follows the SHA-256 computation with a different hash initialization vector and a final output shortened to its first seven 32-bit state words.^[ref]

If the final state words are $H_0,\dots ,H_7$, the digest isThis is $7\times 32=224$ bits, or 28 bytes and 56 hexadecimal digits. The input is still padded into 512-bit blocks, and each block still undergoes the SHA-256 family's 64-round computation. Output width and internal processing width are different quantities.

For a computed example, the ASCII bytes 61 62 63 give

23097d223405d8228642a477bda255b32aadbce4bda0b3f7e36c9da7.

A SHA-256 digest of the same bytes begins ba7816bf8f01cfea. Keeping only its first 28 bytes therefore does not give SHA-224. The algorithm's different initial values are applied before processing any message block.

The same output length also does not make SHA-224 identical to SHA-512/224. The latter uses the 64-bit SHA-512 family structure, a different initial state and a different padding/length-field convention. For instance, a 56-byte input takes two padded blocks in SHA-224 but only one in the SHA-512-based variant. Both results have 28 bytes, so a digest field's size cannot identify which function produced it.

The intended cryptographic protocol must select the hash explicitly. A cryptographic test vector for SHA-224 checks that defined function, whereas an HMAC vector also specifies its key and keyed construction.

SHA-256 is a SHA-2 cryptographic hash function producing a 256-bit digest. It processes a padded message in 512-bit blocks, with eight 32-bit state words and 64 processing rounds per block. The specified additions use modular arithmetic modulo $2^{32}$.^[ref]

Padding is part of the function. For input bit length $\ell <2^{64}$, append a one bit, then the smallest nonnegative number $k$ of zero bits satisfyingthen append the 64-bit representation of $\ell$. This makes the complete length a multiple of 512 bits.^[ref]

For an original byte-count example, the three ASCII bytes 61 62 63 have length 24 bits. Here $k=423$, andThe padded block consists of the original three bytes, byte 80, 52 zero bytes and an eight-byte length field representing 24. The padded input occupies 64 bytes; the final digest occupies 32 bytes. Computing SHA-256 gives

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad.

Adding a newline changes the byte sequence and the digest. Displayed text, its character encoding and its line terminator must therefore be specified when comparing hash values.

The padding boundary is also visible without computing a digest. A 55-byte input fits its padding into one 64-byte block, whereas a 56-byte input requires two blocks because the length field no longer fits. Both still produce a 256-bit output. Digest length is not the padded-message length or a reversible compressed representation of the input.

Finite output size necessarily allows collisions over a larger input set; collision resistance concerns the difficulty of finding them. SHA-256 also supplies the hash operation used inside common HMAC and HKDF instantiations, whose keyed constructions and security properties differ from an ordinary unkeyed digest.

SHA-384 is a SHA-2 cryptographic hash function producing 384 bits. It uses the 64-bit word operations, 1024-bit blocks and eighty-round computation of SHA-512, with its own hash initialization vector. Its result is the first 384 bits of that differently initialized computation.^[ref]

Write its final eight-word state as $H_0,\dots ,H_7$, with each word containing 64 bits. The output iswhere $\Vert$ denotes concatenation. Six words give $6\times 64=384$ bits, or 48 bytes and 96 hexadecimal digits. The computation still maintains eight state words while processing the message; the shorter output does not reduce every intermediate state to six words.

For a computed example using ASCII bytes 61 62 63, SHA-384 gives

cb00753f45a35e8bb5a03d699ac65007272c32ab0eded1631a8b605a43ff5bed8086072ba1e7cc2358baeca134c825a7.

The ordinary SHA-512 digest begins ddaf35a193617aba, so truncating that digest to 48 bytes already disagrees at the beginning. Different initialization, rather than merely a shorter printed result, distinguishes the algorithms.

A streaming implementation can process message blocks using the SHA-512 family machinery while retaining the selected variant's initial state and final serialization. Treating those choices as part of the function is essential when a digital signature or HMAC specification names SHA-384. Changing to another 384-bit output transformation changes the algorithm, even if the receiving buffer still has the expected size.

A transcript hash is a cryptographic hash function applied to the defined encoding of a cryptographic transcript. The included messages, ordering, boundaries and algorithm are part of its definition:In TLS1.3 the inputs include handshake type and length headers but exclude record-layer headers. A retry has an explicit synthetic-message substitution; ordinary payload concatenation is not that protocol's definition.^[ref]

An original ten-byte example uses a deliberately separate toy format: one type byte, a two-byte big-endian payload length, then payload. The first message is 01 00 02 48 69, carrying ASCII Hi; the second is 02 00 02 4f 4b, carrying OK. The SHA-256 digest of these ten bytes in that order is

2cd107ca2c002f392a6c26a4b2ed3caca0c23ecf0d67e3a790e787800caadc19.

Reversing the two encoded messages gives

7efaeb2cd69eae34b41ea8316a104ba7964254bd86e9b9ba14df77bb29163b66.

These are original computations, not TLS test vectors. Both message order and the encoded headers contribute to the input bytes.

Incremental hashing of a cryptographic transcript feeds those byte sequences into one continuing hash context and finalizes at the required point. It computes the same digest as hashing their full concatenation. Computing $H(H(M_1)\Vert M_2)$ is a different operation: the finalized inner digest replaces the first message and introduces its own hashing boundary. A running internal state is not interchangeable with a completed digest.

An unkeyed transcript hash alone does not authenticate who spoke. A digital signature or message authentication code binds it to the required authenticated context. Nor can a hash recover message boundaries omitted by an ambiguous encoder. TLS's Finished message illustrates the separate authentication step by applying HMAC to the specified transcript hash.^[ref]