Normalize a key to the hash block size

Hash a key only when it is longer than B, then pad the result to exactly B bytes.

• B is the underlying hash compression-block length in bytes; L is its digest length. The generic construction does not require B=L. Our SHA-256 example has B=64 and L=32; RFC 4231 §§4.2,4.4,4.7 provide the corresponding SHA-256 examples. These are chosen parameters, not values for every hash.
• If the original key is longer than B bytes, first hash it with H and use that L-byte result as the effective key. Otherwise use the original key unchanged. Then append zero bytes to make a B-byte normalized key block, called K0 in this guide (§2). K0 is explanatory notation, not an extra transmitted field.
• The public 20-byte test key needs44zero bytes to fill B=64. An illustrative64-byte key needs no initial key hash and no appended zero bytes. The equality boundary matters: a key of exactly B bytes is not hashed first.
• RFC 4231 §4.7 uses131 bytes of aa as the public long-key test. For SHA-256, hash all 131 bytes to32 bytes, then append32 zero bytes. Hashing the first 64 bytes only, cutting the key off, or hashing every short key would change the algorithm.
• Held for Document Update erratum4809 proposes forbidding long keys. It is not a verified correction; the published long-key normalization remains the algorithm. The normalized long-key digest is effective secret key material, not a safe public fingerprint. Neither a public test key nor a human password is a recommended source of HMAC key entropy (§§2–3).