On 2008.12.19 at 14:03:46 -0500, Patrick Patterson wrote: > Ok - if you are asking if there is a generic "crypto" layer in Linux - the > answer is no. Today, there is a mix of applications that use their own crypto > (eg: parts of KDE, Java, others), applications that use OpenSSL (Apache, > Postfix, OpenLDAP, etc.), application that use GNUTLS, applications that use > NSS - Netscape Security Services (Evolution, OpenOffice (I think), Mozilla), > GPGSM (other parts of KDE), and the Kernel (several of the IPSec > implementations).
Things are even more complicated. Most of application software out there can be compile-time (or even runtime) configured to use different crypto libraries. Typically, there is a choice between OpenSSL and gcrypt/GNU TLS GPGSM is based on libgcrypt, so it uses same implementation of algorithms as GNU TLS. OpenOffice uses libxmlsec to sign documents, and this library can be compiled with any of three libraries mentioned, as well as MS CryptoProvider (on Windows platform) Most distributions of OpenOffice for Linux, however use NSS for crypto, because libnss contain own ready to use certificate and private key store (one which Firefox and Thunderbird use), and OpenSSL doesn't. Kernel support for cryptography, AFAIC doesn't include public key cryptography. There is no need for it. You need some userspace tool to perform connection initiation and certificate verification. And this tool is typically compiled with OpenSSL or NSS. And only fast simmetric ciphers and digests/macs need to be inside kernel for good fast IPSEC implementation. > add Java support), but in general, if you are adding primitives, then you've > got A LOT of places to go and add that support to). Realy there is even more work, because most application authors think that there is quite limited set of algorithms. Often some RSA specific routines, such as SSL_use_RSAPrivateKey_file are used in application code, where algorithm independent SSL_use_PrivateKey_file would do. Some other authors hardcode list of ciphersuites which do not include newly added ciphersuites implicitely. For example, couple of years ago I've to submit patches to PostgreSQL database to be able to use GOST ciphersuites with it. Fortunately, they included these patches in 8.3 release. So, if application uses a cryptographic library which supports needed algorithm (which is now a case with OpenSSL and Russian standard GOST algorithms), it doesn't mean, that you can just throw in correct keys and certificates and everything should work. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
