The performance of the card and given algorithm changes with the length of processed data. Here we provide detailed performance for relevant methods expected to process input with variable lengths (e.g., Cipher.doFinal()). We measured the execution time for data lengths of 16, 32, 64, 128, 256 and 512 bytes and visualize in a graph. Multiple measurements of the same method and fixed data length are performed to capture its variability.
We also included measurements of several methods usually used together in single sequence (e.g., set key, init the engine and sign the data). Note that resulting time is not simply the sum of operations measured separately as JavaCard Virtual Machine itself influence the results same way as caching and other optimizations do for ordinary CPUs. Used key values are randomly generated to prevent JCVM optimizations by skipping already performed initialization.
Note that as many algorithms are block-based, you will experience almost the same execution time until the length of the process data exceeds the length of internal algorithm block (e.g, 64 bytes for SHA-2 hash) after which significantly more operations are executed to process another full block. Similar behavior but with a different underlying cause can be observed when the length in processed data exceeds the length of engine's internal memory buffers. Finally, it often makes sense to concatenate multiple independent blocks into a buffer and then call processing method only once as actual processing (e.g., encryption) is only part of the operation - context switch between card's main processor and crypto co-processor may be significant.