Re: question about compiling in windows XP
Start, Programs, Visual Studio.NET 2003, Visual Studio Tools, Visual Studio.NET 2003 Command Prompt Its a Dos Box with the environment variables/paths setup to run the VS tools. Mark wrote: I am using MS Visual Studio 2003, and am trying to compile OpenSSL 0.9.7g. I am following the instructions provided in the file - INSTALL.W32. I get to the point where the instructions say: Then from the VC++ environment at a prompt do: nmake -f ms\ntdll.mak I am not sure how to run this from a command prompt in Visual Studio, since I cannot find a Visual Studion workspace or project file in which to open the OpenSSL project. What am I not doing right ?? Thanks in advance. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Problem in compiling openssl 0.9.7g on Windows with MSVC workspace
From the looks of it you are missing some include files. Search the source for where those symbols are defined. Get those include files into your project. BTW, why not just link to the libs? You could even link statically. Sean Francois PIETTE wrote: Am i the only one still using MSVC workspace ? Can someone give a look at my message below ? -- [EMAIL PROTECTED] The author for the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: Francois PIETTE [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Thursday, June 02, 2005 6:37 PM Subject: Re: Problem in compiling openssl 0.9.7g on Windows with MSVC workspace I have the exact same problem and can't fix it. Can someone give a step by step procedure to fix the problem ? Or maybe correct MSVC workspace exist somewhere ? btw: Compiling works OK when using the make file. It only fails as explained below when using MSVC workspace. -- [EMAIL PROTECTED] The author for the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: ahmad hassan [EMAIL PROTECTED] To: openssl-users@openssl.org Cc: [EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 1:20 PM Subject: Problem in compiling openssl 0.9.7g on Windows Hello, I am trying to build openssl 0.9.7g on windows, which i was successfully able to do using steps mentioned in INSTALL.W32 file. Now i would like to include libeay32 and ssleay32 source code as a workspace in my Visual C++ 6.0 project. For that i went to http://www.openssl.org/related/ and the second link gave me the dsp to use and compile openssl source code through vc++ environment. It is actually so that i had openssl 0.9.7d with me which i downloaded a year ago and compiled it using this visual studio project file but now it is not compiling with the latest version giving me messages like this. There is some problem with proxy certifiactes thing. How do i reslove these errors. Some are just defined in the libeay32.def file which i removed but PROXY_CERT_INFO_EXTENSION_free is not declared anywhere and is being used in number of places like openssl-0.9.7g\crypto\x509\x509_vfy.c etc. Can anyone guide me or give me related information regarding how to include latest openssl version as workspace in my project. Configuration: libeay32 - Win32 Debug Linking... libeay32.def : error LNK2001: unresolved external symbol PROXY_CERT_INFO_EXTENSION_free libeay32.def : error LNK2001: unresolved external symbol PROXY_CERT_INFO_EXTENSION_it libeay32.def : error LNK2001: unresolved external symbol PROXY_CERT_INFO_EXTENSION_new libeay32.def : error LNK2001: unresolved external symbol PROXY_POLICY_free libeay32.def : error LNK2001: unresolved external symbol PROXY_POLICY_it libeay32.def : error LNK2001: unresolved external symbol PROXY_POLICY_new libeay32.def : error LNK2001: unresolved external symbol d2i_PROXY_CERT_INFO_EXTENSION libeay32.def : error LNK2001: unresolved external symbol d2i_PROXY_POLICY libeay32.def : error LNK2001: unresolved external symbol i2d_PROXY_CERT_INFO_EXTENSION libeay32.def : error LNK2001: unresolved external symbol i2d_PROXY_POLICY ..\..\out32dll\Debug/libeay32.lib : fatal error LNK1120: 10 unresolved externals LINK : fatal error LNK1141: failure during build of exports file Error executing link.exe. libeay32.dll - 12 error(s), 0 warning(s) Configuration: libeay32 - Win32 Debug _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager
Is this the Right Way?
I have an app that communicates over the Internet. I'm using the libeay32.dll for encryption. As we all know from WEP, using encryption doesn't mean its secure. Can you take a min. at look at how I've implemented this and tell me if its secure? Thanks! The user has a fixed 8 character password (bad, I know, I don't control that part.) someSalt and theIV are 16 bytes (128 bit). rand_bytes() is used to init someSalt and theIV. I use the following code to create a session key, and setup the encryption context: EVP_BytesToKey(EVP_aes_128_ofb(), EVP_md5(), (unsigned char *)someSalt, (const unsigned char *)password, datal, count, keystr, theIV); EVP_CIPHER_CTX_init(ctx); EVP_CipherInit_ex(ctx, EVP_aes_128_ofb(), NULL, keystr, theIV, 1); When the first message is passed, server to client, I send the following: someSalt|theIV|encryptedMessage When the client gets the first message, it gets the password from the user, gets someSalt and theIV off the incoming message, and then uses the same chunk of code to generate the key: EVP_BytesToKey(EVP_aes_128_ofb(), EVP_md5(), (unsigned char *)someSalt, (const unsigned char *)password, datal, count, keystr, theIV); EVP_CIPHER_CTX_init(ctx); EVP_CipherInit_ex(ctx, EVP_aes_128_ofb(), NULL, keystr, theIV, 1); From then on the client and server only send the encryptedMessage, since someSalt and theIV have already done their job. When the return socket is created, it uses the same procedure, but a new SALT and IV. The two sockets in the duplex communication use different session keys. Am I doing anything wrong? Thanks, Sean __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Using RC4 vs EVP_CIPHER
Steve,
Salt shouldn't be predictable so using a fixed string isn't an option but it
isn't secret.
I'm using rand_bytes() to create the salt.
IV. I should really use an IV with some modes. Again, its random
bytes, but it doesn't have to be secret. I will also have to transmit
the IV to the other side. That's not a security problem is it?
Is is a problem if you use the same random bytes for the SALT and the IV?
EVP_BytesToKey() also generates an IV so that isn't a problem.
I'm attempting to use EVP_aes_128_ofb(). OFB mode should have an IV.
I'm passing in 16 char of rand_bytes to EVP_CipherInit_ex(). Currently
I'm not passing the IV to the other side. I would expect the decryption
to fail since the client and the server aren't using the save IV. Its
doesn't fail. This leads me to believe that the cipher isn't actually
using the IV. What am I missing?
int count = 0;
int datal = 0;
unsigned char * someSalt;
unsigned char * theIV;
if (!rand_seeded_p)
{
rand_seed();
rand_seeded_p = 1;
}
//setup the salt for the password
someSalt = new unsigned char[saltSize];
rand_bytes(someSalt,saltSize);
theIV = new unsigned char[saltSize];
rand_bytes(theIV,saltSize);
//hash the password into a 128bit key
datal = (unsigned long)strlen((const char *)password);
EVP_BytesToKey(EVP_aes_128_ofb(), EVP_md5(), (unsigned char *)
someSalt, (const unsigned char *)password, datal, count, keystr, NULL);
EVP_CIPHER_CTX_init(ctx);
EVP_CipherInit_ex(ctx, EVP_aes_128_ofb(), NULL, NULL, NULL, 1);
/* We finished modifying parameters so now we can set key and IV */
EVP_CipherInit_ex(ctx, NULL, NULL, keystr, theIV, 1);
Thanks,
Sean
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Using RC4 vs EVP_CIPHER
Steve, Additionally you seem to be using an unsalted key derivation algorithm with a stream cipher (RC4). If passwords are reused then I hope you aren't sending anything sensitive that way because that is an insecure combination. Additional Questions: SALT isn't secret, correct? In this app I'm going to have to send the SALT to the other end in order for the passwords to be the same...This isn't a problem, is it? IV. I should really use an IV with some modes. Again, its random bytes, but it doesn't have to be secret. I will also have to transmit the IV to the other side. That's not a security problem is it? Is is a problem if you use the same random bytes for the SALT and the IV? Thanks, Sean P.S. The books I have are pretty clear on the IV issue, but don't really get into much details on SALT, and none mention if IV=SALT would be a bad thing. Good point. I assume what I really want to use is EVP_BytesToKey to create the key with salt. Thanks for the help! Sean __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Problem in compiling openssl 0.9.7g on Windows
Ahmad, ahmad hassan wrote: Hello, Yes you are right the libeay32.lib and ssleay32.lib will do the trick but i wanted to do it the way i had been using it. I need a little help I started to go this route too, but it got ugly in a hurry. You really need to track down and include all the individual files you need for a specific functionality offered by OpenSSL. You'll need to add the source directories (OpenSSL-0.9.7g, openssl-0.9.7g/crypto, 0.9.7g/ssl...and on and on) and then add all the needed *.c files... (and of course those paths will change from machine to machine and version to version) Then I though about compatibility with future versions and decided to just use the nice tools OpenSSL gave me. The fact that I was trying to maintain some code someone else wrote that had already pulled in a few files from OpenSSL made the problem clear to me pretty quickly. Some low-level functions had changed parameters and types. It was painful updating. Using the higher level functions from the library will be much simpler to maintain. regarding that and the link error to get resolved. I also would like to ask you a little question if i am a client and using opensssl 0.9.7d and server is using new lib i.e. openssl 0.9.7g would there be issuses I don't know about the versions being compatible, but why risk it? Also, there are more (security) reasons to upgrade to the latest version. arising or they are backward compatible. I am actually using it for ftp over ssl. It shouldn't happen that application hangs for some SSL_Read etc. Do you want to spend time debugging OpenSSL version compatibility issues, or writing your application? I'd recommend getting everyone up on the same version, just for your sanity. Especially if you have control over the environments. I'm sure some long-time users can discuss the compatibility details, but that's my own personal feeling about using different versions together... Sean Regards, Ahmad. From: Sean Covel [EMAIL PROTECTED] Reply-To: openssl-users@openssl.org To: openssl-users@openssl.org CC: [EMAIL PROTECTED] Subject: Re: Problem in compiling openssl 0.9.7g on Windows Date: Thu, 05 May 2005 10:03:37 -0400 Can't you just include libeay32.lib and ssleay32.lib in your project as additional libraries? The you just need to add the path to those libs and you're done. I looked at the project on that site and its old, and all it does is compile the libraries in the VC++ GUI, instead of using the nice scripts provided by OpenSSL. What's the point? Sean ahmad hassan wrote: Hello, What's the matter. Nobody is doing what is mentioned below or people don't reply back on this group. Thank You. From: ahmad hassan [EMAIL PROTECTED] Reply-To: openssl-users@openssl.org To: openssl-users@openssl.org CC: [EMAIL PROTECTED] Subject: Problem in compiling openssl 0.9.7g on Windows Date: Tue, 03 May 2005 16:20:38 +0500 Hello, I am trying to build openssl 0.9.7g on windows, which i was successfully able to do using steps mentioned in INSTALL.W32 file. Now i would like to include libeay32 and ssleay32 source code as a workspace in my Visual C++ 6.0 project. For that i went to http://www.openssl.org/related/ and the second link gave me the dsp to use and compile openssl source code through vc++ environment. It is actually so that i had openssl 0.9.7d with me which i downloaded a year ago and compiled it using this visual studio project file but now it is not compiling with the latest version giving me messages like this. There is some problem with proxy certifiactes thing. How do i reslove these errors. Some are just defined in the libeay32.def file which i removed but PROXY_CERT_INFO_EXTENSION_free is not declared anywhere and is being used in number of places like openssl-0.9.7g\crypto\x509\x509_vfy.c etc. Can anyone guide me or give me related information regarding how to include latest openssl version as workspace in my project. Configuration: libeay32 - Win32 Debug Linking... libeay32.def : error LNK2001: unresolved external symbol PROXY_CERT_INFO_EXTENSION_free libeay32.def : error LNK2001: unresolved external symbol PROXY_CERT_INFO_EXTENSION_it libeay32.def : error LNK2001: unresolved external symbol PROXY_CERT_INFO_EXTENSION_new libeay32.def : error LNK2001: unresolved external symbol PROXY_POLICY_free libeay32.def : error LNK2001: unresolved external symbol PROXY_POLICY_it libeay32.def : error LNK2001: unresolved external symbol PROXY_POLICY_new libeay32.def : error LNK2001: unresolved external symbol d2i_PROXY_CERT_INFO_EXTENSION libeay32.def : error LNK2001: unresolved external symbol d2i_PROXY_POLICY libeay32.def : error LNK2001: unresolved external symbol i2d_PROXY_CERT_INFO_EXTENSION libeay32.def : error LNK2001: unresolved external symbol i2d_PROXY_POLICY ..\..\out32dll\Debug/libeay32
Re: Problem in compiling openssl 0.9.7g on Windows
Can't you just include libeay32.lib and ssleay32.lib in your project as additional libraries? The you just need to add the path to those libs and you're done. I looked at the project on that site and its old, and all it does is compile the libraries in the VC++ GUI, instead of using the nice scripts provided by OpenSSL. What's the point? Sean ahmad hassan wrote: Hello, What's the matter. Nobody is doing what is mentioned below or people don't reply back on this group. Thank You. From: ahmad hassan [EMAIL PROTECTED] Reply-To: openssl-users@openssl.org To: openssl-users@openssl.org CC: [EMAIL PROTECTED] Subject: Problem in compiling openssl 0.9.7g on Windows Date: Tue, 03 May 2005 16:20:38 +0500 Hello, I am trying to build openssl 0.9.7g on windows, which i was successfully able to do using steps mentioned in INSTALL.W32 file. Now i would like to include libeay32 and ssleay32 source code as a workspace in my Visual C++ 6.0 project. For that i went to http://www.openssl.org/related/ and the second link gave me the dsp to use and compile openssl source code through vc++ environment. It is actually so that i had openssl 0.9.7d with me which i downloaded a year ago and compiled it using this visual studio project file but now it is not compiling with the latest version giving me messages like this. There is some problem with proxy certifiactes thing. How do i reslove these errors. Some are just defined in the libeay32.def file which i removed but PROXY_CERT_INFO_EXTENSION_free is not declared anywhere and is being used in number of places like openssl-0.9.7g\crypto\x509\x509_vfy.c etc. Can anyone guide me or give me related information regarding how to include latest openssl version as workspace in my project. Configuration: libeay32 - Win32 Debug Linking... libeay32.def : error LNK2001: unresolved external symbol PROXY_CERT_INFO_EXTENSION_free libeay32.def : error LNK2001: unresolved external symbol PROXY_CERT_INFO_EXTENSION_it libeay32.def : error LNK2001: unresolved external symbol PROXY_CERT_INFO_EXTENSION_new libeay32.def : error LNK2001: unresolved external symbol PROXY_POLICY_free libeay32.def : error LNK2001: unresolved external symbol PROXY_POLICY_it libeay32.def : error LNK2001: unresolved external symbol PROXY_POLICY_new libeay32.def : error LNK2001: unresolved external symbol d2i_PROXY_CERT_INFO_EXTENSION libeay32.def : error LNK2001: unresolved external symbol d2i_PROXY_POLICY libeay32.def : error LNK2001: unresolved external symbol i2d_PROXY_CERT_INFO_EXTENSION libeay32.def : error LNK2001: unresolved external symbol i2d_PROXY_POLICY ..\..\out32dll\Debug/libeay32.lib : fatal error LNK1120: 10 unresolved externals LINK : fatal error LNK1141: failure during build of exports file Error executing link.exe. libeay32.dll - 12 error(s), 0 warning(s) Configuration: libeay32 - Win32 Debug _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] _ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Using RC4 vs EVP_CIPHER
Steve, Dr. Stephen Henson wrote: [snip] Here are the relevant chunks for code. I'm trying to give enough code without over-burdening you. If you need more, let me know. [snip] Here's one problem: EVP_CIPHER_CTX_set_key_length(Dctx, 128); the length parameter is in bytes not bits. Thanks. Easy enough to fix. Additionally you seem to be using an unsalted key derivation algorithm with a stream cipher (RC4). If passwords are reused then I hope you aren't sending anything sensitive that way because that is an insecure combination. Good point. I assume what I really want to use is EVP_BytesToKey to create the key with salt. Thanks for the help! Sean __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Using ripemd160 causes nonvalid digital signature CA
Windows 2003 Server, SP1. List of Crypto Providers: Listing Provider 'Default' 1 Algorithm Name Default Key len Min lenMax len RC2 128 40 128 RC4 128 40 128 DES 56 56 56 3DES TWO KEY 112 112112 3DES 168 168168 SHA-1160 160160 MD2 128 128128 MD4 128 128128 MD5 128 128128 SSL3 SHAMD5 288 288288 MAC 00 0 RSA_SIGN 1024 38416384 RSA_KEYX 1024 38416384 HMAC 00 0 Listing Provider 'Default' 3 Algorithm Name Default Key len Min lenMax len SHA-1160 160160 MD5 128 128128 DSA_SIGN 1024 5121024 Listing Provider 'Default' 5 Algorithm Name Default Key len Min lenMax len 3DES 168 168168 3DES 112 112112 RC2 128 40 128 DES 56 56 56 SHA-1160 160160 MD5 128 128128 MAC 64 64 64 HMAC 160 160160 RSA_KEYX 512 512512 RSA_SIGN 512 512512 Listing Provider 'Default' 12 Algorithm Name Default Key len Min lenMax len RC2 128 40 128 RC4 128 40 128 DES 56 56 56 3DES TWO KEY 112 112112 3DES 168 168168 SHA-1160 160160 MD5 128 128128 SSL3 SHAMD5 288 288288 MAC 00 0 RSA_SIGN 1024 38416384 RSA_KEYX 1024 38416384 HMAC 00 0 PCT1 MASTER 128 128128 SSL2 MASTER 40 40 192 SSL3 MASTER 384 384384 TLS1 MASTER 384 384384 SCH MASTER HASH 00 -1 SCH MAC KEY 00 -1 SCH ENC KEY 00 -1 Listing Provider 'Default' 13 Algorithm Name Default Key len Min lenMax len CYLINK MEK 40 40 40 RC2 128 40 128 RC4 128 40 128 DES 56 56 56 3DES TWO KEY 112 112112 3DES 168 168168 SHA-1160 160160 MD5 128 128128 DSA_SIGN 1024 5121024 DH_KEYX 1024 5124096 DH_KEYX 1024 5124096 Listing Provider 'Default' 18 Algorithm Name Default Key len Min lenMax len CYLINK MEK 40 40 40 RC2 40 40 128 RC4 40 40 128 DES 56 56 56 3DES TWO KEY 112 112112 3DES 168 168168 SHA-1160 160160 MD5 128 128128 DSA_SIGN 1024 5121024 DH_KEYX 512 5124096 DH_KEYX 512 5124096 SSL3 MASTER 384 384384 TLS1 MASTER 384 384384 SCH MASTER HASH 00 -1 SCH MAC KEY 00 -1 SCH ENC KEY 00 -1 Listing Provider 'Microsoft Enhanced Cryptographic Provider v1.0' 1 Algorithm Name Default Key len Min lenMax len RC2 128 40 128 RC4 128 40 128 DES 56 56 56 3DES TWO KEY 112 112112 3DES 168 168168 SHA-1160 160160 MD2 128 128128 MD4 128 128128 MD5
Re: 0.9.7g doesn't compile on Win32
Steve, Dr. Stephen Henson wrote: I was able to build 0.9.7f for Win32 successfully. Downloaded and tried to build 0.9.7g, and its a no-go. Is there a working mak file for Win32 for 0.9.7g? Compiles with no problems here. I'm assuming you are using VC++ since you mention ntdll.mak. Yup. Possible causes could be extracting in text mode resulting in CRLF for EOL or your version of perl doesn't build the makefiles properly. Doh! Don't know what I did differently extracting the 9g tarball, but you are correct. I ran unix2dos, and now everything compiles fine. Sean Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Using RC4 vs EVP_CIPHER
Now that I've updated to the latest OpenSSL (7g) I've got a question:
I implemented some RC4 functionality using the low-level rc4 functions.(
RC4_Set_Key, RC4), and its working fine.
The OpenSSL documentation recommends using the EVP_* functions instead
of the lower level functions. It seems like it might give easy access
to additional functionality, so I'm converting.
Here's the problem. When I switched the code from RC4 to EVP, the
program broke, in a big way. The project freezes and I have to either
logout or shutdown in order to get Visual Studio 6 to die. If I'm
REALLY patient (and I'm not) I can eventually get Task Manager to come
up, and then click on msdev.exe (and then wait.) and then click on
end-process (and wait) and then click on OK (and wait). You get the
idea.
A brief explanation of what the code is doing. The code is a plugin for
another program. The program initializes the plugin, passes it a
password, and then starts handing it chunks of text to encrypt. The
program has a socket open to another identical program, doing the same
thing on the other side. Kinda like a chat program. The encrypt key
is for sending, the decrypt key is for receiving. All the plugin knows
is the key, the input/output buffer, and the length of the chunk.
I have the RC4 code and the EVP code both in there. They are controlled
by a #define.
Here are the relevant chunks for code. I'm trying to give enough code
without over-burdening you. If you need more, let me know.
unsigned char keystr[MD5_DIGEST_LENGTH];
#ifdef EVP
EVP_CIPHER_CTX Ectx;
EVP_CIPHER_CTX Dctx;
#else
RC4_KEY Ekey;
RC4_KEY Dkey;
#endif
unsigned char iv[] = 12345678;
PLUGIN_API int Startup(void)
{
//hash the password into a 128bit key
EVP_Digest((unsigned char *)szExternalKey,(unsigned
long)strlen((const char *)szExternalKey),keystr,NULL,EVP_md5(),NULL);
#ifdef EVP
EVP_CIPHER_CTX_init(Ectx);
EVP_CipherInit_ex(Ectx, EVP_rc4(), NULL, NULL, NULL, 1);
EVP_CIPHER_CTX_set_key_length(Ectx, 128);
EVP_CipherInit_ex(Ectx, NULL, NULL, keystr, iv, 1);
EVP_Digest((unsigned char *)szExternalKey,(unsigned
long)strlen((const char *)szExternalKey),keystr,NULL,EVP_md5(),NULL);
EVP_CIPHER_CTX_init(Dctx);
EVP_CipherInit_ex(Dctx, EVP_rc4(), NULL, NULL, NULL, 0);
EVP_CIPHER_CTX_set_key_length(Dctx, 128);
EVP_CipherInit_ex(Dctx, NULL, NULL, keystr, iv, 0);
#else
RC4_set_key(Ekey,MD5_DIGEST_LENGTH,keystr);
RC4_set_key(Dkey,MD5_DIGEST_LENGTH,keystr);
#endif
}
PLUGIN_API BYTE* TransformBuffer(BYTE* pDataBuffer, int nDataLen, int*
pnTransformedDataLen)
{
int dwByteCount = 0;
BYTE* pTransBuffer =
CheckLocalTransBufferSize(GiveTransDataLen(nDataLen));
if (pTransBuffer == NULL)
{
*pnTransformedDataLen = -1;
return NULL;
}
#ifdef EVP
if(!EVP_CipherUpdate(Ectx, pTransBuffer, dwByteCount,
pDataBuffer, nDataLen))
{
// Error
PrintLog((DEST,TransformBuffer failed));
return NULL;
}
#else
RC4(Ekey,nDataLen,(unsigned char *)pDataBuffer,(unsigned char
*)pTransBuffer);
#endif
// return the transformed data length
*pnTransformedDataLen = GiveTransDataLen(nDataLen);
return pTransBuffer;
}
PLUGIN_API BYTE* RestoreBuffer(BYTE* pRestoredDataBuffer, int nDataLen,
int* pnRestoredDataLen)
{
int dwByteCount = 0;
if (pRestoredDataBuffer == NULL)
{
// Give the size of the transformed data buffer, based
on the original data length
*pnRestoredDataLen = GiveRestDataLen(nDataLen);
// Ensure the pLocalRestBuffer that receive transformed data is
big enough
BYTE* pBuffer = CheckLocalRestBufferSize(*pnRestoredDataLen);
return pBuffer;
}
#ifdef EVP
if(!EVP_CipherUpdate(Dctx, pRestoredDataBuffer, dwByteCount,
pLocalRestBuffer, nDataLen))
{
// Error
PrintLog((DEST,RestoreBuffer failed));
return NULL;
}
#else
RC4(Dkey,nDataLen,(unsigned char *)pLocalRestBuffer,(unsigned char
*)pRestoredDataBuffer);
#endif
// return the resulting data length
*pnRestoredDataLen = GiveRestDataLen(nDataLen);
return pLocalRestBuffer;
}
PLUGIN_API int Shutdown(void)
{
// Cleanup everything
#ifdef EVP
EVP_CIPHER_CTX_cleanup(Ectx);
EVP_CIPHER_CTX_cleanup(Dctx);
#endif
return 1;
}
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Using RC4 vs EVP_CIPHER
I'm continuing to test. I've noticed something else strange with the
EVP_ functions...
I have a test program that reads in text file A a chunk at a time,
encrypts the chunk, then writes it out to B. It then reads B back
in a chunk at a time, decrypts it, and writes it back out to C.
Simple test. If A == C its working.
I'm using RC4, a stream cipher. Technically there is no block size.
If I set the chunk size to 2048, all is well. If I set it to 50, all
is well. 49, good. 48, BAD!!! If I use 48 or below, it doesn't work.
Encrypting with EVP_CipherUpdate APPEARS to be working.
Decryption with EVP_CipherUpdate returns 1, meaning success, but the
output is not decrypted, its just further garbled.
My plugin application has LOTS of small chunks, and a few larger chunks
getting sent. This might explain why its not working.
Ring any bells?
Sean
Sean Covel wrote:
Now that I've updated to the latest OpenSSL (7g) I've got a question:
I implemented some RC4 functionality using the low-level rc4 functions.(
RC4_Set_Key, RC4), and its working fine.
The OpenSSL documentation recommends using the EVP_* functions instead
of the lower level functions. It seems like it might give easy access
to additional functionality, so I'm converting.
Here's the problem. When I switched the code from RC4 to EVP, the
program broke, in a big way. The project freezes and I have to either
logout or shutdown in order to get Visual Studio 6 to die. If I'm
REALLY patient (and I'm not) I can eventually get Task Manager to come
up, and then click on msdev.exe (and then wait.) and then click on
end-process (and wait) and then click on OK (and wait). You get the
idea.
A brief explanation of what the code is doing. The code is a plugin for
another program. The program initializes the plugin, passes it a
password, and then starts handing it chunks of text to encrypt. The
program has a socket open to another identical program, doing the same
thing on the other side. Kinda like a chat program. The encrypt key
is for sending, the decrypt key is for receiving. All the plugin knows
is the key, the input/output buffer, and the length of the chunk.
I have the RC4 code and the EVP code both in there. They are controlled
by a #define.
Here are the relevant chunks for code. I'm trying to give enough code
without over-burdening you. If you need more, let me know.
unsigned char keystr[MD5_DIGEST_LENGTH];
#ifdef EVP
EVP_CIPHER_CTX Ectx;
EVP_CIPHER_CTX Dctx;
#else
RC4_KEY Ekey;
RC4_KEY Dkey;
#endif
unsigned char iv[] = 12345678;
PLUGIN_API int Startup(void)
{
//hash the password into a 128bit key
EVP_Digest((unsigned char *)szExternalKey,(unsigned
long)strlen((const char *)szExternalKey),keystr,NULL,EVP_md5(),NULL);
#ifdef EVP
EVP_CIPHER_CTX_init(Ectx);
EVP_CipherInit_ex(Ectx, EVP_rc4(), NULL, NULL, NULL, 1);
EVP_CIPHER_CTX_set_key_length(Ectx, 128);
EVP_CipherInit_ex(Ectx, NULL, NULL, keystr, iv, 1);
EVP_Digest((unsigned char *)szExternalKey,(unsigned
long)strlen((const char *)szExternalKey),keystr,NULL,EVP_md5(),NULL);
EVP_CIPHER_CTX_init(Dctx);
EVP_CipherInit_ex(Dctx, EVP_rc4(), NULL, NULL, NULL, 0);
EVP_CIPHER_CTX_set_key_length(Dctx, 128);
EVP_CipherInit_ex(Dctx, NULL, NULL, keystr, iv, 0);
#else
RC4_set_key(Ekey,MD5_DIGEST_LENGTH,keystr);
RC4_set_key(Dkey,MD5_DIGEST_LENGTH,keystr);
#endif
}
PLUGIN_API BYTE* TransformBuffer(BYTE* pDataBuffer, int nDataLen, int*
pnTransformedDataLen)
{
int dwByteCount = 0;
BYTE* pTransBuffer =
CheckLocalTransBufferSize(GiveTransDataLen(nDataLen));
if (pTransBuffer == NULL)
{
*pnTransformedDataLen = -1;
return NULL;
}
#ifdef EVP
if(!EVP_CipherUpdate(Ectx, pTransBuffer, dwByteCount,
pDataBuffer, nDataLen))
{
// Error
PrintLog((DEST,TransformBuffer failed));
return NULL;
}
#else
RC4(Ekey,nDataLen,(unsigned char *)pDataBuffer,(unsigned char
*)pTransBuffer);
#endif
// return the transformed data length
*pnTransformedDataLen = GiveTransDataLen(nDataLen);
return pTransBuffer;
}
PLUGIN_API BYTE* RestoreBuffer(BYTE* pRestoredDataBuffer, int nDataLen,
int* pnRestoredDataLen)
{
int dwByteCount = 0;
if (pRestoredDataBuffer == NULL)
{
// Give the size of the transformed data buffer, based
on the original data length
*pnRestoredDataLen = GiveRestDataLen(nDataLen);
// Ensure the pLocalRestBuffer that receive transformed data is
big enough
BYTE* pBuffer = CheckLocalRestBufferSize(*pnRestoredDataLen);
return pBuffer;
}
#ifdef EVP
if(!EVP_CipherUpdate(Dctx, pRestoredDataBuffer, dwByteCount,
pLocalRestBuffer, nDataLen
0.9.7g doesn't compile on Win32
Hi! New to the list. I was able to build 0.9.7f for Win32 successfully. Downloaded and tried to build 0.9.7g, and its a no-go. First problem, there are a bunch of \\ in the ntdll.mak file, like $(INCL_D)\apps\\.h I tried to edit all those out, but even after that it wouldn't build. (error is: don't know how to make '.\apps.h') I then copied the ntdll.mak file from 0.9.7f, and tried building that. Unfortunately too many things changed between versions, and that fails too. (linker, unresolved external symbols) Is there a working mak file for Win32 for 0.9.7g? Sean __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
