I've been told that asymmetric cryptography requires that the message to be encrypted be smaller than its key length. Why is this?
I know about hybrid encryption, which uses symmetric encryption to resolve this problem. But I still want to know why public-key cryptography needs the data to be shorter than the key length.
There are two main reasons why asymmetric cryptography is practically never used to directly encrypt significant amount of data:
1) Size of cryptogram: symmetric encryption does not increase the size of the cryptogram (asymptotically), but asymmetric encryption does. If we take the example of RSAES-OAEP in PKCS#1v2 with a 1024-bit key and 160-bit SHA-1 hash, a 1024-bit cryptogram can convey a maximum of 688 bit of useful information. Thus data enciphered in this way would cost 49% more space to store, or more time to move over a given link.
2) Performance: on a modern CPU with hardware AES support, encryption or decryption speed is over 2000 megabyte/second (per core); while decryption of a 1024-bit cryptogram in the above scheme can perhaps run at 4000 per second (per thread of a comparable CPU), thus a throughput of 0.4 megabyte/second, 5000 times slower; that's also moreless the ratio of power usage. That ratio tends to get even worse as security increases. While there are more efficient schemes, it is safe to say that a symmetric scheme is orders of magnitude faster and less power hungry than an asymmetric one, at least for decryption (some asymmetric schemes, including RSA with low public exponent, are considerably faster on the encryption side than they are on the decryption side, and can approach the throughput of some symmetric cryptography).
Addition: Asymmetric Cryptography does not "need data smaller than its key length". For example, the public key in an RSA scheme can be reduced to about half the cryptogram / modulus size by fixing high-order bits of the modulus $n$, and setting $e$ to a fixed value, thus can have a cryptogram nearly double the public key size. The private key can be compressed even further, ultimately to the seed of a PRNG.
BUT... In practical terms, we needn't use these tricks to make the data look smaller than the key size. This is because it is simple to use hybrid encryption; we pick a random Symmetric key, encrypt that key with the public key, and then use the Symmetric key to encrypt the data. With this approach, we can handle an arbitrary sized data using any public key encryption method.
However, any public-key encryption schemes is bound to increase the size of the data that it enciphers: if it did not, there would be a single ciphertext for any given plaintext, and thus an adversary could test if the plaintext is a certain value, simply by enciphering that value (using the public key) and comparing to the ciphertext. Public-key encryption schemes typically increase the cryptogram size by $k$ bits to resist such attack with a strength of $2^k$ encryptions.
openssl speed -evp aes-128-cbc)
$\endgroup$
Symmetric encryption is generally faster than asymmetric encryption. That is the basic reason to use symmetric encryption with larger amounts of data. The time difference between the two methods will increase linearly as the amount of data increases.
From Wikipedia on computional cost of Public-key cryptography:
Computational cost
The public key algorithms known thus far are relatively computationally costly compared with most symmetric key algorithms of apparently equivalent security. The difference factor is the use of typically quite large keys. This has important implications for their practical use. Most are used in hybrid cryptosystems for reasons of efficiency – in such a cryptosystem, a shared secret key ("session key") is generated by one party, and this much briefer session key is then encrypted by each recipient's public key. Each recipient then uses the corresponding private key to decrypt the session key. Once all parties have obtained the session key, they can use a much faster symmetric algorithm to encrypt and decrypt messages. In many of these schemes, the session key is unique to each message exchange, being pseudo-randomly chosen for each message.
