Variations

Edit online

Variations of setup characteristics and parameters were used in the JSSE study, to show the effect of these variations on workload output and performance.

Ciphers

Different cipher suites are used for each test case. Each test case is therefore run four times, once using each cipher. The full cipher name is listed, followed by a shortened name in parenthesis. The shortened name is used throughout this document.
  • SSL_RSA_WITH_RC4_128_MD5 (RC4-128)
  • SSL_RSA_WITH_3DES_EDE_CBC_SHA (3DES)
  • SSL_RSA_WITH_AES_128_CBC_SHA (AES-128)
  • SSL_RSA_WITH_AES_256_CBC_SHA (AES-256)
These ciphers follow this naming schema:
  • All ciphers use the Rivest-Shamir-Adleman (RSA) cipher for the SSL handshake (asymmetric algorithm for public-key cryptography).
  • The symmetric ciphers for data encryption are RC4-128, 3DES, AES-128, and AES-256.
  • CBC stands for cipher-block chaining, where each block of plaintext is exclusive OR'd with the previous ciphertext block before being encrypted. This way, each ciphertext block is dependent on all plaintext blocks processed up to that point. This technique increases the security level. For details, see:

    https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

  • MD5/SHA are hash algorithms used for digital signatures.

Each cipher has different workload and performance characteristics. Some ciphers might not be supported by either one or both of the cryptographic hardware devices (CPACF and CEX2A).

Hardware versus software encryption

The performance characteristics of the hardware cryptographic operations and key storage and retrieval are compared to the same operations running with software encryption on the Java™ virtual machine. Different ciphers and packet sizes are used to understand performance attributes under a variable workload.

Packet size

Different packet sizes are used to create six separate tests using packet sizes from 1 byte to 262144 bytes. The smaller packet sizes would have a higher relative percentage of the resources dedicated to the SSL handshakes, which in hardware encryption mode are run on the IBM® Crypto Express2 feature.

The larger packet sizes would cause more resources to be devoted to the encryption, decryption, and hashing of the data. For hardware encryption, the data encryption and hashing would run on the Central Processor Assist for Cryptographic Function (CPACF).

Hardware encryption with and without polling thread (poll_thread=1)

The z90crypt device driver provides a polling thread. The polling thread queries the cryptographic adapter for finished cryptography requests that were offloaded to the cryptographic adapter. The use of the polling thread provides a trade-off. The requests from the cryptographic adapter are normally retrieved only once every 1/100th of a second. This retrieval rate is used because this value is the rate used by the Linux® kernel timer. The limit equates to 100 SSL handshakes per second.

This limit can be relaxed when the adapter is lightly loaded, such as with workloads with fewer than eight parallel connections. There is a CPU cost to run an additional thread that performs repeated polling operations. The throughput and CPU utilization are measured by running the z90crypt device driver with and without the polling thread enabled, for all the different ciphers and packet sizes.

Cached or uncached session

It is possible to pass an invalidate flag to the test program and have the invalidate() function run using the session object. This function invalidates the session, meaning that any handshakes must be repeated. With session caching, even after sessions close the keys, the identity of the client is maintained. This means that when a subsequent new connection and session are requested, a new handshake is not required.

The JSSE routines that handle SSL handshakes therefore do not need to run to generate new encryption keys using the resource-intensive asymmetric key generation. For hardware encryption, this means that the use of the IBM Crypto Express2 feature is minimal. With this test and a very small packet size, it is possible to isolate the effect of handshakes on JSSE throughput, because the effort for data encryption is minimal. Most of the tests in this study are run with uncached sessions, in order to specifically exercise the SSL handshake mechanism.

Client authentication

Client authentication is an authentication mechanism where the server requests a certificate from the client, in order to verify that the client is what it claims to be. The certificate must be an X.509 certificate and signed by a certificate authority (CA) trusted by the server.

The client typically receives the server's certificates and checks to see if the server is on the list of trusted certificate authorities (CA). If the server is on the list, or if the client decides to trust the server, the certificate is accepted. Client authentication is an optional security step that goes beyond this trust mechanism to increase the level of security.