After some digging around in the HMAC spec I found this (paraphrased):
Step 1: If the length of Key equals the block size of the hash function (512 bits/64 Bytes for SHA-256), set the key equal to the key. Go straight to step 4.
Step 2: If the length of key is greater than the block size of hash function, hash the key to obtain a string the same length as the hash function output, then append 0s up to the length of the Block Size.
Step 3: If the length of key is less than the block size of the hash function, append 0s to the end of the key so that the key length is now the same size as the block length.
So if you input a 512 bit key of:
Then it will be untouched. If however you add at least one Byte to the end e.g. 'aa', the key now becomes:
Or if you have less than the block size, perhaps a 256 bit key of:
Then it now becomes:
It would seem that the more secure way to use HMAC would be to input a key that is exactly equal to the block length of the cipher being used, which for SHA-256 would be 512 bits. This must give full 512 bit diffusion of the key into the HMAC. Otherwise HMAC will turn at least half of the key to zeros.
I did a bit more reading and found that the there is an NMAC spec which is similar to HMAC but requires two independent random keys:
NMAC = H(k1 || H(k2 || m)).
What is the security impact of having at least half the key as null Bytes in HMAC (which would happen in the majority of cases, unless care was taken to specifically choose key sizes the same length as the block size)?
In general, which is the more secure construction, HMAC or NMAC? Given that the spec for HMAC seems to not use two independent random keys, but derives the inner and outer keys from the main key, and also weakens the main key in the first 3 steps.
If I had a key longer than the block length of the hash function, would it be stronger to use the NMAC construction instead of HMAC? Perhaps by splitting the full random key in half to use as k1 and k2. For example, I have a random 768 bit key, I split that into two 384 bit keys then use that with NMAC. Under HMAC that 768 bit key would be reduced to 256 bits psuedo random concatenated with 256 bits of 00000000000000000000... In this case I think NMAC would be more secure, correct?
I know HMAC is designed specifically for the Merkle–Damgård type hashes, but can Keccak (sponge construction) be used with HMAC? Or is it better to use it with the NMAC? Or simply do H(k || m) as the Keccac authors intended? Length extension attacks are no longer an issue for Keccak.