To test decryption, call sakagclient with the D option and use the ciphertext from the encryption transaction (from the transaction similar to the top half of the diagram in Encryption [CBC Mode] of this chapter) on the local computer—it is sure to be different from the ciphertext shown in this document) as well as the token from the encryption test as parameters. Make sure to copy the ciphertext exactly as it shows in the output of the encryption command:

java -jar sakagclient.jar https://demo.strongauth.com 1 all Abcd1234!
D HdYm1/+R5FA32AvqJ/WsnwirsW0UHiZF/7Qpc6ySXbVDIQsjjGtDBeObdvvQU5FKu5grm58v5DXtqNk1jl39cNBpR0Ht3DX/xUz2vZPC0uo=
1000000000101315

The operation may take a little while because cryptographic keys may need to be loaded from the internal database and decrypted before the actual encrypted object can be decrypted. However, once the keys are decrypted, they are cached for a short duration (15 minutes); repeating the same decryption operation immediately produces an immediate response. The following picture shows the successful return of the original string (“You must be the change you want to see in the world. M. K. Gandhi”)

NOTE: The first web service request for encryption or decryption within a user's session will see a long delay because of the following factors:

• The latency of the internet

• The verification of the user's authorization (which causes the decryption of a hierarchy of keys in the hardware module to verify the user's password)

• The decryption of the symmetric key before it is available for use

• The actual encryption/decryption of the PAN data

A key-caching feature of SAKA (15 minutes by default) enables subsequent operations to see significant improvements in performance. However, at the end of the default caching period, the keys are flushed from memory and the first cryptographic operation after the flush will see a similar delay as keys are decrypted and loaded into cache memory. The caching window can be configured for individual business needs.

From a performance point of view, the current generation of SAKA, using a TPM, delivers approximately 200–220 web service operations per second (WSOPS) when multi-threaded client applications make requests. In a clustered environment where all nodes in the cluster may service client applications, the overall WSOPS will be higher than for an individual SAKA, but will be difficult to predict in advance without understanding the topology of a given network and affected applications.