> From: [email protected] On Behalf Of Rajib Karmakar > Sent: Thursday, 29 September, 2011 07:22
> The problem was with the install path. When we don't mention > "--prefix", > OpenSSL is installed in some other path. And does not update > the already > installed binaries. Thus I was actually using the older > binary in my past > tests. > As I suspected. Good that part is solved. > However I am still unable to use two ciphers > 'RSA_EXPORT1024_WITH_RC4_56_MD5' and > 'RSA_EXPORT1024_WITH_RC2_CBC_56_MD5'. As I said, twice: those two are '#if 0'ed, so for them you must set the ALLOW macro and also patch s3_lib.c . It appears this is because they are even more nonstandard. > Though succeeded in having the SHA variant of the > Export1024_rc4 cipher. I > am also facing some trouble with another RC2 cipher > (RSA_EXPORT_WITH_RC2_CBC_40_MD5). Is the RC2 cipher support > unavailable in > this library? > RC2 is certainly implemented. Like most algorithms, it CAN be disabled in config (or Configure) but is enabled by default, and you are using the default. (At least once you get your new build; a distro package may well have disabled it.) That suite (EXP-RC2-CBC-MD5) works in my 1.0.0e (and others). Old EXPort suites are 512-bit PKC (RSA or DH), so unless you have a 512-bit RSA cert (which would be grossly insecure and basically useless) this suite needs a temporary RSA key. s_server does this automatically, but if you are writing the code it must set either a key or a callback to provide one. RSA key generation requires (more) entropy and is relatively costly; I would not expect these to be a problem on Linux but conceivably they could be. What exactly is "trouble"? ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
