Security implications of the key padding in HMAC I just learned HMAC in class.
Keys are zero-padded in HMAC hashing function. 
10 and 1 will be both transformed into the same final key (e.g. 1000).
Isn't that a problem?
Ordinarily, the keys for a MAC algorithm are assumed to have a fixed length.  (If they don't, e.g. if the "keys" are actually user-supplied passwords, then you should run them through a suitable KDF anyway.)  When HMAC is used that way, there is no problem, since the padding process cannot map two keys to the same output.

(If the input keys are longer than the hash input block length, HMAC specifies that they are to be hashed before padding.  In this case, two keys can end up getting hashed to the same value, but actually finding two such equivalent keys is as difficult as finding a collision for the hash function.  The hashing step does reduce the effective keyspace size of HMAC to the hash output length; that's only an issue insofar as it makes a brute force key recovery attack as easy as a single brute force MAC forgery.  But for normal applications of HMAC, the latter is already considered a break, and thus the hash output size should be chosen to make it infeasible.)

That said, precisely because of its flexibility and its strong security properties (PRF-ness), HMAC is not only used as a generic MAC, but also for other purposes such as, notably, as a component of password-based KDFs like PBKDF2.  In such uses, the key padding (and hashing) in HMAC could cause issues if one isn't careful:


For keys longer than the hash input block size, $k$ and $H(k)$ are equivalent HMAC keys.  This could be an issue e.g. in a carelessly designed application that used $H(k)$ as a key check value, and thereby revealed it to attackers.
Conceivably, a lazy application designer could be tempted to take advantage of HMAC's flexible key length and derive auxiliary keys from a master key simply by appending various suffixes to it.  In such a case, using two suffixes of different length (including, possibly, the empty suffix) that only differed by the longer one having one or more null bytes appended to it could potentially yield equivalent subkeys.
Similarly, when HMAC is used for password hashing (e.g. as part of PBKDF2), two passwords that only differ by appended null bytes would be equivalent.  Of course, people rarely use (or even allow) null bytes in passwords, and anyone who does is likely to run into bigger problems anyway (like the fact that many systems may store user input as a null-terminated string, effectively truncating it at the first null byte).  And even if someone did somehow end up using such an equivalent null-padded password, the security implications would be essentially the same as if they'd simply reused the original password.


In practice, all of these issues are easily avoidable simply by being aware of them and not doing silly things like using null bytes in passwords or in subkey suffixes.  The real problem with HMAC's key padding scheme is simply that it presents a subtle trap for careless cryptographers, and requires anyone analyzing HMAC-based schemes to be aware of its internal structure.  It would be nicer and simpler if we could just treat HMAC as an ideal black-box PRF, but alas, due to the possibility of equivalent keys, that's not quite the case.