The nature of the challenge for operating systems and their support for cryptography is clear. On every measurement, without exception, small-sized operations fare much worse than those performed on large data buffers. In some cases, buffer size influences performance more than the choice between hardware or software cryptography. This suggests that the per-operation overhead is very high, and this is clear from the larger data sizes, which get close to the throughput advertised by the board manufacturer, which we presume is ``best-case''. In this respect, our findings confirm those of [15]. Since many cryptographic protocols are transactional in nature rather than bulk transfers, these small data operations will be the common case. Energy should be spent on reducing the overhead of such cases.
As we mentioned in Section 5.2, there are several possible approaches: request-batching, kernel crossing and/or PCI transaction minimization, or simply use of a faster processor. These are more cost-effective solutions than deploying a hardware accelerator. In situations where bulk data transfer is the norm (as may be the case in the various Storage Area Network technologies currently under consideration), cryptographic accelerators can drastically improve performance, especially for the more ``expensive'' algorithms such as 3DES. Unfortunately, there were no commercially available hardware accelerators for AES supported by OpenBSD, so we cannot compare the software and hardware cases for that algorithm. However, recent attacks against AES make likely the continued use of 3DES in many environments.