In a custom protocol we want to replace an aged tiger32 based challenge response authentication. I suggested that we use something existing, so threw HMAC into the room. As per wikipedia it works as:
$\textit{HMAC}(K, m) = H \left( (K \oplus opad) | H((K \oplus ipad) | m)\right) $
where $m$ would be the nonce. Now The Architect™ suggested "Let us put a few more nonces in there, more randomness does not hurt." and came up with this:
$\textit{HMAC}(K, m_{0..4}) = H \left(m_0 | (K \oplus opad) | m_1 | H(m_2|(K \oplus ipad) | m_3)|m_4\right) $
Although I could not see anything immediately wrong with it, my reply was "We are no cryptographic experts, let us stay with something that has proven to be good in real world applications already."
So we are kind of still arguing and now need input of cryptographic experts. The two main questions here that arise are (Always under the assumption that key, nonce and hash are sufficiently good):
- In this specific instance, will adding those nonces hurt security? That is, will it make authenticating without knowing $K$ any easier, or will it make recovering $K$ from intercepted traffic any easier?
- For the general case, if possible, will in similar situations ("hashing stuff for authentication") adding nonces always make things better, or are there situations to be aware of were adding them could make things worse?