3
$\begingroup$

Long question but I am starting to lose sight of all the HASH algo's there are.

I know SHAKE128 and 256 are part of the SHA-3 standard but is the SHA3 standard officially released yet? i can only find a draft of the publication, does this mean it's not official and therefor not proven to be secure?

I have not found a proper SHAKE128 or 256 c implementation which is why i'm wondering if they should be used yet, because if they were good I'd think there'd be a lot of example code for them.

I know SHA-1 has a theoretical attack which comes close to being practical and obviously MD5 is broken which is why i would like to keep away from those.

Then SHA-2 remains but SHA-2 contains sha 224, 256, 386 and 512. I've tested these (and whirlpool and Tiger) on my test device and this was the speed:

HMAC        bytes   speed μs
Sha1        64      746
            128     857
Sha224      64      918
            128     1066
Sha256      64      918
            128     1066
Sha384      64      2395
            128     2840
Sha512      64      2400
            128     2840
Sha512_224  64      2390
            128     2835
Sha512_356  64      2390
            128     2835
MD5         64      308
            128     345
Whirlpool   64      5630
            128     6420
Tiger       64      832
            128     952

So MD5 is fastest followed by SHA-1 but those i would like to evade. Now Tiger is the 3th fastest followed by SHA 224 and 256.

I do know that having an insecure HASH does not necessarily mean your HMAC is insecure but still, I always lock my car even though no one has the key.

So the question: what is the best hash to use, obviously it needs to be relatively fast and by my standards sha-512 isn't fast (enough).

$\endgroup$
3
  • 1
    $\begingroup$ There are only two significant SHA-2 variants, SHA-256 and SHA-512. All the other variants only differ by truncation and have different IVs. $\endgroup$ Mar 23 '15 at 14:18
  • 2
    $\begingroup$ BLAKE2b is faster than MD5 and SHA-1 on modern 64-bit systems and has a native keyed hashing mode that is a suitable equivalent for HMAC. That said, HMAC's security proof only requires the compression function to be a PRF. While MD5 is broken and SHA-1 is likely not far behind, none of their broken properties are relevant to HMAC. HMAC-MD5 and HMAC-SHA1 are still unbroken (albeit distasteful). $\endgroup$ Mar 23 '15 at 15:59
  • 1
    $\begingroup$ SHAKE is not at all appropriate for HMAC use, and SHA3 in general is not really designed for use with HMAC $\endgroup$ Mar 24 '15 at 6:50
8
$\begingroup$

I know SHAKE128 and 256 are part of the SHA-3 standard but is the SHA3 standard officially released yet? i can only find a draft of the publication, does this mean it's not official and therefor not proven to be secure?

No, SHA-3 has not been formally approved. On the other hand, what do you mean "not proved to be secure"? Do you really thing that NIST approves only things that are "proven"? In practice, we have only a handful of things that are "proven" (OTP, secure sharing); while NIST certainly tries to vet what they place on the approved list, they have no proof.

In any case, from your questions, it appears that you are interested in speed. Now, SHA-3 is actually slower in software than SHA-2 (what SHA-3 excells at is if you can implement it with hardware gates); hence it would appear to be the wrong direction for you.

What is the best hash to use, obviously it needs to be relatively fast and by my standards sha-512 isn't fast

Well, before I get into that, I would like to point out that your HMAC implementation can likely be improved.

In HMAC, as you know, we use the key to generate an IPAD and an OPAD; we then compute $a = Hash(IPAD | Message)$, and then compute $b = Hash(OPAD | a)$, and $b$ is the result of the HMAC.

Now, IPAD and OPAD are sized to be precisely 1 Merkle-Damgaard block of the hash function; hence one thing you can do is you can compute the initial hash compression function evaluation $Compress(IV, IPAD)$ and store that intermediate state; similarly, you can compute the initial hash compression function evaluation $Compress(IV, OPAD)$ and store that.

Then, to compute $a = Hash(IPAD | Message)$, you can restore the initiate state for that, and just compute the hash over the message (just using the precomputed evaluation as the IV, and adjusting the final padding to account for the longer message); similarly, you can use the same trick when computing $Hash(OPAD | a)$.

This allows you to compute HMAC using two fewer hash compression operations over the naive method. Now, if you are computing the HMAC only once for a key, or if you are computing HMAC over a huge message, this doesn't help much. However, if you are computing HMACs over a number of tiny messages, this helps a lot.

