GSoc2010 project suggestion: replacement software crypto provider

[Thor Lancelot Simon <tls%panix.com@localhost>]

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