RFC 6234 Quiz (EN)

Q1: What does RFC 6234 itself specify?

Multiple Choice

An A2A draft cites only RFC 6234 as the complete normative definition of SHA-256, HMAC-SHA-256, and HKDF-SHA-256.

A. All three algorithms, including the HMAC key-processing and HKDF extract-and-expand rules B. SHA-256 and HMAC-SHA-256, while HKDF is defined completely in an appendix C. SHA-1/224/256/384/512 and sample code; HMAC and HKDF are referenced to RFC 2104 and RFC 5869 D. Only test vectors; all algorithm processing is implementation-defined

**Explanation:** A: RFC 6234 does not reproduce the full HMAC or HKDF specifications. B: Section 7.1 gives HMAC context and a reference, not a complete HMAC specification; HKDF is likewise external. C: RFC 6234 Sections 1 and 3-6 specify SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512; Section 7.1 points to RFC 2104 for HMAC, Section 7.2 points to RFC 5869 for HKDF, and Section 8 contains sample code for all three families. D: The SHA processing is specified; it is not left to each implementation.

Q2: What must an A2A profile define before hashing a structured value?

Multiple Choice

Two conforming SHA-256 libraries receive the same logical task object, but one implementation hashes UTF-8 JSON and the other hashes a platform object serialization.

A. Nothing; SHA-256 normalizes equivalent application objects before processing B. Only the human-readable field order, because character encoding and numeric representation do not affect a digest C. The exact algorithm, canonical input bytes or bits, and any output-length or truncation rule D. Only how the digest is displayed, because all 256-bit implementations hash structured values identically

**Explanation:** A: RFC 6234 hashes the supplied bit string and does not know application-level equivalence. B: Character encoding, field encoding, and numeric representation all change the input bits. C: RFC 6234 Sections 1, 2, and 4 define algorithm-level input and processing. Canonicalization and truncation are profile choices that must be fixed for interoperable protocol use. D: Display encoding is downstream of the digest and cannot reconcile different hash inputs.

Q3: Where should canonicalization occur before digest verification?

Multiple Choice

A client sends JSON and a SHA-256 digest. A gateway parses and rewrites the JSON before forwarding it. The backend hashes the rewritten bytes, while the client hashed the original bytes. The design intends the digest to authenticate the client's exact request representation.

A. Keep both byte representations and accept either digest if the parsed JSON objects compare equal B. Verify authoritative input bytes before rewriting, or require one canonical representation for signer and verifier C. Let the gateway recompute the client's digest after rewriting because SHA-256 identifies semantic content D. Hash both versions and concatenate the digests so either representation proves the client's intent

**Explanation:** A: Parsed-object equality is a different claim from authentication of the exact client representation. B: RFC 6234 Sections 1 and 4 process a specific bit string. The A2A profile must define which bytes carry the security meaning and preserve or canonically reproduce them at the verifier. C: Recomputing at the gateway changes the party and bytes behind the digest claim. D: Concatenation does not establish which bytes the client authenticated and introduces an undefined construction.

Q4: Does a secret-prefixed SHA-256 construction satisfy an HMAC profile?

Multiple Choice

The A2A profile requires HMAC-SHA-256 for request authentication. One implementation instead computes SHA-256(secret || request-bytes) and passes its own test vectors.

A. Yes, because any SHA-256 input containing a secret is an HMAC construction B. Yes, if local test vectors pass and the secret is at least 256 bits C. It depends only on whether the implementation truncates both outputs to the same length D. No. It is not HMAC; implement the referenced HMAC construction and shared test vectors

**Explanation:** A: HMAC has a defined inner/outer keyed construction; secret concatenation is not that construction. B: Self-generated vectors demonstrate consistency with itself, not conformance to HMAC. C: Equal output length does not make two algorithms equivalent. D: RFC 6234 Section 7.1 points to RFC 2104 for HMAC. The review conclusion follows from the profile's explicit HMAC requirement; RFC 6234 alone does not make a general security judgment about every raw-hash construction.

Q5: Does raw SHA-256 satisfy an HKDF-based key schedule?

Multiple Choice

An A2A design must derive separate request-proof and audit keys from shared input keying material. The profile says HKDF-SHA-256, but an implementation computes SHA-256(input-keying-material) once and uses the result for both purposes.

A. Yes, because using SHA-256 gives the same security semantics as every SHA-256-based KDF B. Yes, if each consumer labels the result after the shared digest has already been computed C. No. Use the specified HKDF extract-and-expand construction with distinct purpose inputs D. No, because RFC 6234 forbids SHA-256 from appearing inside any key-derivation function

**Explanation:** A: Sharing a hash primitive does not make different constructions semantically equivalent. B: A label applied only after one shared key exists does not give the KDF distinct derivation inputs. C: RFC 6234 Section 7.2 points to RFC 5869 for HKDF. The profile must define the HKDF inputs, including purpose separation, and test the resulting construction. D: SHA-256 is commonly the hash used by HKDF; the problem is replacing the named KDF with a raw digest.

Q6: Which digest pipeline preserves the client's A2A proof?

Multiple Choice

A client signs a request digest. A gateway parses and normalizes the request, then sends the backend normalized bytes, the original digest, and an unsigned header saying that client verification succeeded. The backend authorizes the normalized operation.

A. Accept the original digest against normalized bytes because a correct SHA-256 implementation preserves semantic equivalence B. Verify client proof over canonical bytes at the backend, or trust a protected gateway assertion binding the original and normalized request C. Recompute an unsigned digest at the gateway and treat matching output length as continuity of the client's signature D. Keep the unsigned success header but require the backend to run the RFC 6234 sample code over whichever bytes it received

**Explanation:** A: SHA-256 operates on exact input bits and does not preserve application-semantic equivalence across encodings. B: This makes the authenticated representation and verifier explicit. RFC 6234 Sections 1 and 4 supply digest processing; signature verification, assertion protection, request mapping, and authorization come from the composing profile. C: Output length says nothing about who authenticated the normalized bytes. D: Correct sample-code output cannot authenticate an unsigned success claim or choose authoritative request semantics.

US Secure Hash Algorithms

References (URLs)

Q1: What does RFC 6234 itself specify?

Q2: What must an A2A profile define before hashing a structured value?

Q3: Where should canonicalization occur before digest verification?

Q4: Does a secret-prefixed SHA-256 construction satisfy an HMAC profile?

Q5: Does raw SHA-256 satisfy an HKDF-based key schedule?

Q6: Which digest pipeline preserves the client's A2A proof?