I suspect you aren't using this optimization, because if you were, the time differential between 64 bytes messages and 128 byte messages would be considerably larger.

Implementing this may have the time taken to HMAC a 64 byte message on SHA256 by 40% (3 hash compression operations rather than 5).

Now, as for the "best hash"; well, if you want to stick with NIST approved operations, the fastest alternative is HMAC-SHA1 (which is FIPS approved still); if you don't care for that, well, the best you have is HMAC-SHA256.

$\endgroup$
3
  • $\begingroup$ To be honest i do not know if the code I am using does that. but i believe it does. But that might be a question for stackoverflow. $\endgroup$
    – Vincent
    Mar 23 '15 at 15:19
  • $\begingroup$ @poncho maybe update now that SHA3 is released? $\endgroup$
    – Legorooj
    Dec 30 '19 at 23:08
  • 1
    $\begingroup$ @Legorooj I've added an answer updated for SHA3 and more recent development. $\endgroup$
    – DannyNiu
    May 23 at 6:08
3
$\begingroup$

It depends.

If you have full control over the whole system, all components and can use whatever algorithm you want to deploy, you can stick to the one giving you the best efficiency which fulfills your security requirements. In this case, it would be Tiger. However, Tiger has a 192 bit output. If that is not enough for you, go for SHA256.

However, if the availability of the hash function is an issue (e.g. has to be supported in web browsers), and you (with good reason) excluded MD5 and SHA-1, then SHA256 would be the obvious choice.

In general, sticking to SHA-256 today is quite okay for most non-critical systems. It is fast, widespread and has been the target of a lot of cryptanalysis. If for some reason the hash is considered too short, going to SHA-512 is probably your next best candidate.

$\endgroup$
2
$\begingroup$

What is the best hash for HMAC?

The answer is: for the best interoperability, security, and efficiency, HMAC is best instantiated with SHA256 as HMAC-SHA256.

Let me explain.

History

HMAC was first proposed in the paper "Keying Hash Functions for Message Authentication" by Mihir Bellare, Ran Canettiy, and Hugo Krawczyk in 1996, as a construction that turns a cryptographic hash function into a message authentication code.

The reasoning of the construction is based on the then fact that almost all hash functions were based on the Merkle-Damgaard paradigm and built from compression functions. The security proof of the construct however, is independent of the underlaying construction, and is only dependent of commonly assumed security properties of cryptographic hash functions.

The SSL protocols back then used ad-hoc constructions to assure the integrity and authenticity of the message communicated. This is why the need of standardized hash-based MACs are apparent and urgent.

Modern Days

Since the NIST SHA-3 competition and the development of newer SSL/TLS protocol versions, understanding of hash function design and symmetric-key cryptography had grown a lot.

First, encryption algorithms begin to incorporate MAC as part of the algorithm design, along with other inputs such as AAD, IV, in an AEAD design paradigm.

Second, the SHA-3 competition had successfuly saught hash function designs that are immune to length extension attack. This made constructing MAC functions directly from the underlaying primitive (and not generically as had been done with HMAC) more efficient.

For example, SHA-3/Keccak now has a KMAC specified in NIST-SP-800-185, the successor to BLAKE - the BLAKE2 hash functions can take additional input such as key and salt prior to hashing the message.

However, in Real World

To preserve interoperability, optional components should be kept minimum to ease real-world implementations. This is why you don't find newer MAC functions being included in protocol (e.g. TLS-1.3), format (e.g. Json Web Token), and API (e.g. WebCrypto) standards.

HMAC-SHA256 provides a maximum 256-bit security when the key is properly generated, and may be truncated as needed. While SHA-512 and SHA-384 perform faster on 64-bit architectures, not all devices in your system are necessarily 64-bit, and it's too much of an overkill. The truncated versions SHA-512/256 isn't always available.

Also, SHA-256 had received instruction set support on x86 and ARM architectures, where as SHA-512 hasn't.

I don't recommend SHA-224 largely due to lack of available implementations (e.g. missing in C# System.Security.Cryptography namespace), and also because it's actually added after the initial 3 variants SHA-{256,384,512} were introduced, for the sole purpose to match the 3-DES 112-bit security, as such, it's not very meaningful.

That's why, I made the recommendation at the beginning of this answer.

$\endgroup$
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.