Understanding Factors That Impact Encryption Performance
Recently, we discussed the rising volume of encrypted traffic and its continuously changing nature. Understanding secure sockets layer (SSL) parameters is key to testing for maximum performance under realistic traffic and a relevant environment. This blog elaborates on these key parameters, their impact on encryption performance, and their standard values as recommended by authorities such as the National Institute of Standards and Technology (NIST).
We used a real test to determine some of the special considerations when validating encrypted performance. F5’s article describes the actual results of the tests performed.
Factors affecting SSL performance and their commonly used values.
- Public key exchange, key signing, and certificate exchanges
Asymmetric exchange is where client and server use key pairs and long keys to perform the initial key/certificate exchange to ensure each other’s authenticity. It also derives a smaller-sized shared key used by symmetric encryption for bulk data transfer. This impacts the sessions per second or connections per second (CPS) performance. Examples: ECDHE-ECDSA, ECDHE-RSA, RSA
- Symmetric encryption, data authenticity, confidentiality and hashing
Symmetric encryption ciphers like AES, use the shared secret for both encryption of plain text application data and decryption of cipher text application data. This is also combined with other ciphers like CBC or GCM that provide authenticity and confidentiality to prevent theft or corruption attempts that may be done to the data in transit. This process heavily impacts the encrypted throughput performance. Examples of ciphers; AES-CBC-SHA256, AES-GCM-SHA384.
- Key size
The higher the key size, the more secured the connection. However, the length of key used can impact the sessions per second and, in some cases the throughput performance as well. Generally, for initial key exchange, longer keys like 2K bits (256P curve for ECC) or a comparable strength key is used and for symmetric encryption, anywhere between 128-bit to 256-bit key size is used.
- Session reuse
This is a mechanism where SSL client and server leverages stored information from a past session through methods such as session identifier or session tickets for opening a new session. This helps save resource-intensive computations of public key cryptography. Session reuse can dramatically increase sessions per second and CPS performance. However, when testing, we recommend turning off session reuse to find out the true SSL performance.
- Application protocol and page size
Encryption performance is found using HTTP as the underlying protocol. Usually, a smaller page size like 1024 bytes is used to gauge peak sessions per second performance, while a page size of 65KB to 1MB is used to measure the maximum encryption throughput capability of a product or network. A mix of popular encrypted applications with various transaction sizes are sometimes used to find mixed application encryption performances.
Finding out encrypted performance is not similar to clear text, as various factors can impact the performance (Example: A 512 size key will generally have 4 times better CPS performance than a 2K key size).
Ixia’s CloudStorm Application and Security Test Load Module delivers an architecture that allows concurrent emulation of complex applications, SSL encrypted applications, and a large volume of DDoS traffic to validate that network infrastructure is high performing and secure. CloudStorm supports up to 12 blades in a chassis, and is driven by Ixia’s BreakingPoint and IxLoad test solutions for application delivery and security resiliency testing. With a single blade in the chassis, CloudStorm is capable of achieving 90 Gbps of encrypted throughput and 160,00 connections per second with not any session reuse with strong ciphers and key sizes. Refer to F5’s blog to see how they used CloudStorm to validate some of these parameters in action.