How to calculate time taken by encryption? 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:


CPU has 1 core, and 2.8GHz, algorithm is AES-128-CBC, data size
to encrypt is 1024 MB
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?
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)