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...
