[loeg]

> It's also super simple: It's almost literally just concatenating the secret and the message you want to authenticate together, and take an ordinary hash (like SHA256) of that, the rest of it is just to deal with padding.

It's not quite as simple as that. The output of the first hash is hashed a second time (to prevent length extension attacks).

[anyfoo]

Thanks, forgot to mention that. Needless to say, I always consult real cryptographers when working on stuff like that.

[loeg]

Do you ever need to implement an HMAC from scratch? I'd look for an off-the-shelf solution before trying to find a cryptographer.

[anyfoo]

I don't, and I absolutely did not mean to imply that anyone should implement HMAC themselves. I was addressing people who want to potentially use HMAC (after proper consultation with cryptographers), for which a general understanding of HMAC is prerequisite. Hence why my original comment only described implementation on a surface level, but elaborated over potential uses for HMAC.

Only cryptographers should implement crypto primitives. Even if I'd get the algorithm itself right, I might not know how to make it so that it runs in constant time (which is something that crosses into the CPU's ability to do so), and thus may inadvertently leak secrets through side channels.

But even if I just use HMAC, I still consult with cryptographers to make sure my use is correct, that there is no better solution, and that I am not missing any attack vectors.

Even in simple cases it can be a grave mistake to use seemingly simple crypto primitives without proper consultation, see for example some of the very prominent problems that were the result of improper IV usage with AES.