Today most new processors, either for embedded or desktop systems include either instructions intended to speed up cryptographic operations, or a co-processor with cryptographic capabilities. Taking advantage of those is a challenging task for every cryptographic application or library. GnuTLS handles the cryptographic provider in a modular way, following a layered approach to access cryptographic operations as in Figure 11.4.
The TLS layer uses a cryptographic provider layer, that will in turn either
use the default crypto provider – a software crypto library, or use an external
crypto provider, if available in the local system. The reason of handling
the external cryptographic provider in GnuTLS and not delegating it to
the cryptographic libraries, is that none of the supported cryptographic
/dev/crypto or CPU-optimized cryptography in
an efficient way.
The Cryptographic library layer, currently supports only libnettle. Older versions of GnuTLS used to support libgcrypt, but it was switched with nettle mainly for performance reasons24 and secondary because it is a simpler library to use. In the future other cryptographic libraries might be supported as well.
Systems that include a cryptographic co-processor, typically come with
kernel drivers to utilize the operations from software. For this reason
GnuTLS provides a layer where each individual algorithm used can be replaced
by another implementation, i.e., the one provided by the driver. The
FreeBSD, OpenBSD and Linux kernels25 include already
a number of hardware assisted implementations, and also provide an interface
to access them, called
GnuTLS will take advantage of this interface if compiled with special
options. That is because in most systems where hardware-assisted
cryptographic operations are not available, using this interface might
actually harm performance.
In systems that include cryptographic instructions with the CPU’s
instructions set, using the kernel interface will introduce an
unneeded layer. For this reason GnuTLS includes such optimizations
found in popular processors such as the AES-NI or VIA PADLOCK instruction sets.
This is achieved using a mechanism that detects CPU capabilities and
overrides parts of crypto back-end at runtime.
The next section discusses the registration of a detected algorithm
optimization. For more information please consult the GnuTLS
source code in
When an optimized implementation of a single algorithm is available,
say a hardware assisted version of AES-CBC then the
following functions, from
be used to register those algorithms.
Those registration functions will only replace the specified algorithm and leave the rest of subsystem intact.
For asymmetric or public keys, GnuTLS supports PKCS #11 which allows operation without access to long term keys, in addition to CPU offloading. For more information see Hardware security modules and abstract key types.
for the Linux kernel implementation of