I am implementing hmac-sha-512 in an integrated system. However, one subsystem is only supports the use of 256-bit keys.

I read in https://www.rfc-editor.org/rfc/rfc4868 that:

However, note that [HMAC] strongly discourages a key length less than the output length. Nonetheless, we describe handling of shorter lengths here in recognition of shorter lengths typically chosen for IKE or IKEv2 pre-shared keys.

And also:

These key length restrictions are based in part on the recommendations in [HMAC] (key lengths less than the output length decrease security strength, and keys longer than the output length do not significantly increase security strength), and in part because allowing variable length keys for IPsec authenticator functions would create interoperability issues.

In what way does using a 256-bit key rather than a 512-bit key with HMAC-SHA-512 decrease its security strength? Is it not advisable to proceed with a 256-bit key?

  • $\begingroup$ Think of it this way: using a 256-bit key when it expects a 512-bit key is like letting the world know half of your key. Using a half-strength key may still be plenty strong in practice, but it clearly shouldn't be the recommended norm. $\endgroup$
    – Mr. Llama
    Sep 20 '18 at 23:58
  • 1
    $\begingroup$ I think the general answer is that HMAC-512 with a 256-bit key means you're lowering your security to the level of the 256-bit key, so you're spending CPU cycles on this 512 hash and not getting the full benefit out of it. However there are some subtleties here, so I've flagged this question to be migrated to crypto.SE $\endgroup$ Sep 21 '18 at 0:02
  • 1
    $\begingroup$ I am pretty sure that basically you'd get 256 bit security for a 256 bit key. The HMAC construction is pretty sturdy and resists quite a bit of abuse. If your runtimes support it you can simply choose the lesser known SHA-512/256 hash and sidestep the issue (this - security wise - is the same as using SHA-512 with a 256 bit key which kind of proves the above without really doing so). Obviously there is no need for a 512 bit security strength; 256 bit is more than enough. $\endgroup$
    – Maarten Bodewes
    Sep 21 '18 at 10:40
  • $\begingroup$ Do you care about attackers willing to dedicate a dyson sphere to cracking your crypto? $\endgroup$ Sep 21 '18 at 11:01
  • 2
    $\begingroup$ Using "only" 256 bits with HMAC/SHA-512 means that it could be broken by a 2nd-tier deity like Hermes or Dionysus, without having to refer to Zeus himself. Against puny mortal humans, though, it should be fine. $\endgroup$ Sep 21 '18 at 13:13

In what way does using a 256-bit key rather than a 512-bit key with HMAC-SHA-512 decrease its security strength?

It doesn't, in any real sense. With a 256 bit key, it can be broken by searching through a key space of size $2^{256}$; a simple computation on the energy required to do such a search shows that it is ludicrous (and is the source of the 'Dyson Sphere' comment made by CodesInChaos).

If we assume that the attacker had a working reliable Quantum Computer, he could, in theory, attack the system by performing $O(2^{128})$ HMAC-SHA512 evaluations, which is still not very practical, but not nearly as ludicrous. However, to achieve such a 'low' number of computations, he would have to perform those computations serially (which would extend the total time taken to do the search to something longer than the current age of the universe). Yes, he could speed things up by using multiple parallel Quantum Computers, but it turns out that drastically increases the already huge number of evaluations required.

There is no known way to attack the system with any less effort; hence the system is quite secure against any even remotely plausible attacker.

  • $\begingroup$ This is obviously correct. I was however hoping for an answer that went into the HMAC / hash construction and discuss in detail why it would be secure (in the sense that only brute force is possible). This is an answer that I could have written :P $\endgroup$
    – Maarten Bodewes
    Sep 22 '18 at 20:16

Your Answer

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