HMACSHA256 2.5 times faster than HMACSHA512

Question

According to the answers to a previous question, the 512 version should be faster on x64 devices. And even if it were executed on an x86 (32 bit) device - there shouldn't be such a big difference.

Is there some explanation for this difference? (Or must it be an implementation issue.)

The following code returns almost 5 seconds for the HMACSHA512, and almost 2 seconds for HMACSHA256: (It's run on a Samsung J5 (2015) which has a Snapdragon 410 Processor with "CPU Bit Architecture 64-bit". Using Xamarin.Forms PCL, the Droid project.):

private void Button_Clicked(object sender, EventArgs e)
{
    ICrypto crypto = DependencyService.Get<ICrypto>();
    Stopwatch watch = new Stopwatch();

    byte[] b = new byte[64];
    watch.Start();
    for (int i = 0; i < 10000; i++)
    {
        b = crypto.CalculateHmac512(b);
    }
    watch.Stop();
    label.Text = watch.ElapsedMilliseconds.ToString();
}

And

class Crypto : ICrypto
{
    //HMACSHA256 hmac = new HMACSHA256();
    HMACSHA512 hmac = new HMACSHA512();

    public byte[] CalculateHmac512(byte[] m)
    {
        return hmac.ComputeHash(m);
    }
}

(On a 64 bit PC for 100,000 iterations I get around 200ms for 512, and around 130ms for 256. So I guess that Xamarin itself is 32 bit. But that still doesn't explain the x2.5 difference on Android.)

Answer 1

SHA-512 internally hashes blocks of 128 octets, versus 64 for SHA-256. That can give a speed advantage on 64-bit CPUs in term of octets hashed per second, but only for large messages. I'd try 8192 where there is 64, and 200 where there is 10000.

---

The SHA-512 compression function typically requires significantly more time than that of SHA-256: structure is close, with variables twice the size, and there are 80 rounds versus 64 (25% more). There's also about twice as much data moved, and that typically incurs some penalty. However the time required overall can be less than twice as much, and since twice as much message is hashed, there can be some benefit overall for large message.

The question compares HMAC-SHA-512 to HMAC-SHA-256. The HMAC construction adds at least 3 compressions (more so for long keys) compared to a straight hash, which further increases the message size threshold before the 64-bit version can have an edge. With a 64-octet message, HMAC-SHA-512 performs 4 compressions, and HMAC-SHA-256 performs 5 (320 rounds for both). For a 8192-octet message, that goes 68 vs 132 compressions (5440 vs 8448 rounds), which gives HMAC-SHA-512 a chance.

Also, speed of algorithms, especially crypto, depends a lot on the quality of their implementation and how well it is tailored to the hardware at hand. From where we stand, we can't even tell if HMACSHA512 or HMACSHA256 are native code, Just-In-Time-compiled, or interpreted. Benchmarking anything but native code is both rather pointless (if performance really matters, the critical section should be native) and harder (results tend to be unstable).