# Asymmetric vs symmetric encryption benchmarks

I have found these benchmarks in Crypto++'s site. http://www.cryptopp.com/benchmarks.html

But I am, quite honestly, not entirely sure how to interpret them.

I am really looking for a set of benchmarks, or a study, that shows how asymmetric encryption is slower (and more computationally expensive) than symmetric encryption.

Basically, something that directly pits them against each other and shows the slower performance of asymmetric ciphers.

Could anyone link me to something like that? My Google searches have proved futile.

• The link you posted contains numbers of both symmetric and asymmetric operations -- what else are you looking for? May 8, 2014 at 0:28
• Hi @David. It does but it seems to me that they're not 'rated' the same. As they say at the end: MB/second of each cipher, hash function, and MAC, and operations/second of each asymmetric operation. I would like something that directly compares them?
– user31481
May 8, 2014 at 0:35
• Asymmetric crypto is done to a single value at a time, symmetric ciphers are usually applied to one or more blocks. Since they're not interchangeable, it's hard to make any more of a comparison than in the document. May 8, 2014 at 0:50
• @David I see. Well if I were writing an answer, using these benchmarks, how would I justify the statement that "asymmetric encryption is slower and more computationally heavy than symmetric"? How could I use these results to compare them?
– user31481
May 8, 2014 at 1:16
• Symetric and asymetric ciphers have different purposes and usages. So it is pointless to compare them, even if they were of a comparable performance. Jul 16, 2015 at 7:31

Off the top of my head:

• One raw RSA message can be at most as long as the modulus.
• One cooked RSA message needs padding to be secure. RSA PKCS#1.5 padding needs (at least) 11 bytes of padding.

And I'm going to assume rsa2048. 2048 bits is 256 bytes raw. Minus 11 for the padding gives 245 byte usable.

The CryptoPP site gives:

• RSA 2048 Signature 6.05 milliseconds/operation
• RSA 2048 Verification 0.16 milliseconds/operation

# Calculation

• RSA 2048 Signature 6.05 milliseconds/operation

• (1000 ms/s) / (6.08 ms/op) == 164.47 op/s
• 164.47 op/s * 245 byte/op == 40,296 byte/s
• RSA 2048 Verification 0.16 milliseconds/operation

• (1000 ms/s) / (0.16 ms/op) == 6,250 op/s
• 6250 op/s * 245 byte/op == 1,531,250 byte/s

So: About a 1.5 MByte/s for verify (/encrypt). And 40kByte/s for sign (/decrypt).

And for "AES/CTR (128 bit key)" the CryptoPP table lists about 100 MiB/s.

• Great answer to the question, even if it dodges the problem being solved. Nov 17, 2015 at 16:10
• I disagree. OP wanted something that directly pits them against each other and shows the slower performance of asymmetric ciphers. My answer does that. Refer to Tom Leek's and Mark's answers to see why direct pitting doesn't actually make sense. ;) Nov 17, 2015 at 16:26

In fact, the assertion that asymmetric cryptography is slower than symmetric cryptography does not make a lot of sense. They do not do the same thing. What asymmetric cryptography does, symmetric cryptography cannot do; less intuitively, this also works the other way round: what symmetric cryptography does, asymmetric cryptography cannot do.

Asymmetric encryption allows making the encryption key public, without revealing the decryption key; this is the obvious advantage of asymmetric encryption over symmetric encryption, and the reason why it was invented in the first place.

In the other direction: asymmetric encryption processes only messages of a limited size, and inherently incurs a non-fixed size overhead. For instance, with a 2048-bit RSA key and following the PKCS#1 standard (`RSAES-PKCS1-v1_5`), input messages cannot exceed 245 bytes in length, and yet yield a 256-byte output. It is unclear how a longer message should be split into sub-messages to be processed individually with RSA; this superficially looks like the "chaining" problem with block ciphers, for which modes of operation have been defined, allowing bulk processing of input data. However, block ciphers are easy: they work over nice sequences of bits, and encrypted blocks are indistinguishable from uniform randomness. The same would not hold for, say, RSA, where encrypted messages are integers modulo a big integer which is not a power of 2, which induces biases. This problem of chaining RSA encryptions is not well-studied, and does not seem to have obviously secure solutions.

The size overhead for asymmetric encryption is consubstantial to its asymmetry: since the encryption key is public, everybody can try to encrypt data with the encryption key. If the encryption is deterministic, then this allows an immediate brute force attack on the plaintext (the attacker tries potential plaintext values until a match is found). To prevent that, the encryption MUST be non-deterministic, which in turn implies a size increase (because of pigeonholes).

The raw consequence is that asymmetric encryption is not good at bulk encryption. When the data to encrypt is larger than the elementary size of the algorithm, then we do not really know how to do it securely, but we have rather fundamental reasons to believe that it would be expensive in terms of network bandwidth.

None of the above is about computational cost. To make a meaningful comparison that takes computational cost into account, one must be in a context where there is, indeed, a choice between symmetric and asymmetric encryption to be made. Basically, this would be a situation where:

• You want asymmetric encryption for a message m.
• You may want to use so-called "hybrid encryption": asymmetric encryption to encrypt a random key K, that you then use to process the data with a symmetric encryption algorithm.
• The message m could be processed directly with the asymmetric encryption algorithm.

The third condition means that m is small enough to be the input of a single invocation of the asymmetric encryption algorithm, since otherwise you would not know how to process it. In that case, raw asymmetric encryption necessarily wins, since the choice is between "one asymmetric encryption" and "one asymmetric encryption plus some symmetric encryption stuff". On the other hand, if the size of m may exceed that which can be processed with a single call to the encryption algorithm, then you are back to the chaining problem, and any talk about performance is at best premature: first define what you want to do, see whether it is secure, and then (only then) can we talk about speed.

To make an analogy: you could ask which vehicle is faster, between this one: and that one: If you think that the answer is obvious, go drive your Ferrari into a lake...

• Did you just tell him to go fish? Nov 8, 2015 at 22:10
• Great answer to the problem being solved, even if it dodges the actual question. Nov 17, 2015 at 16:10

Symmetric ciphers (even those described as "block ciphers") are usually used in a stream-like fashion, encrypting or decrypting a sequence of bytes of arbitrary length. Consequently, measuring their speed in MB/s is a useful thing to do.

Asymmetric ciphers are usually used in a block-like fashion, encrypting or decrypting a single small piece of data. This operation takes the same amount of time regardless of whether it's a single bit, a 32-byte hash, or a maximum-sized block. Consequently, measuring their speed in operations/s is a useful thing to do.

You could work out the stream-like speed of an asymmetric cipher by finding out its maximum block size and multiplying by its speed in operations/s. Since asymmetric ciphers are almost never used in stream-like fashion, this isn't a very useful thing to do.