The problem of cryptographic algorithms & cryptographic accelerators

There are many ways one could use cryptography in GNU/Linux. There are cryptographic libraries such as the Java crypto API, Botan, OpenSSL, GnuTLS and nettle,  that provide access to crypto algorithms. The Linux kernel has also its own cryptographic API to be accessed by the in-kernel IPSec implementation. They all offer a variety of algorithms and each one has its pros and cons. Some implementations might be faster, some slower but such variation is expected.

New generation CPUs contain instruction sets for cryptographic operations, such are VIA's PADLOCK and Intel's AES-NI. Other embedded systems provide a cryptographic accelerator allowing offloading of cryptography. An interesting question is how do the above cryptographic libraries take advantage of the above optimizations?

Cryptographic operations based on the PADLOCK or AES-NI instruction sets require libraries to re-write their AES (for example) implementation using the above instruction sets. They both have special requirements for data and key alignment requiring special care on implementation. Moreover since those instruction sets are not available in all CPUs of the same family, run-time CPU detection has to occur which will enable the optimized versions.

The cryptographic accelerators case is more complicated. Cryptographic libraries cannot access the accelerators without a driver. Until recently there was no generic driver to access them in the Linux kernel. Today we have two. The AF_ALG interface, which is included in the Linux kernel since 2.6.38 and the cryptodev-linux interface which is an interface compatible with OpenBSD's /dev/crypto. Both allow access to the hardware accelerated algorithms included in the Linux kernel. Moreover, in CPUs having the PADLOCK or AES-NI instruction set the Linux kernel includes and uses optimized versions of the crypto algorithms. This allows the kernel interface to be used as a generic interface to access cryptographic accelerators and optimized instruction sets.

However, performance-wise this is not optimal.  The kernel interface requires switches from user-space to kernel-space which has a significant performance cost. Thus the usage of the kernel services should be avoided when possible (i.e., in the AES-NI and padlock instruction sets).

So there is no universal interface to take advantage of hardware-accelerated cryptography. But is there one needed? Why have a universal interface to access hardware acceleration when there isn't any to access cryptography?

I believe a universal interface to access hardware accelerated cryptography is needed because not having it involves a massive duplication of work, that is architecture and system specific. Such an interface would allow the crypto libraries to stay architecture or system agnostic and focus on the bigger picture rather than coping with architecture quirks, hardware bug work-arounds etc. Moreover, cryptographic libraries compete on the interface, protocols etc. Libraries competing on hardware support although typical for the 80's and 90's shouldn't be the case in a  modern operating system.

How can this be solved? I believe a system-wide library to access accelerated crypto would be the ideal. One that would use the kernel provided cryptography in case of a hardware accelerator, or the relevant CPU-specific instructions if detected. Each cryptographic library could then use it, to provide accelerated cryptography transparently to all applications.