Plugin own crypto routines with ssl
I have newly atrted working on the ssl.I do not know much about the way it works and its design also.I want to integrate my own crypto routines with the ssl. Someone please help me out __ Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Problem using Broadcom uBSec engine in 0.9.8
Hi, Further to Geoff's comments... To load an engine from a shared library with 0.9.8 you have to first load the dynamic engine. This is loaded by calling ENGINE_load_builtin_engines() (along with some others) or may be explicitly loaded with ENGINE_load_dynamic(). I noticed that your test app code does neither. Once the dynamic engine has been loaded you may set the dynamic engine load path as Geoff mentioned using the SO_PATH ctrl command if necessary before calling ENGINE_load_ubsec(); Hope this helps, Jon. > The problem is that if you do a "shared" build, the > engines are built as > shared-libraries too - that is, this is now the case > but wasn't under > 0.9.7. Your code is calling ENGINE_load_ubsec() > which doesn't exist in > libcrypto, because when you call > ENGINE_by_id("ubsec") it should fall > back to automatically searching the default path to > load the engine > shared lib (libubsec.so). Let me know if this isn't > the case, but from an > initial glance that seems to be what you're hitting. Do you Yahoo!? Find a local business fast with Yahoo! Local Search http://au.local.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Dynamic Engine problems with some 0.9.7x version
Hi, On October 24, 2005 11:50 am, Marco GRELLA wrote: > I have developed an OpenSSL Engine for our hw crypto accelerator. > I have no problems in using it as a dynamic engine with OpenSSL 0.9.8, > neither I have problems in loading it with OpenSSL 0.9.7d. > > But I get problems with 0.9.7g/i (so, I guess 'h' too) versions. Are you rebuilding the dynamic engine (lib) for each version you try to load against or did you build against one fixed version and try to load it against others? If the latter, which version did you build against? > Here I report the output I get: > > --- >--- [EMAIL PROTECTED] hwa_engine]# openssl097i engine dynamic -c - -pre > SO_PATH:/usr/local/ssl7i/lib/engines/libhwa.so -pre NO_VCHECK:1 -pre > ID:hwa -pre LIST_ADD:1 -pre LOAD > (dynamic) Dynamic engine loading support > [Success]: SO_PATH:/usr/local/ssl7i/lib/engines/libhwa.so > [Success]: NO_VCHECK:1 > [Success]: ID:hwa > [Success]: LIST_ADD:1 > [Failure]: LOAD > 4284:error:260B606D:engine routines:DYNAMIC_LOAD:init > failed:eng_dyn.c:433: SO_PATH: Specifies the path to the new ENGINE > shared library (input flags): STRING > NO_VCHECK: Specifies to continue even if version checking fails > (boolean) >(input flags): NUMERIC > ID: Specifies an ENGINE id name for loading >(input flags): STRING > LIST_ADD: Whether to add a loaded ENGINE to the internal list > (0=no,1=yes,2=mandatory) >(input flags): NUMERIC > LOAD: Load up the ENGINE specified by other settings >(input flags): NO_INPUT Why the NO_VCHECK? An engine lib built against 0.9.7x *should* load ok against any 0.9.7y (unless it doesn't, of course:-) but I think it's wise to assume this won't be the case between 0.9.7 and 0.9.8. If that's what you're trying, I wouldn't be surprised if you hit problems. Anyway, dig a little deeper if you can - if need be set a break point at or before eng_dyn.c:433 and go in a step it through. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ Self-interest and materialistic desire are parts of who we are, but not all. To base a social and economic system on these traits is dangerously fundamentalist. -- Joel Bakan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Problem using Broadcom uBSec engine in 0.9.8
On October 25, 2005 11:06 am, Martin Del Vecchio wrote: > I'm still looking for help with this problem. > > The uBSec support works in 0.9.7g with static linking. > The uBSec support works in 0.9.7g with shared libraries. > The uBSec support works in 0.9.8 with static linking. > The uBSec support fails in 0.9.8 with shared libraries. [snip] > Here is the command line I use to build the test program: > > gcc -o test test.c -I include ./libssl.a ./libcrypto.a -ldl > > It feels like this is such a major bug that it can't possibly be real, > and I must be doing something wrong. The problem is that if you do a "shared" build, the engines are built as shared-libraries too - that is, this is now the case but wasn't under 0.9.7. Your code is calling ENGINE_load_ubsec() which doesn't exist in libcrypto, because when you call ENGINE_by_id("ubsec") it should fall back to automatically searching the default path to load the engine shared lib (libubsec.so). Let me know if this isn't the case, but from an initial glance that seems to be what you're hitting. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ Self-interest and materialistic desire are parts of who we are, but not all. To base a social and economic system on these traits is dangerously fundamentalist. -- Joel Bakan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1226] DES_SPtrans in des_enc.m4: Text relocation remains against symbol
> great: -Bsymbolic solved the problem! > > I'll try to pass that information over to the apache httpd project, > because that's useful for anyone who wants to build apache 2 with > dynamic mod_ssl but with OpenSSL linked in statically. Note that it doesn't necessarily mean that there is nothing one can do in openssl code. On the contrary there is. It's possible to ensure that relocation problem *never* occurs. However! It should *not* discourage people from using -Bsymbolic. I mean -Bsymbolic is not just a cure for this particular problem, it's The Right Thing(tm) to do, which happens to fix this particular problem too. As for the "contrary." I have applied fix to development branch, http://cvs.openssl.org/chngview?cn=14547 and am closing this ticket. It also should fix a problem with outdated gnu assembler failing to compile the module in question. The fix can be backported to 0.9.8 if more people suffer. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1228] openssl/sha.h requires sys/types.h, but does not include it
The following trivial C file fails to compile in 0.9.8a: #include void foo(void) { } In file included from test.c:1: /usr/include/openssl/sha.h:109: error: syntax error before 'size_t' /usr/include/openssl/sha.h:111: error: syntax error before 'size_t' /usr/include/openssl/sha.h:116: error: syntax error before 'size_t' /usr/include/openssl/sha.h:118: error: syntax error before 'size_t' /usr/include/openssl/sha.h:138: error: syntax error before 'size_t' /usr/include/openssl/sha.h:140: error: syntax error before 'size_t' /usr/include/openssl/sha.h:142: error: syntax error before 'size_t' /usr/include/openssl/sha.h:144: error: syntax error before 'size_t' /usr/include/openssl/sha.h:185: error: syntax error before 'size_t' /usr/include/openssl/sha.h:187: error: syntax error before 'size_t' /usr/include/openssl/sha.h:189: error: syntax error before 'size_t' /usr/include/openssl/sha.h:191: error: syntax error before 'size_t' This did not appear to happen in 0.9.7. Probably this is due to changing the API to use size_t; in sha.h I think that happened in 1.13: revision 1.13 date: 2004-05-15 11:29:55 +; author: appro; state: Exp; lines: +4 -4 size_t-fication of message digest APIs. We should size_t-fy more APIs... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Problem using Broadcom uBSec engine in 0.9.8
I'm still looking for help with this problem. The uBSec support works in 0.9.7g with static linking. The uBSec support works in 0.9.7g with shared libraries. The uBSec support works in 0.9.8 with static linking. The uBSec support fails in 0.9.8 with shared libraries. Here's a matrix: Version | ./config (static) | ./config shared | 0.9.7.g | Works | Works | 0.9.8| Works | Fails! | Here is the command line I use to build the test program: gcc -o test test.c -I include ./libssl.a ./libcrypto.a -ldl It feels like this is such a major bug that it can't possibly be real, and I must be doing something wrong. Can somebody help me? Thanks. -Original Message- From: Martin Del Vecchio Sent: Thursday, October 20, 2005 10:42 AM To: 'openssl-dev@openssl.org' Subject: Problem using Broadcom uBSec engine in 0.9.8 I am using OpenSSL on Linux in a shared library environment (./config shared). I am trying to load support for the Broadcom uBSec engine. Here is a test program: int main (int argc, char *argv[]) { ENGINE *Engine; SSL_library_init(); SSL_load_error_strings(); OpenSSL_add_all_algorithms(); ENGINE_load_ubsec(); // See if we can find the ubsec engine Engine = ENGINE_by_id ("ubsec"); if (Engine) printf ("ENGINE_by_id() found uBSec at %p.\n", Engine); else printf ("ENGINE_by_id() did not find UBSec.\n"); return (0); } I compile and link this file (test.c) with OpenSSL 0.9.7g: gcc -o test test.c -I include ./libssl.so ./libcrypto.so I run it, and it reports that it finds the uBSec engine. I try this with OpenSSL 0.9.8 and I get a link error: /tmp/ccuqAevP.o(.text+0x12c): In function `main': : undefined reference to `ENGINE_load_ubsec' collect2: ld returned 1 exit status This symbol is in e_ubsec.c, but when I include the corresponding .o file, I get the same error. That's because the symbol is not defined in e_ubsec.o, because it is inside a conditional: #ifdef OPENSSL_NO_DYNAMIC_ENGINE This symbol is not defined, because I chose the shared-library configuration. How can I use the built-in uBSec engine in a shared-library environment? Thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]