Use of PublicKey Encryption
Learn how publickey cryptosystems are used in practice.
Limiting factors
Despite its benefits, two significant factors limit the adoption of publickey encryption:

Computational costs: As noted, publickey encryption and decryption are relatively expensive computations to perform. This means that in applications where processing speed is important (in other words, almost every application), it’s often regarded as a good idea to restrict the number of publickey encryption and decryption operations performed. This is by far the most important restriction on the use of publickey encryption.

Longplaintext security issues: All of our discussion in this chapter has involved encryption of single plaintexts, which can be represented by one ‘unit’ of publickey encryption.
For example, we assumed that a plaintext to be encrypted using an RSA public key $(n, e)$ could be represented as a number less than $n$. If we want to encrypt a longer plaintext, we first have to split the plaintext up into separate ‘units’ and then encrypt these separately. If we consider each of these plaintexts as ‘blocks’ (which is a reasonable analogy), then by default, we would be encrypting these separate blocks using the publickey equivalent of ECB mode for a block cipher. This gives rise to the several security issues we discussed, all of which were resolved by proposing different modes of operation for block ciphers.However, there are no alternative modes of operation proposed for publickey encryption. (This is, of course, primarily because of the lack of demand due to the computational issue just discussed.) From a security perspective, it might also be wise to restrict the use of publickey encryption to single plaintexts—‘single’ meaning that the entire plaintext can be encrypted in one computation.
Therefore, there’s a strong case from both an efficiency and a security perspective for limiting the use of publickey encryption to ‘occasional’ short plaintexts.
Hybrid encryption
There are several applications in which we want to use publickey encryption due to the benefits discussed earlier. However, as we just saw, when the plaintexts are long, we don’t use publickey encryption. This gives rise to a conundrum—whether to use publickey encryption or not. Fortunately, we have an elegant and simple solution to this conundrum, namely hybrid encryption.
If Alice wants to encrypt a (long) plaintext and send it to Bob, she will do the following:

First, she generates a symmetric key $K$ and publickey encrypts the symmetric key $K$ using the public key of Bob.

Then, she symmetrically encrypts the plaintext using $K$.
Alice then sends both of these ciphertexts to Bob. On receiving the two ciphertexts, Bob will do the following:

First, he recovers the symmetric key $K$ by decrypting the first ciphertext using his private key.

Then, he recovers the original plaintext by decrypting the second ciphertext using $K$.
This hybrid encryption process is depicted in the illustration below:
Get handson with 1200+ tech skills courses.