RE: Generating rsakey using openssl as lib
From: owner-openssl-us...@openssl.org On Behalf Of Leonardo Laface de Almeida Sent: Tuesday, 16 October, 2012 17:06 Does your library dynamically-link the openssl libs, or statically embed them (while being dynamic itself)? library dynamically-link the openssl libs. My lib already uses SSL_CTX_* and SSL_* for connections. The certificates and the private keys are created directly from Openssl prompt (DOS or linux terminal). Because the App can't load the library with the following lines on dll code: 1. EVP_PKEY_CTX *ctx; 2. EVP_PKEY *pkey = NULL; 3. ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL); If the third line is commented, then the library is loaded and everything works. If you are dynamic-linking openssl libs (as well as your lib), are you sure when your app runs it is finding the correct ones? Unfortunately, yes. My lib finds the openssl libs, even though, it establishes SSL connections. That doesn't prove it's finding the *correct* openssl. Most (and usual) kinds of SSL connections work on older versions. Do you get TLSv1.1 or TLSv1.2 connections, or at least request them properly even if your server doesn't agree? That would prove version 1.0.1. Could there be an older version of openssl in your search path? The EVP_PKEY_CTX_* routines were new in 1.0.0. If you are finding a version older than that, they will be missing. There were, and I've actualized. From prompt: OpenSSL version OpenSSL 1.0.1c 10 May 2012 From path: C:\Openssl\bin That doesn't prove it either. The DLL search for openssl.exe could find different DLL files than for yourapp.exe, unless (probably) *everything* is all in one directory, and from what you say below it doesn't sound like everything is. Does your app run briefly and exit, or does/can it wait or do something that takes a reasonably long time? If the latter, get ProcessExplorer from technet.microsoft.com/en-us/sysinternals and use it to examine your running application process to check the full paths of the DLLs used. (Or there are other tools that can do this, but ProcessExplorer is the one I am familar with.) From C:\My_LIB_proj\lib\Openssl\include\openssl\opensslv.h #define OPENSSL_VERSION_TEXT OpenSSL 1.0.1c 10 May 2012 For Windows note that the DLL search rules have changed several times over the last year or so as Microsoft puts out more and more security patches for DLL planting attacks. Well, I'm developing the lib for Windows first. What I use from OS are separated in different source files. Almost everything is in c pure, except some things it isn't possible, as threads, for example. I suppose this part it will be easier on linux. :) Different in some details but not necessarily easier. :-( It seems to be an error with some pointer from EVP_* functions. Any EVP_* function called causes this error. Sounds like reference *to*, not pointer *from*. If the app/lib doesn't load, these function calls never get executed. All EVP_* or only all EVP_PKEY_CTX_* ? Most other parts of EVP_ are quite a bit older, although there have been minor changes. Yes, pointer to, sorry. Not allones, EVP_aes_256_cbc() and EVP_PKEY_get1_RSA(pkey) are working. EVP_PKEY_asn1_find_str() , EVP_PKEY_asn1_get0_info() and EVP_PKEY_CTX_new_id() are not working. I've not tried other ones. EVP_aes_ and SSL_various working but EVP_PKEY_CTX_ and EVP_PKEY_asn1_ not working does sound like a version problem. EVP_PKEY_CTX_ (as asked before) and also EVP_KEY_asn1_ are new in 1.0.0, and most other stuff is a good bit older. Anyway, as you said the EVC functions where recent development effort foccus, I think this may be some error in openssl lib. I also think it might be openssl version problem or some cross-compiling error. It sounds like it well could be a version problem. How is cross-compiling involved? I've downloaded the openssl*.tar file and extracted to C:/Openssl. Then, I've used Visual Studio 2010 for cross-compiling. I followed the instructions in INSTALL.W32 file (pretty good, by the way). Then, I've copied the following directories from C:\Openssl\ to C:\My_LIB_proj\lib\Openssl\: include lib Then, I've imported the libeay32.lib and ssleay32.lib as usual in c programming. I've also included C:\My_LIB_proj\lib\Openssl\include to included paths. Is something missing? That should be good for compiling and linking your app. Unless VS has changed recently, just adding an import .lib to a project is used for linking but does *not* make it run with the matching .dll, although other settings may do that. (I'm back on 2003, and MS changes this kind of stuff a lot.) Are you running your app in VS, or from CMD or similar? That may also affect the search rules. Note: this is not cross-compiling, just normal compiling. In any case, if it's possible I'm not importing or compiling the
RE: Generating rsakey using openssl as lib
I can't give you a total solution but Well, I've called SSLeay_version(SSLEAY_VERSION) from lib, and I've got OpenSSL 0.9.8a 11 Oct 2005. That's confirm it's a version problem. My question now is, what shall I make for removing all Openssl versions from my pc. After no OpenSSL installed or compiled, then I will start from beginning with version 1.0.1. Exactly! Welcome to the club. A good number of the products one trials or purchases over the years install their own copy of the OpenSSL DLLs *somewhere*. Use the Windows Start search function and key in ssleay32.dll and/or libeay32.dll and see how many hits you get! You could start by uninstalling or deleting any products you are sure you are not using. (Don't just delete them all!) Perhaps that will solve the problem. Else, you are *probably* going to get the correct DLL if you put it right in the same folder with your .exe. Copy your DLLs from wherever you built them to wherever you are building your application. It's a little complicated with VS because of the multiple folders: project, Debug, and Release -- but play around and you should be able to get it right. You are in my experience on the right track using SSLeay_version(). I would leave it in my code and printf the results on every execution. You never know when someone is going to install *something* and mess you up. Good luck! Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Leonardo Laface de Almeida Sent: Thursday, October 18, 2012 5:57 AM To: openssl-users@openssl.org Subject: RES: Generating rsakey using openssl as lib Hi, That doesn't prove it's finding the *correct* openssl. Most (and usual) kinds of SSL connections work on older versions. Do you get TLSv1.1 or TLSv1.2 connections, or at least request them properly even if your server doesn't agree? That would prove version 1.0.1. My lib is server for SSL connections. From SSL_get_version(ssl) after SSL_accept(ssl) I got the string: TLSv1. I got this connection using a web browser. This means it is TLS 1.0, write? Does your app run briefly and exit, or does/can it wait or do something that takes a reasonably long time? If the latter, get ProcessExplorer from technet.microsoft.com/en-us/sysinternals and use it to examine your running application process to check the full paths of the DLLs used. (Or there are other tools that can do this, but ProcessExplorer is the one I am familar with.) The application runs and doesn't exit. The App starts trying to load mylib. Without those functions (EVP_PKEY_CTX*), the App loads mylib and uses properly all exported functions. With those functions, the App can't load mylib. Then, no function from lib can be called. I can debug mylib and App. From both the behavior is the same. I've downloaded the openssl*.tar file and extracted to C:/Openssl. Then, I've used Visual Studio 2010 for cross-compiling. I followed the instructions in INSTALL.W32 file (pretty good, by the way). Then, I've copied the following directories from C:\Openssl\ to C:\My_LIB_proj\lib\Openssl\: include lib Then, I've imported the libeay32.lib and ssleay32.lib as usual in c programming. I've also included C:\My_LIB_proj\lib\Openssl\include to included paths. Is something missing? That should be good for compiling and linking your app. Unless VS has changed recently, just adding an import .lib to a project is used for linking but does *not* make it run with the matching .dll, although other settings may do that. (I'm back on 2003, and MS changes this kind of stuff a lot.) Are you running your app in VS, or from CMD or similar? That may also affect the search rules. Note: this is not cross-compiling, just normal compiling. I'm using QT Creator for both, App and Mylib. In linux, I will use the same IDE. Lib Configuration: win32:LIBS += -L$$PWD/lib/Openssl/lib -llibeay32 win32:LIBS += -L$$PWD/lib/Openssl/lib -lssleay32 INCLUDEPATH += $$PWD/lib/Openssl/lib DEPENDPATH += $$PWD/lib/Openssl/lib INCLUDEPATH += $$PWD/lib/Openssl/include DEPENDPATH += $$PWD/lib/Openssl/include Note: $$PWD - is path to C:/mylib/ For testing, I have pointed mylib to C:/Openssl/lib (instead of C:/MyLib/lib/Openssl/lib). I've got the same behavior as above. --- Well, I've called SSLeay_version(SSLEAY_VERSION) from lib, and I've got OpenSSL 0.9.8a 11 Oct 2005. That's confirm it's a version problem. My question now is, what shall I make for removing all Openssl versions from my pc. After no OpenSSL installed or compiled, then I will start from beginning with version 1.0.1. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Generating rsakey using openssl as lib
From: owner-openssl-us...@openssl.org On Behalf Of Leonardo Laface de Almeida Sent: Monday, 15 October, 2012 15:14 I was following the main function in genpkey.c file and following the same sequence for generating key pair. I've got some executing erros that took me some hours to get it. I still have the problem and I think it might be some errors in openssl libs. In fact, I'm developing a library (*.dll and *.so) that make SSL connectios [and other crypto] Does your library dynamically-link the openssl libs, or statically embed them (while being dynamic itself)? Because the App can't load the library with the following lines on dll code: 1. EVP_PKEY_CTX *ctx; 2. EVP_PKEY *pkey = NULL; 3. ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL); If the third line is commented, then the library is loaded and everything works. If you are dynamic-linking openssl libs (as well as your lib), are you sure when your app runs it is finding the correct ones? Could there be an older version of openssl in your search path? The EVP_PKEY_CTX_* routines were new in 1.0.0. If you are finding a version older than that, they will be missing. For Windows note that the DLL search rules have changed several times over the last year or so as Microsoft puts out more and more security patches for DLL planting attacks. Instead this three lines, with the next two lines the App can also load the dll and it works: 4. RSA *rsa; 5. rsa = RSA_new_method(NULL); Therefore, I'm developing using RSA_* functions now, and I think it will work just fine. Probably. It seems to be an error with some pointer from EVP_* functions. Any EVP_* function called causes this error. Sounds like reference *to*, not pointer *from*. If the app/lib doesn't load, these function calls never get executed. All EVP_* or only all EVP_PKEY_CTX_* ? Most other parts of EVP_ are quite a bit older, although there have been minor changes. Anyway, as you said the EVC functions where recent development effort foccus, I think this may be some error in openssl lib. I also think it might be openssl version problem or some cross-compiling error. It sounds like it well could be a version problem. How is cross-compiling involved? In any case, if it's possible I'm not importing or compiling the openssl libs properly, please let me know. Maibe some directive before compiling openssl, e.g. I'm using Openssl version 1.0.1c You're compiling openssl yourself? Are you installing it in the system directory(s), or using in your own dir(s)? If the latter, is there any openssl in the system dir(s)? The specific system directory(s) depend on your OS, and possibly build options. You imply you are doing at least Windows plus some Unix, which are different; if you do more than one Unix, those may also be different. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Generating rsakey using openssl as lib
From: owner-openssl-us...@openssl.org On Behalf Of Leonardo Laface de
Almeida
Sent: Thursday, 11 October, 2012 14:04
I have an application which already establishes SSL Socket connection
using OpenSSL as lib. Now, my application needs to able the user create
a RSA key pair, sign documents and verify signatures. This it will be
needed in some features of my application, managed by user for signing
docs and verifying signatures.
The point is not do this by prompt because it will force install openssl
in all computer which the application is installed. The idea is call some
function from Openssl lib already imported by my application in order to
create and use key pair.
I assume by prompt you mean the commandline aka utility executable
openssl (openssl.exe on Windows)? Note this executable can run with
input as commandline args or from a file or pipe without prompting.
If your application uses openssl as dynamic library(ies), as is the
usual configuration on most systems, you already need the openssl
library(ies) installed for your application to work. If so, presumably
you've already handled that, and that install probably could and
maybe did include the commandline executable.
But yes, everything significant openssl does is done by calling
library functions that your application(s) can call.
My question is, what's the better (or easier) way to make it happen?
A common standard way of doing signatures on data is CMS-formerly-PKCS7,
see thread PKCS7 open and extract signature just in the past few days.
I'm thinking in call the function which the openssl prompt calls, then,
Openssl lib will generate and store the key already in pem format,
into a directory specified by application. The same about sign docs
and verify signatures.
Almost. See RSA_generate_key to generate a key, or EVP_keygen*
for the new-1.0.0 more generic way, and PEM_write[_bio]_RSAPrivateKey
to write the specific legacy form or PEM_write[_bio]_PKCS8PrivateKey
for the (less new) generic form. And similarly to read back.
If these files are only stored locally and a human needn't look at them,
you could use DER format instead of PEM. But there's little benefit.
Other way it would be to call rsa functions directly and code it for pem
format.
You can call RSA_* directly, or you can use the generic EVP_* routines
with an RSA key, which is where recent development effort has focussed.
If you want CMS, openssl has a module for that (and for SMIME_,
which is really CMS under the covers), which actually uses EVP_*,
with routines to write and read the structure in PEM. If you design
your own structure, you'll need to implement it yourself, though openssl
can do base64 using a BIO (directly to/from a file, or in memory)
or just EVP_{en,de}code directly.
All of these are routines that commandline can use, depending on
the subcommand you choose and the arguments you give it.
I have no idea which one is easier or better. I'm reading openssl docs
and source code, but I'm still a bit lost how to make it works.
Hope this helps. If you have more specific questions ask again.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
