Because of the format this question is in, it was a toss up between posting it to this site or Skeptics, but I went for here in the end because I'm probably more likely to get a definitive answer.

According to the InfoSec-themed Twitter account @SwiftOnSecurity, on a single tweet that is part of a larger thread seen here:

Fun fact: A modern CPU can decrypt AES at several gigabytes per second, at like 3% usage. Seriously this isn't even a consideration anymore.

To me, the word "modern" here seems to imply "average", and it's this that made me suspect hyperbole when I initially came across the claim. I find it hard to believe that the average CPU can do this based on my own experiences of using several different RAR-cracking programs to password-crack WinRAR files that employed AES encryption.

I was able to average only 200 p/s on my Dual-Core i3-2100, and all the programs I used took the better part of a day to work their way through a plain-text dictionary of several million passwords. In addition, this was always achieved by pushing the CPU to its limits at 100% usage. Granted, the i3-2100 is no longer a modern CPU, so perhaps it's possible that CPUs released in the last year or so have improved dramatically, hence why I'm here asking the following questions.

Is the average CPU produced in 2017 capable of decrypting AES at several gigabytes per second?

Would such a CPU be capable of doing so at just 3% of its usage?

Does the quote in question misrepresent or over-simplify the topic, or is it fairly accurate?

Disclaimer: I'm by no means an InfoSec professional, nor have I studied information security in any depth, so I apologise in advance if I'm speaking from a place of unforgivable ignorance here.

  • 11
    See the numbers at calomel.org/aesni_ssl_performance.html which show several GByte per second per core on commonly used CPU. It's the first hit for me when searching for aes speed cpu. But your system (i3-2100) has no hardware support for AES according to the product description and that's why it is slow. – Steffen Ullrich Apr 3 '17 at 5:03
  • 13
    It sounds like you are comparing AES decryption speeds to password/passphrase key-derivation function for AES speeds. The latter are intentionally slowing the process of 'generating' a key for security purposes, while the former assume you already have the valid decryption key. – PwdRsch Apr 3 '17 at 5:24
  • 1
    The claim that AES in typical modern hardware is so fast that it's no longer the bottleneck is pretty much true. The claim that HTTPS or SSL is therefore fast, is slightly more complicated than that. For instance, SSL defeats client side proxy caching, so you are forced to deploy with a CDN to maintain good global performance. Second aspect, initial TLS handshake still takes multi round trips, though subsequent reconnection is requires less roundtrip. TLS 1.3 enables zero roundtrip reconnection, but this comes with a number of security caveats. So yes, AES is no longer bottleneck for HTTPS. – Lie Ryan Apr 6 '17 at 3:03
  • @Hashim: You are misreading the tweet. The author is talking about how quickly modern processors can decrypt AES data if you have the secret key. Whatever the numbers are, the point is just that recent CPUs have specialized AES acceleration hardware, to allow more software to use encryption routinely without a large performance impact. – Luis Casillas Apr 7 '17 at 1:38

AES decryption with the key can definitly happen at GB/s on modern Intel CPUs. Brute-forcing the entire AES keyspace (e.g. 2^128 possibilities) is considered impossible today by a very large margin (more time than the age of the universe).

AES is regarded as so strong that known-plaintext attacks and differential cryptanalysis can be compared to brute force on getting the plaintext in (un)reasonable time (several billion years) !

AES encryption achieves similiar speeds , therefore SwiftOnSecurity argues that claims on how HTTPS impacts performance are outdated.

  • Exactly...I suspect the context of the quoted tweet was full disk encryption..possibly https – ste-fu Apr 3 '17 at 23:25
  • The twitter conversation seems to be about HTTPS. – flakeshake Apr 5 '17 at 14:35
  • I believe AES encryption is decently faster than AES decryption, since encryption requires an aeskeygenassist, a number of aesenc, and one aesenclast, whereas decryption, aside from s/enc/dec/, has an additional aesimc before each round decryption. It's sufficiently slow enough that I ended up using a CTR-based decryption routine for a kernel patch I wrote, since CTR can do both encryption and decryption using just encryption instructions. – forest Jan 2 '18 at 3:29

Hello this is @SwiftOnSecurity who wrote the quoted tweet in the question.

Please ignore my 3% claim. This was an off-hand comment that I should not have made in service of my central point. I erred in using such a trivial number to emphasize that overhead is generally not a concern, and consumer CPUs can handle even absurd decryption speed requirements.

I did honestly think it was sub-10%, because I thought the core AES-NI instructions were somehow exempted from CPU utilization, and it would not max a core. This was the thrust of the "3%" claim. I have very little knowledge of CPU architecture, and it shows here.

I will issue a correction when I return to Twitter. (currently taking a break)

Again, I'm deeply sorry for the misleading information. I do try to be generally reliable in my specific technical claims. I'm humbled you thought enough of this to ask a question on StackExchange.


  • I was wondering where that 3% claim came from! – forest Jan 2 '18 at 3:25

Yes, the claim is basically true as stated, at least if you ignore the "3%" part. For example, according to these benchmark results, an Intel Core i3-6100 3.70 GHz CPU (which is from the last generation of Intel's low-end desktop CPU line, and thus presumably fairly representative of an "average modern CPU") can do AES encryption (or, presumably, decryption) at 3.28 gigabytes per second on a single core, and nearly twice that using both cores.

I'm not entirely sure what the "3% usage" part of the claim is supposed to mean; taken at face value, i.e. to mean that doing the encryption only slows down other simultaneous processing by 3%, it does seem unrealistic. With hyperthreading, presumably you could run up to three other threads on that Core i3 CPU at the same time, while still maintaining something close to the full single-core AES throughput, but that's still 25% CPU usage, not 3%. I suppose if you upgraded to a high-end server CPU with, say, 16 cores, then with hyperthreading you could run up to 31 other threads at the same time, for a 3.125% CPU usage. That might be what the claim is about, even if that's hardly "average" any more.

So why is password cracking still so slow, then? That's because it's designed to be slow. Specifically, any reasonably well-designed password based encryption scheme will use a deliberately slow iterated key derivation function to implement key stretching. Basically, when you enter your password, the first thing the software does is hash it a few thousand or million or billion times; the final result of all this repeated hashing is then used to generate the actual AES key. On a modern CPU, all that hashing still takes only a small fraction of a second, and so is hardly noticeable to normal users. However, it effectively slows down brute force password guessing attempts by a factor proportional to the number of times each password needs to be hashed.

  • 1
    Modern CPU's pipeline and rearrange instructions. So, while the AES instruction is taking its presumably multiple clock cycles to operate, the CPU's still free to do other work in the same thread. This makes the "3% usage" claim plausible (though I haven't verified the exact number). The claim's unlikely to follow from a core-based argument because that doesn't really make sense. – Nat Apr 6 '17 at 23:55

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.