I’ve been writing about encryption performance lately because our customers and potential customers have been asking about the impact of encryption on the overall performance on their systems. It’s good that they are asking these questions as a poorly performing encryption library can have severe impact on your application environment. This is especially true on an IBM Enterprise platform like the IBM i (formerly known as AS/400 and iSeries) where customers often run multiple applications.
While it is common in the Microsoft, UNIX, and Linux worlds to segment different applications onto different physical servers, it is common in the IBM i world to run many applications on the same server. You typically find CRM, ERP, web, and many other applications happily co-existing on one IBM i server. But this means that a poorly performing encryption library will have a ripple impact on all of these applications, and not just one.
IBM provides a no-charge, AES software encryption library on the IBM i platform that developers can use to encrypt data. It implements all of the standard AES key sizes (128, 192, and 256) along with a variety of other encryption algorithms, both open and proprietary. I don’t believe the software library has been independently certified to the NIST standards, but I believe that it properly implements the AES encryption algorithm.
But how does it perform?
We did a simple little comparison test of encrypting 1 million credit card numbers on an entry level IBM i model 515 server with a single processor. We compared the native IBM AES library with our own AES encryption library which is NIST certified and optimized for encryption. The difference is very large. Our IBM i encryption library clocked in at 116 times faster than the native IBM i library. Note that this is an informal test and not independently verified, but practical experience by our customers is very similar.
What does this mean in terms of application performance when you add encryption to the mix? The math is pretty simple. An encryption task that takes 10 minutes with our library will take several hours with the IBM library. That’s painful. And all of the other applications that share this system will also feel the pain.
The problem is not limited to just an occasional developer at an individual customer site. Some vendors of IBM i software use the IBM encryption libraries, too. So you can be inadvertently using the poorly performing libraries without knowing it.
Often I see IBM i customers trying to fix an encryption performance problem by adding additional processors to their servers. This can be expensive, and usually involves software license upgrade fees. It can also not have the impact that you might think. Due to the way that encryption works, adding a second processor usually will not double your encryption throughput. Another bit of disappointment and extra cost.
It is usually not hard to fix an encryption performance problem if you catch it early. If you’ve take a modular approach to the implementation, you can usually swap out one module for another without too much difficulty. You just don’t want to be doing that for hundreds of applications.
For more information on AES encryption, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and key management work together to secure your data.