GSoc2010 project suggestion: replacement software crypto provider

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