William A. Rowe, Jr. wrote:
All do know that crypto in Windows is .NET only from now on? http://blogs.msdn.com/karinm/archive/2009/01/19/capicom-dll-removed-from-windows-sdk-for-windows-7.aspx* common API to access functionality (dbd, ldap, crypto)So will APR crypto be .NET aware from now on too?If true; we'll likely substitute openssl in APR. Would solve des_crypt as well. But I'm not certain we really care, the primitives below capicom we use, capicom itself we don't.
There are right now two implementations of the crypto API in apr_util, one for OpenSSL, and a second for Mozilla NSS.
I am keen to get a third implementation in there, native Windows crypto support (it would take the form of another optional module), but I don't have access to a Windows development environment.
When I have some time, we could potentially add gnutls support as well.Right now the test cases for crypto test that data encrypted by module A can be successfully decrypted by module B: this is one of the key design goals of the apr_crypto interface: drop in any module relevant to the platform, and it should interoperate seamlessly with code running on other machines/architectures. As it turns out, interoperability between OpenSSL and NSS isn't very good, despite the fact they both are supposed to implement standards.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
