Warning: Using encryption may cause performance issues. Or maybe not. It really depends on how you use it. If you understand just how "expensive" each part of your enterprise encryption operation is, it's possible you can avoid the expensive parts and dramatically increase the performance of your applications.
This doesn't require low-level hacking of encryption algorithms. Not at all. You simply need to understand the relative cost of operations that enterprise encryption software performs, then minimize use of the most expensive of these: network connections.
An example: Encrypting email
The way you implement email encryption between two people is a good example. Suppose that Alice wants to use the S/MIME protocol to sign and encrypt an average-sized, 75KB email message that she wants to send to Bob. We make the following assumptions, which are typical for this particular use of encryption:
- Both Alice and Bob have X.509-based certificates that will be used in this protocol.
- Alice will get Bob’s certificate from an LDAP server.
- Alice will validate Bob’s certificate with a call to an OCSP server before she uses the certificate.
- Alice will use a 2,048-bit RSA signing key to sign the email.
- Alice will use AES-CBC with a 128-bit key to encrypt the email.
- Bob’s public encryption key is a 2,048-bit RSA key.
To encrypt an email to Bob, Alice will need to perform the following steps:
- Get Bob’s certificate from an LDAP server.
- Validate Bob’s certificate by making a call to an OCSP server.
- Use her RSA private key to digitally sign the email.
- Pick a random AES key and use that key to encrypt the email message.
- Use Bob’s RSA public key to encrypt the random AES key.
Estimating encryption times
It is easy to estimate the times for the network connections needed in steps 1 and 2 using a utility such as traceroute. Reasonable estimates for these are about 200ms (remember that 1,000ms = 1s) for the connection to the LDAP server and another 200ms for the connection to the OCSP server. That 200ms includes setting up a TCP connection to a server (SYN, SYN ACK, ACK) and the TLS protection needed for that connection (ClientHello, ServerHello, etc.), as well as the request to and response from the server. It includes propagation delay, transmissions delay, processing delay, and queuing delay. It also includes the cryptographic operations that are needed to implement the TLS protocol, but those are probably a small fraction of the 200ms, as we will see shortly. It does not include the time to shut down the TCP connection (FIN, ACK).
Performance will vary
I should note that the times needed for these TCP connections can vary significantly from these estimates. If the TCP connection is being made to a server in the same data center as the client application, the time will be less. If the TCP connection is being made to a server across the country or on a different continent, the time will be more. A connection to a close server might be faster by a factor of two or more, while a connection to a distant server might be slower by a factor of two or more.
Using the OpenSSL speed command
It is also easy to estimate the times needed for the other cryptographic operations. In particular, the speed command for OpenSSL is an easy way to do this. So if you type “openssl speed rsa2048” or “openssl speed aes-128-cbc” at a Linux command prompt, you will get good estimates for the timing information that we want.
Even if you are not using the OpenSSL library for your cryptography, the estimates that OpenSSL will give you will probably not be too different from the actual performance of the cryptographic library that you are using instead. So if you are not using OpenSSL, don’t be afraid to get rough estimates using OpenSSL’s speed command.
Totaling the estimates
On a typical computer, Alice’s RSA signing operation takes about 0.06ms, her AES encryption about 0.75ms, and her RSA encryption operation about 1.6ms. Because these values are so much smaller than the total times needed for the network connections, you probably shouldn't worry about the time needed for the cryptographic operations in setting up the necessary TLS connections. The times needed for the network connections can easily vary by a few milliseconds, which is much more than the total amount of time needed by the additional cryptographic operations—i.e., 200ms plus or minus a few milliseconds is still about 200ms.
Now we have estimates for all of the steps that Alice needs to create her encrypted email for Bob. These are summarized in the table below.
Approximate timing of the steps needed to encrypt a typical email message.
Step | Operation | Time taken |
1 | Alice gets Bob’s certificate from an LDAP server | 200ms |
2 | Alice validates Bob’s certificate by making a call to an OCSP server | 200ms |
3 | Alice uses her private RSA key to digitally sign the email | 1.6ms |
4 | Alice picks a random AES key and use that key to encrypt the 75KB email message | 0.75ms |
5 | Alice uses Bob’s public RSA key to encrypt the random AES key | 0.06ms |
Minimize your app's network connections
Note that almost all of the time taken for this relatively simple encryption operation is due to network connections instead of cryptographic operations. That might seem a bit surprising. After all, using an RSA key to either sign or encrypt involves doing complicated calculations with 2,048-bit (671 decimal digits) numbers.
Those are big numbers, and it is easy to understand why doing calculations with them is slow. But network connections are even worse than doing those calculations. Much worse. So if you are worried about the performance of an encryption operation, the first thing to do is to minimize the number of network connections that your application makes to implement encryption. Those are very expensive, and their use should be avoided if possible and minimized in all other situations.
And note that only some of these operations will get faster if Alice uses faster hardware. The digital signature can get faster. The AES encryption of the email can get faster. The encryption of the AES key can get faster. But faster hardware will probably have no influence on the time taken by the network connections. Even if Alice can reduce the time taken by the encryption and signing operations to zero, she will still be left with over 99 percent of the original time required for the overall operation.
The network connections are not everything, but they are almost everything.
Other 'expensive' security operations
All of this discussion has been from the point of view of a client application. From the point of view of the server that the client application communicates with, there are additional expensive operations to consider, because many security-related operations are typically logged in a database.
Every request for a key from a key server is probably logged. And the success or failure of the authentication of the request to get a key from a key server is probably logged. Information about these events is typically stored in a database, and for that to happen, the server application needs to make a connection to the database, and those events get stored in the database.
Both of those operations can be expensive relative to the time that using the key takes. The connection to the database takes roughly the same amount of time as the other TCP connections I described earlier, and writing the event log data to a hard disc probably takes about the same amount of time as a digital signing operation.
It is easy to think of other examples where the time required to carry out the encryption operation is indeed the biggest cost, like using a single AES key to encrypt 1 million records in a database. But do not assume that encryption will always cause performance issues. Whether or not it does really depends on exactly how it is used.
Performance depends on how you encrypt
So does encryption hurt performance? Maybe. It really depends on exactly what you are doing and how you are doing it. In many cases, you will find that the actual encryption is not a significant factor.
Other things such as the overhead from secure network connections are typically much more expensive, and these are additional costs that many types of enterprise software will incur. They are not unique to encryption at all.
Image credit: Flickr
Keep learning
Get up to speed on unstructured data security with TechBeacon's Guide. Plus: Get the Forrester Wave for Unstructured Data Security Flatforms, Q2 2021.
Join this discussion about how to break the Ground Hog Day repetition with better data management capabilities.
Learn how to accelerate your analytics securely into the cloud in this Webinar.
Find out more about cloud security and privacy, and selecting the right encryption and key management in TechBeacon's Guide.
Learn to appreciate the art of data protection and go behind the privacy shield in this Webinar.
Dive into the new laws with TechBeacon's guide to GDPR and CCPA.
