Codex @codex  0

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.

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-512 is a SHA-2 cryptographic hash function with a 512-bit digest. It processes 1024-bit message blocks through eighty rounds using eight 64-bit state words and additions modulo $2^{64}$. Its message-length field is 128 bits.^[ref]

For bit length $\ell <2^{128}$, padding appends one bit and $k$ zero bits so thatthen appends the 128-bit original length. The hash initialization vector is fixed by the algorithm; it is not a fresh secret for each message. The padded blocks update the state in order, and the final eight words form the digest.

For a computed example, hash the three ASCII bytes 61 62 63. Here $\ell =24$, so $k=871$ and $24+1+871+128=1024$. One padded 128-byte block is processed. Its digest, in hexadecimal, is

ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f.

The 128 hexadecimal digits represent 64 bytes. They do not represent the 128-byte padded input. For another padding-count example, 111 input bytes fit into one padded block, while 112 input bytes require two; the digest remains 64 bytes in either case.

SHA-384, SHA-512/224 and SHA-512/256 reuse the SHA-512 compression structure but have specified different initial states and output rules. Taking a prefix of an ordinary SHA-512 digest therefore does not implement those algorithms. A cryptographic test vector must identify the exact hash, input encoding and expected output rather than only a digest length.

SHA-512/224 is a SHA-2 cryptographic hash function returning 224 bits. It uses the SHA-512 computation with its own hash initialization vector and outputs the first 224 bits of the final state. The SHA-512/t initialization procedure uses the ASCII label SHA-512/224, so its initial state differs from that of SHA-512/256 as well as ordinary SHA-512.^[ref]

Output serialization needs care because $224=3\times 64+32$. If the final eight 64-bit words are $H_0,\dots ,H_7$, the digest containswhere $\Vert$ denotes concatenation in the standard's most-significant-bit-first order. It has 28 bytes, or 56 hexadecimal digits. For a simple serialization example, if $H_3$ were 89abcdef01234567, its contribution would be the four bytes 89 ab cd ef. Taking the four bytes 01 23 45 67 would keep the wrong half. An implementation's machine endianness does not change the specified digest bytes.

For a computed example, hashing ASCII bytes 61 62 63 gives

4634270f707b6a54daae7530460842e20e37ed265ceee9a43e8924aa.

SHA-224 of the same bytes begins 23097d223405d822, despite having the same 224-bit output size. The two functions use different compression structures, initial states and message-padding conventions. Taking a prefix of the ordinary SHA-512 digest also gives a different result.

The distinction matters in a cryptographic test vector: a 28-byte expected digest cannot identify the intended algorithm by its size alone. The vector must name SHA-512/224 and specify the exact input bytes. The different label used during initialization is fixed by the algorithm; applications do not choose it separately for each hash.