Do yourself a favor and just have one of the OpenSSL crypto experts do the function on a consulting basis. Will save you a lot of time, and misery! And it will be crypto correct.
Ken > > There are a few other complications which you may not be aware of. > > But I am terrified that they exist. I'm a generic multiplatform network > applications type, not a crypto geek. > > > Under CryptoAPI you can't directly set the actual key. There are various > > tricks involving things like exponent of one RSA keys to get round this > > though. > > I realized this. I feed it the hash, it makes a key. Cool, unless you need > to replicate the "it makes a key" using OpenSSL. > > > OpenSSL allows you to set the actual key and has support for various > standard > > key derivation algorithms like PKCS#12 or PKCS#5v2.0 . > > (I'd rant about the OpenSSL man pages, but I'd be off my own topic.) > > Since my first post, I've tripped PKCS#5v2.0; I guess my primary comment > would be that the OpenSSL DES/EVP pages don't make it clear what is used for > what ... for example that PKCS includes the key generation routines that may > not be public key. > > > Its advisable to use the EVP interface on OpenSSL rather the the low level > > routines. > > I realize that. But I didn't see the obvious path way to do using the low > level or EVP routines. > > > It isn't a good idea to just make up a key derivation algorithm: there are > > lots of these about that are horribly insecure. Many don't even use a salt > > which makes them vulnerable to attack. > > I wasn't planning to. I know of weaknesses (which I won't advertise) in > exactly what I'm doing, but it's a major improvement on the "simply XOR > against a fixed key" which the current implementation does. I prefer not > add more *unknown* weaknesses. > > (All this is a mere fallback to running the whole sebang over SSL from > client to server -- and I'm using SHA1 passwords when possible, which is > whenever not calling external authenication facilities.) > > > What this means for 3DES is that there isn't a common password based key > > derivation algorithm. The solution would be to implement one in either > > CryptoAPI or OpenSSL. For example you could implement PKCS#5 v2.0 under > > CryptoAPI or even the odd 3DES derivation algorithm under OpenSSL. > > Have you seen the Secure Programming Cookbook for C and C++ (by Viega & > Messier, from O'Reilly)? I'm looking at recipe (section) 4.10, which has > PKCS#5 for Windows and OpenSSL. Of course, that leads off other parts of > the book, so back to my reading ... > > -ahd- > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __________________________________________________ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-398-0221 [EMAIL PROTECTED] http://www.securenetterm.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
