Inner and outer processing use different pads
HMAC normalizes a key to the selected hash’s block width and combines it separately with fixed ipad and opad values. The inner hash covers its padded key and message; the outer covers the other padded key and inner result. This defined separation is not an arbitrary single hash.
Long keys are first hashed and shorter ones padded as specified. Block width differs from digest length, so a 64-byte example is not a universal constant for every HMAC instantiation.
References: [1]
Tags and precomputed state have security obligations
A tag can accompany its message while the key remains secret. Using easily guessed password bytes does not become strong key generation merely by naming HMAC, and key updates and purpose separation constrain exposure.
Implementations can precompute keyed inner and outer state to reduce repeated work, especially for short messages. RFC 2104 requires protecting that state like secret keys rather than treating it as an ordinary public performance cache.
Instantiation and truncation must be explicit
Names such as HMAC-SHA-256 identify the chosen hash, not a claim that ordinary SHA-256 itself is keyed. A protocol may specify truncation, but peers cannot independently choose retained bits; shorter tags and the number of verification attempts affect guessing risk.
Historical MD5 or SHA-1 examples are not present-day selection advice. RFC 6151 updates the old MD5/HMAC-MD5 discussion and advises against HMAC-MD5 in new designs. Construction, underlying function, parameters and deployment requirements require separate assessment.