9
$\begingroup$

First of all, I know that this all it's very complicated, I know that CPUs are complex beasts, and may not work at their full potential all the time, they can have more than one core, and the calculations may very well be reordered, optimized, or vectorized, there are different cryptographic libraries, etc.

However, I need a simple, straightforward formula, very approximate formula for calculating the time taken by the encryption algorithm on a specific CPU. For simplicity, let's consider 2 situations:

  1. CPU has 1 core, and 2.8GHz, algorithm is AES-128-CBC, data size to encrypt is 1024 MB
  2. CPU has 4 cores, operations are ordered hypothetically as they "should be", algorithm is AES-128-CBC, data size to encrypt is 1024 MB

I know that 1Hz means 1 second, and a CPU that has 2.8GHz performs about 2.8 billion operations per second (which means 2.8 billions cycles per second). I also know that:

$$ \text{cycles per byte (CpB)} = \frac{\text{cycles per second (CpS)}}{\text{speed (S)}} = \frac{2.8GHz}{\text{speed (S)}}$$

and, of course:

$$ \text{time (T)} = \frac{\text{data size (DS)}}{\text{speed (S)}} = \frac{1024 MB}{\text{speed (S)}}$$.

But I don't have the speed (bytes per second), and also, even if I had one, how to calculate time needed by encryption? I mean, I only have data size (DS) and cycles per second (CpS), but it seems I still need bytes per second (BpS) or cycles per byte (CpB), and of course, time (T).

I know that the best way is to do the actual measurement, but I need to make some assumptions about the hardware I don't have, and I need some encryption time for those devices (approximate time of course).

How can it be calculated? Are the information I have enough? What else do I need to calculate the time needed by AES-128-CBC to encrypt 1024 MB of data on 2.8GHz CPU?

Improve this question
$\endgroup$
5
  • 2
    $\begingroup$ Note: On modern (superscalar) CPUs, there may be more than one instruction being processed per cycle. $\endgroup$
    – SEJPM
    Sep 12, 2016 at 11:07
  • $\begingroup$ Do you have any assumptions about cache? $\endgroup$
    – b degnan
    Sep 12, 2016 at 12:28
  • $\begingroup$ note; A program if compiled correctly to target a specific cpu instruction' set, it can make a huge difference. An example in form of a benchmark that test the mathematical's processor $\endgroup$
    – yagmoth555
    Sep 12, 2016 at 13:56
  • $\begingroup$ @bdegnan: I dont have any assumptions about the cache. You can assume whatever you want. $\endgroup$
    – yak
    Sep 19, 2016 at 14:01
  • $\begingroup$ @yak You need some real constraints. Bus access is the limiting factor in non-custom implementations, so if you make the assumption that all data must flow and flow out from memory, the calculation is the time it takes to move that 1024MiB down the bus twice. The AES math can easily be completed in the time it takes for the 300MHz DDR4 bus cycle, which would give you 19200 MiB/sec if that's all you did. I can write to cache much faster than that, thus: you need to have some assumptions if you want to use cache. $\endgroup$
    – b degnan
    Sep 19, 2016 at 15:43

1 Answer 1

Reset to default
5
$\begingroup$

The speed depends a lot on the exact model of the processor, and on the software. New(-ish) processors with hardware support for AES are much faster than older processors without it (AES-NI in x86 processors) and an optimized implementation might be quite different from a generic one, especially if the latter doesn't even use the hardware support...

For older processors (without hardware support), some speed tests can be found here. The best numbers for Core 2 family processors were around 12 clock cycles per byte for CTR mode, which would make for about 230 MB/s at 2.8 GHz. For newer processors with AES-NI support, some numbers here, ranging from 600 MB/s to 1500 MB/s per core for CBC mode and 700 MB/s to 2600 MB/s for GCM mode with processors from 2010 to 2015 (with various clock speeds).

(A quick and dirty test with the OpenSSL command line tool on a low-end Xeon processor from around 2012 gave figures in the same ballpark as in the previous link.)

Note that if you care about speed, it seems you shouldn't be using CBC mode. For many processors on the list (as well as the one I tested on), AES-128-GCM is quite a bit faster than AES-128-CBC. And that's without any authentication in addition to CBC encryption. I assume the reason is that CBC encryption is inherently linear: encrypting a block requires the ciphertext of the previous block. This will limit the number of parallel operations the processor can do. For the same reason, multiple cores will not help in encrypting a single, long, chain. The authentication part of GCM encryption is also fast, because there's special hardware support for that, too. (the CLMUL instructions)

Improve this answer
$\endgroup$
4
  • $\begingroup$ I see. It seems a bit clear now. But, I do not understand one thing. How did you calculate the speed from cycles per byte and clock speed? When you do $$ \text{12} = \frac{2800000000}{speed}$$ the speed is then equal to $$233 333 333,333$$ - but how did you manage to change it to MB/s? I know it may be a bit silly / stipud question, but I really do not get it. Thanks! $\endgroup$
    – yak
    Sep 13, 2016 at 22:39
  • 1
    $\begingroup$ @yak, "cycles" of course means clock cycles, and clock speed is just cycles per second. If you look at the units in that equation, the result just drops out as bytes per second: $$ {2800*10^6 cycles/s \over 12 \space cycles/B } = 233 *10^6 B/s = 233 \space MB/s $$ $\endgroup$
    – ilkkachu
    Sep 14, 2016 at 6:21
  • $\begingroup$ Ok, but when we go multicore? What then? $\endgroup$
    – yak
    Sep 19, 2016 at 14:02
  • $\begingroup$ @yak - In ideal case, if 1 core gives you 233 MBps, x cores will give you 233x MBps. $\endgroup$
    – xkcd
    Jan 24, 2017 at 12:28

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.