Does Encryption Hurt Performance?

By Cynthia Leonard — September 23, 2015

HP Data Security is a provider of encryption technologies that provide powerful security for sensitive data and email communications. In HP’s line of work, we are often asked, “Does encryption hurt performance?” The answer depends on how encryption is being used and how performance is being measured. A common belief is that encryption will consistently cause performance issues when used to protect sensitive data. That is not always the case.

Not all encryption techniques are the same. For simplicity’s sake, suppose that we are performing a fairly straightforward operation (e.g. encrypting a single field in a database). This operation consists of the following set of high-level steps:

A call to a secure key server to fetch an encryption key over the network.

Encryption of the actual data.

Storage of the encrypted data and logging of the event.

For those not as familiar with AES keys, The Advanced Encryption Standard (AES) is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST). For AES, NIST selected a block size of 128 bits, but three different key lengths: 128, 192 and 256 bits.

Assume we are fetching a 128-bit AES key. Fetching the key will require both network overhead as well as disk I/O. Encryption of the sensitive data is most likely the fastest part of this entire operation. It takes relatively little time, such that it is almost not worth worrying about. For a better sense of the relative time scale between network, disk access, and CPU, see the reference here and this one from Git Hub.

Assume further that the connection to the key server was over a TLS (or SSL) connection. To get the same level of security as our 128-bit AES key, we would need to use a fairly big public key to set up the secure connection. Assuming we are using the RSA algorithm (like most of the world does), we will l need a 3,072-bit RSA key to match the security of our 128-bit AES key.

If we do not use a longer RSA key, we are getting less effective security from that AES key. This is because the weakest link in the overall security chain would then be the weaker RSA key. Cracking a 2,048-bit RSA key takes about the same amount of effort as cracking the 112 bits of security that three-key Triple-DES does. Thus, we say that the 2,048-bit RSA key provides 112 bits of security. The 2,048-bit RSA key is the weak link, and we are effectively achieving only 112 bits of security from that 128-bit AES key.

Using a 3,072-bit RSA key to set up the secure connection to the key server takes much more computing time than encrypting with the 128-bit AES key does. That is because it requires doing a lot of math operations on 3,072-bit integers. Those are not fast.

Then the situation gets worse. Much worse.

Setting up that secure connection also requires a few trips across a network, and doing anything over a network is typically much more time consuming than doing calculations in memory. Because of the combination of public-key operations and the time spent transmitting information across a network is so much higher than the time consumed performing the AES encryption, the AES encryption becomes negligible by comparison to the rest of the time spent in the overall operation.

However, in an enterprise computing environment, there is an even more time consuming operation that happens: event logging. When a key is requested from a key server, that event and others are logged in a database. Each key request is logged, and the success or failure of every attempt to authenticate to the key server is also logged. Recording those events in a database results in writing data to a hard disk, and operations that write to a hard disk are frequently even slower than network operations by a factor of 10 or more.

The AES encryption is one of the fastest parts of the entire operation of getting a key and using it to encrypt a field of sensitive data. The actual AES encryption operation looks like it takes almost no time by comparison.

Does encrypting sensitive data hurt performance? Maybe. The answer depends on how the whole encryption process is implemented. In most cases, the actual encryption is not a significant factor. The other components such as overhead from network connections and disk writes will be much more time consuming.

Stephen Pratt is a Senior Performance Test Engineer for HP Security Voltage. He works on HP SecureMail, measuring and reporting on the performance and resource utilization under load of the SecureMail Server.