Performance

The product should not perform poorly with security enabled, or users may be tempted to switch it off to meet performance criteria.

ProtectToolkit-C performance

• In tight loops, it is best to remove as much invariant code as possible. This goes for ProtectToolkit-C session startup, login, key generation / find, and even the cipher initialization. That way only the code that does the cryptographic operation is in the inner loop.

• Use session keys wherever possible, since they can be created and destroyed much more quickly than token keys. However, watch out for object leaks when using session objects; they will not be visible to anything but the application that creates them.

• Avoid having too many objects on a token, since object lookups are performed by traversing all objects until the correct one is found. Once an object is found it should not need to be searched for again.

• Multiple adapters (an adapter cluster) can be combined to increase overall throughput, where independent streams of cryptographic operations can be allocated to different devices. Key replication is required if cryptographic operations need to be performed by any adapter in the cluster.

ProtectToolkit-C performance caveats

• Some operations are limited by a slower operation inside the security module. RSA key generation is a good example. Other operations may be limited by the speed at which data can cross the application-security module interface.

• Performance figures quoted by some PKCS#11 device vendors may be difficult to obtain in real-world application. Cprov includes a PKCS#11 utility that measures performance using only the standard ProtectToolkit-C API. In this case there is no use of undocumented calls to obtain performance figures, and any application developer should expect to obtain them from any well-written PKCS#11 application.

• Performance is often irrelevant for operations that are not time-critical or repetitive.

• FIPS-compliant operation may be slower.