Use of Public-Key Encryption

Limiting factors

Despite its benefits, two significant factors limit the adoption of public-key encryption:

• Computational costs: As noted, public-key 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 public-key encryption and decryption operations performed. This is by far the most important restriction on the use of public-key encryption.

• Long-plaintext security issues: All of our discussion in this chapter has involved encryption of single plaintexts, which can be represented by one ‘unit’ of public-key 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 public-key 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 public-key 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 public-key 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 public-key encryption to ‘occasional’ short plaintexts.

Hybrid encryption

There are several applications in which we want to use public-key encryption due to the benefits discussed earlier. However, as we just saw, when the plaintexts are long, we don’t use public-key encryption. This gives rise to a conundrum—whether to use public-key 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:

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

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

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

2. Then, he recovers the original plaintext by decrypting the second ciphertext using $K$.

This hybrid encryption process is depicted in the illustration below: