I think it's possible to combine the project Hubert suggeted with one I
suggested on the Wiki, in a way which might yield some benefit to almost
all users of opencrypto. Here is that attempt:
NetBSD uses the opencrypto(9) framework, derived from OpenBSD and
FreeBSD, to provide cryptographic services for the kernel. The
framework uses hardware accelleration where possible and software
elsewise. Software cryptography is provided by a module variously
known as "cryptosoft" or "swcrypto". This module is difficult to
maintain and has various performance issues. It should be replaced
in a way which increases functionality, does not harm performance,
and increases maintainability.
The replacement module should use standard implementations of
a reasonable (not exhaustive) set of popular cipher and hash/MAC
algorithms, drawn from another suitably licensed library such as
OpenSSL or LibTomCrypt. It should provide modular-arithmetic and
asymmetric-cryptography operations (opencrypto "key operations")
drawn from the same library. It should use the source library's
optimizations (assembler implementations, optimized cbc/counter
modes, etc) wherever possible.
The asymmetric operations should be implemented, if possible,
such that the standard API of the source library (particularly
the functions for RSA sign and verify operations) is also
directly available in the kernel.
A reasonable initial set of algorithms and modes would be:
AES128 in CBC mode
AES128 in CTR mode
SHA1
SHA2 (256, 384, and 512 bit sizes)
HMAC-SHAn (plain and 96-bit-truncated)
CRK_MOD_EXP
CRK_MOD_EXP_CRT
DEFLATE
GZIP
The replacement module should be able to operate in either a
synchronous (process request in the context in which it was
submitted) or asynchronous, multithreaded (enqueue requests for
later processing and return; dequeue in a processing thread
and return results as the hardware drivers do) mode, as selected
by the user at runtime. Ideally, it should determine the overhead
of the asynchronous mode for various operation sizes at startup
time, and, by default, dispatch asynchronously only those requests
which might actually complete fater.
Thor