Addressing problems with OTP for HMAC:-
By using OTP material for the HMAC key, you create a denial of service (DoS) vulnerability in that an attacker can swamp your input with fake packets that all have to be authenticated draining your key store. If done automatically without your noticing, such would form an ersatz kill switch. OTP consuming Universal hashing does not eliminate this vulnerability. Whilst generating key material for text sized OTPs is easy, you then are forced to re-sync them with the other actors. This may involve face to face meetings depending on your security position and level of skepticism.
Your construction does not have two factor authentication and that’s poor form with OTPs. All OTP material has to be stored (what you have). If it’s also used for authentication, it’s stored too (what you have). There is no opportunity for authentication via what you know. Thus if I somehow access your key store, I can become you.
Your construction does not have two factor authentication and that’s poor form with OTPs. All OTP material has to be stored (what you have). If it’s also used for authentication, it’s stored too (what you have). There is no opportunity for authentication via what you know. Thus if I somehow access your key store, I can become you.
I suggest these problems swamp the issue of ”key size is larger than the output of the hash.” Mitigation can be had by exploring your faith in NSA, NIST, Quora, this and other forums and academic papers. Some say that contemporary hash functions used for HMACs are secure. If you believe so, a key correctly derived from a password would create exactly the same security level as current protocols like AES + HMAC. And that would provide two factor authentication nullifying the DoS vulnerability. If not, it would be interesting to see reasoned arguments dissuading simple use of any CRC/hash function masked by OTP material.