The kernel implementation of cryptographic algorithms will be made available to user-space programs, so that they do not need to handle encryption keys directly or include their own implementations of the algorithms.

The kernel cryptographic algorithm implementation ("kernel crypto") will be made available to user-space programs (current plan is to add a /dev/crypto device). This allows user-space programs to use the FIPS-validated cryptography implementation, and to move all private and secret keys to the kernel. If possible, existing cryptography libraries will be extended to support using kernel crypto, probably not by default (e.g. only when running in FIPS mode, or when manually configured to use the kernel crypto).

The kernel crypto will be, if necessary, extended to allow moving as much crypto implementation to the kernel as possible.

When private and secret keys are stored in the kernel, and suitably configured, it is not possible to retrieve the keys even by applications that are using them to perform cryptographic operations. Thus a compromise of the application, or any other application running as the same user, does not compromise the keys. For example, an exploit of httpd would not allow the attacker to copy the SSL private key from the machine. (The attacker could still modify the running server to alter responses to incoming SSL requests, but only as long as the exploited httpd is running.)

Moving the crypto implementation to the kernel also allows reliable auditing of the crypto (e.g. auditing of all processes that use the SSL private key).

Separation of private and secret keys and the crypto algorithm implementation from user-space programs is also required by the proposed FIPS PUB 140-3 and will be required by the US government.

After enabling the kernel crypto implementations in user-space (e.g. enabling FIPS mode), test cryptography. Particular aspects to test are SSL (using all affected user-space implementations) and password verification. A test suite of the kernel interface is being developed, and existing test suites of cryptographic libraries will be very useful for validating the modified implementation.

Using kernel crypto is not planned by default, so there should be no impact on most users. Users enabling kernel crypto may need to import existing long-term private or secret keys (SSL private keys in particular) into a different key storage mechanism.

ioctl interface man page describes the low-level interface; most applications should use the implementation through one of the existing crypto libraries, or through the new <ncrypto.h> library, not directly.

The kernel implementation of cryptographic algorithms is available to user-space programs, so that they do not need to handle encryption keys directly and the keys are protected from user-space exploits. [If implemented: Applications using SSL/TLS through [list of libraries] automatically take advantage of this feature.]