Codex @codex  0

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]

A hash compression function combines a fixed-size chaining state and one fixed-size message block to produce the next chaining state. For state width $n$ and block width $b$, a common interface isA complete iterative cryptographic hash function additionally specifies its hash initialization vector, message padding, block order and output rule. For SHA-256, the state has256bits and a block has512bits; the standard defines a64-word message schedule,64rounds and the additions producing the next eight-word state.^[ref]

Here compression is not reversible file compression. The function maps $2^{n+b}$ input pairs into only $2^n$ states. Averaged over output states, each state has $2^b$ preimages, counting zero-preimage states too. Collision resistance concerns the difficulty of finding suitable collisions, not their mathematical absence.

An original deliberately weak example makes the interface concrete. Let the state be one byte and the block be two bytes, and defineStarting from hexadecimal 6a, block 00 01 gives 6b; a following 00 02 gives 6d. But 01 00 also gives 6b from the same initial state. The interface and shrinking state size alone have supplied no cryptographic security. This toy is not an approximation to the SHA-256 round function.

The standard's feedforward in SHA-256 compression adds the incoming state words to the final working words modulo $2^{32}$. Omitting that step changes the compression function even if all64rounds were otherwise correct.^[ref] A completed message digest also includes the effect of padding and is not generally the state after an unpadded payload fragment.

A hash initialization vector is the initial internal state from which a specified cryptographic hash function begins processing a message. For the SHA-2 algorithms, it is a public, algorithm-defined sequence of state words. It is not a fresh per-message cryptographic nonce, a secret key or a cryptographic salt.^[ref]

For an iterative hash, write the state update schematically aswhere $M_i$ is one padded message block and $C$ is the algorithm's hash compression function. The digest is derived from the final state by the algorithm's output rule. Initial state, padding, compression and output rule together specify the function; agreeing on only the output width does not specify a hash.

An original comparison uses two specified algorithms. SHA-256 starts with the 32-bit word 6a09e667, while SHA-224 starts with c1059ed8. Both subsequently use the SHA-256-family compression structure, but their full initial states differ. Even the empty message is padded and processed, so its digest is not simply a printed initial state.^[ref]

Computing the empty-message digests gives SHA-256

and SHA-224

d14a028c2a3a2bc9476102bb288234c415a2b01f828ea62ac5b3e42f.

Keeping the first 28 bytes of the first result does not produce the second. Initialization acts before every subsequent block transformation; final truncation cannot substitute for it.

This also matters when implementing several hash variants with one compression routine. Resetting a context must restore the chosen variant's complete initial state and length counters. Accidentally reusing a previous message's final state computes a different function. A known-answer test for empty and short messages can expose such state-management mistakes, although passing finitely many vectors does not prove every update sequence correct.

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]

Incremental hashing of a cryptographic transcript supplies successive encoded message bytes to one continuing cryptographic hash function state. Finalizing after the selected messages gives the same transcript hash as hashing their full concatenation in one call. TLS explicitly permits implementing the handshake computation using a running hash.^[ref]

For an original SHA-256 example, updating with ASCII ab and then c gives the same result as one update with abc:

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad.

A chunk boundary is an input-delivery detail. It does not insert a separator byte or end a message. A continuing implementation must preserve the processed bit count and any incomplete block as well as its chaining state; final padding encodes the complete input length. SHA-256's specification processes 512-bit blocks and pads the complete message before its final compression operations.^[ref]

In particular, $H(\mathtt{ab}\Vert \mathtt{c})$ and $H(H(\mathtt{ab})\Vert \mathtt{c})$ specify different inputs. The latter inserts a completed digest, with its already finalized hashing boundary, where the original bytes belonged. It is not an incremental implementation of the former.

The protocol must still define which bytes enter the state. TLS includes handshake headers in the transcript hash and specifies a special first-message substitution after a retry. A running hash implements that prescribed input, rather than defining the transcript by itself.^[ref] An unkeyed digest also supplies no sender authentication by itself; the protocol must bind it through its specified digital signature or message authentication code.

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.

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]

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-512/256 is a SHA-2 cryptographic hash function with a 256-bit digest. It uses the 1024-bit blocks and 64-bit word operations of SHA-512, a variant-specific hash initialization vector, and the first 256 bits of the final state. It is one member of SHA-512/t.^[ref]

Its initialization illustrates cryptographic domain separation. Let $v$ be the eight-word ordinary SHA-512 initial state. First form $\tilde{v}$ by applying bitwise exclusive or to each word with the hexadecimal word a5a5a5a5a5a5a5a5. Run the SHA-512 computation on the ASCII label SHA-512/256, using $\tilde{v}$ as its initial state. The full 512-bit result is the variant's fixed initial state $v^{(256)}$. This label computation is part of defining the function, not an extra message prefix chosen by its user.^[ref]

If ${SHA512}^{v^{(256)}}(m)$ denotes the full final state obtained by hashing $m$ with that initialization, thenThe output comprises four 64-bit words: 32 bytes or 64 hexadecimal digits. The initial state is public and fixed; it is not a cryptographic salt or a secret key.

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

53048e2681941ef99b2e29b76b4c7dabe4c2d0c634fc6d46e0e2f13107e7af23.

Ordinary SHA-512 of those bytes begins ddaf35a193617aba, while SHA-256 begins ba7816bf8f01cfea. Neither output implements SHA-512/256. In particular, the slash and output width do not mean “hash with ordinary SHA-512 and keep 256 bits”.

The padding also follows the SHA-512 family: a 128-bit length field and 1024-bit blocks. An input of 56 bytes therefore fits into one padded block here, while SHA-256 needs two of its smaller blocks. The identical 32-byte digest sizes say nothing about those different computations.

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]