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]

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]

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.