I have three questions:
- Would you use HMAC-SHA1 or HMAC-SHA256 for message authentication?
- How much HMAC-SHA256 is slower than HMAC-SHA1?
- Are the security improvements of SHA256 (over SHA1) enough to justify its usage?
$\begingroup$
$\endgroup$
3
-
2$\begingroup$ #2 if you are not a service performing millions of hashes, both of them should take a miniscule fraction of a second (for a reasonably small message). $\endgroup$– Richie FrameApr 4, 2014 at 1:49
-
$\begingroup$ #1) I would make my protocols generic enough that I could easily swap out the cipher-spec. $\endgroup$– mikeazoAug 17, 2015 at 14:08
-
2$\begingroup$ Hashing speed depends on hardware. You should also consider SHA512. If you only need to support 64 bit CPUs and most messages are 120 bytes or longer, then SHA512 will be faster than SHA256. If you need to support a mixture of 32 and 64 bit CPUs or if most messages are 55 bytes or shorter, then SHA256 will be faster than SHA512. $\endgroup$– kasperdMar 27, 2016 at 15:05
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
1
Would you use HMAC-SHA1 or HMAC-SHA256 for message authentication?
Yes.
That is a semi-serious answer; both are very good choices, assuming, of course, that a Message Authentication Code is the appropriate solution (that is, both sides share a secret key), and you don't need extreme speed.
How much HMAC-SHA256 is slower than HMAC-SHA1?
Those sorts of crypto performance questions are quite platform specific, and so it's hard to answer definitively. In my experience, I've seen SHA-1 (and hence HMAC-SHA-1) be about 30% faster than SHA-256; Your Mileage May Vary, of course.
Of course, the obvious comeback is "how much is this performance delta important to you?". That rather depends on how fast you're adding/checking integrity tags.
Are the security improvements of SHA256 (over SHA1) enough to justify its usage?
To the best of our knowledge, there is essentially no security difference between HMAC-SHA256 and HMAC-SHA1; with a sufficiently long key, both are impervious to brute force, and with a reasonably long tag, both will catch any forged messages with the expected probability. There is a known weakness to SHA1 that allows someone to compute a collision in less time than expected; there is no known way to apply that to HMAC-SHA1, and so there are no known methods of attack (other than, as I mentioned just now, brute force, and guessing the tags randomly).
-
$\begingroup$ Addendum. In section 6 of the HMAC specification it explains the unfeasibility of the currently best known attack. And HMAC calls the hash function only two times so the speed is pretty negligible. As for the output size, that may be a factor especially if you're sending hashes over a network. However, it's also acceptable to truncate the output of the HMAC to a certain length. So really, choosing between SHA1 and SHA256 doesn't make a huge difference. Might as well stick with SHA1. $\endgroup$ Apr 4, 2014 at 1:05
$\begingroup$
$\endgroup$
0
I would use HMAC-SHA256.
While poncho's answer that both are secure is reasonable, there are several reasons I would prefer to use SHA-256 as the hash:
- Attacks only get better. SHA-1 collision resistance is already broken, so it's not impossible that other attacks will also be possible in the future.
- It allows you to depend on just one hash function, which you can also use in signature algorithms etc. where collision resistance is required.
- You don't have to justify using a broken primitive. ("I heard SHA-1 is broken?")
The only potential downside is performance, but it's probably not significant in most HMAC use cases, since where performance is important you can find even faster MACs to use instead. So I would consider the above reasons sufficient in most cases to justify using SHA-256 as the HMAC hash.
