One lesson that can be drawn from our experiments is that the current generation of hardware cryptographic accelerators is not sufficient to support ubiquitous use of encryption. Figure 1 points to one problem: the nominal performance of crypto cards is only achieved for large buffer/packet sizes. Since a large percentage (up to 40%) of the packets in a TCP bulk-transfer is 40 bytes, we can see that much of the benefit of such hardware is lost: the cost of card and DMA initialization, PCI transfers, and interrupt handling is roughly comparable to the cost of pure-software encryption, especially as processor speeds increase. This observation suggests that one possible solution is a hybrid approach, where the system uses software encryption for small packets, and hardware encryption for large ones. Another possible solution could be integrating cryptographic functionality with the network interface, which would also improve CPU utilization by offloading the encryption.
One argument against this is the versatility of separate cryptographic components, which allows their use by many other applications ( e.g., filesystem encryption, database and other user-level processes that do crypto, etc.). While this may be a valid argument in the case of user-level processes, we believe that cryptographic accelerators can be integrated with other I/O devices that can use them more efficiently (in particular, disk and tape controllers). The declining cost of high-performance cryptographic chips makes this a viable alternative to dedicated processors.