When using HMAC, does key encoding matter? Given:


H is a good hash function with block size L.
K is a key of length >= L (recommended by RFC 2104).
Khex and Kbase64 are ASCII encodings of K.


In the HMAC algorithm, is there a good reason to prefer K over the other encodings?

Obviously the HMAC algorithm would consider these distinct keys of different lengths, and keys over length L are hashed, but the way HMAC works I don't see why using K would increase the security of the MAC.
The theoretical problem with using text encoded keys, is that it doesn't necessarily conform with how the keys are assumed to be formatted in security proofs such as this one. If you are using HMAC with an underlying hash function that is still believed to meet the requirements of a cryptographically secure hash function, such as the SHA-2 family of hashes, this shouldn't be a problem. The collision resistance assumption of those hashes should be enough to make your alternative scheme no less secure than conventional HMAC.

However, technically, using keys with special formatting might be a problem e.g. if you are using HMAC-h with a broken underlying hash function h, such as SHA-1 or MD5. Both of these two algorithms are based on simple operations such as bit-wise logical operators, addition modulo $2^{32}$ and shifts and rotates. Considering that both hexadecimal encoding and base64 encoding results in octet strings with the high bit of each octet consistently zero, it wouldn't be completely unrealistic that HMAC-h with $K_{hex}$ or $K_{base64}$ might get broken before (or after) HMAC-h with $K$ selected uniformly from $\{0,1\}^k$.