Dynamically loading openSSL dlls
Hi there, I am using axis2/c to build a web service client, and axis2/c depends on openSSL to support SSL. The way that axis2/c is currently built requires resolving all the symbols at load time, which means that the openSSL dlls have to present in the class path even if my web services does not need SSL. My goal is to modify axis2/c so that I can load the openSSL dlls at runtime, this means that I will need the dlls to exist in the class path only if my web service calls require SSL communication. The AXIS2/c mainly calls the openSSL apis starting with SSL_, like SSL_read(...). Has anyone done this? If yes, can you share the experience? I noticed that the functions starting with SSL_ are not exported, is this a problem? Thanks much! Frank
Re: Dynamically loading openSSL dlls
On Wed, Sep 10, 2008 at 7:48 AM, Raymond Zhou [EMAIL PROTECTED] wrote: Hi there, I Eloquent in it's brevity ;-) (I'm green with envy.) Anyhow, google for 'delay load DLL' and the first three links that show up might be the thing you want. There's different ways, depend on what your specific need is. Mostly much harder == more code / more work. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Hashing/MessageDigest in Engine
I was just thinking what you suggested as it would be costly affair to kick accelerator for single block. Well, single *or* small amount of blocks, with how small amount depending on hardware overhead costs and software/hardware sustained performance ratio. For example as per http://marc.info/?l=openssl-devm=115989512430107w=2 on VIA Esther CPU it doesn't pay off to engage SHA1 hardware for inputs shorter than 512 bytes or 8 blocks. While in SHA256 case software is so slow, that passing already 128 bytes or 2 blocks is advantageous. Once again, this is just an example, the numbers are specific for VIA *and* that particular technique (involving _crashing_ a machine instruction into non-accessible page). I see that in an engine there has to be a sequence init - (one moremore) update - final - cleanup, at least once even if the block size is just right, correct? How do I make sure that for single block it doesn't go thru engine? I don't understand what is the problem. You just do it. If input for update is too short, you call software to do the job. And as final is single block operation you call software too. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] openssl-0.9.8h in AIX 5.3 do not build shared libraries
Hi, (response to Andy) 1) How does mod_ssl.so fail to load exactly? I got error message (below) after tried to start httpd (some blanks added): httpd: Syntax error on line 92 of /temp/packages/AIX/apache22/conf/httpd.conf: Cannot load /temp/packages/AIX/apache22/modules/mod_ssl.so into server: rtld: 0712-001 Symbol main was referenced from module /temp/packages/AIX/openssl/lib/libssl.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol main was referenced from module /temp/packages/AIX/openssl/lib/libcrypto.so(), but a runtime definition of the symbol was not found. rtld: 0712-002 fatal error: exiting. 2) entry point Sure there could be callable shared objects (in linux for example run /lib64/libc.so.6). And you could use -binitfini to specify routines, as IBM satys: Optional shared object initialization and termination routines can be specified when creating the shared object. Here I just mean, that there were main() routine, because -bnoentry was not specified. 3) shared_ldflags The -bnoentry is needed when building shared objects in AIX. It would be sensible to separate these AIX gcc versus cc shared ldflags. Now the aix section in Makefile.shared is messy - there is also many AIX cc specific options (not valid for gcc). It seems good if these options would be in Configure: -G,-bexpall,-bnoentry,-bM:SRE,-bnolibpath for AIX cc and -shared for gcc. -Tippa --- --- --- From: Andy Polyakov appro () fy ! chalmers ! se Date: 2008-09-09 21:23:56 Message-ID: 48C6E96C.5060901 () fy ! chalmers ! se When just building Apache 2.2.9 with openssl support, I found that mod_ssl.so could not be loaded. How does mod_ssl.so fail to load exactly? When I investigated the problem I found that the reason was broken openssl shared libraries. These libraries (libcrypto.so and libssl.so) were build using ./Configure aix64-cc shared. Both shared libraries have entry points!!! I don't quite understand why is entry point considered wrong? It's not inappropriate for shared library to have an initialization code and how would it be handled without entry point? Or does AIX run-time linker handle it in some magical way? If so, how? So I checked the build process and found that in Makefile.shared the -G option is used incorrectly. When using -G option with cc it should not be used with/inside -Wl option. The real reason for passing -G through -Wl is that rule in question is expected to work even with gcc, not only cc. So if -bnoentry is actually required, then it's more appropriate to complement -Wl with -bnoentry, not take -G out. Or it might be more appropriate to move -G to ./Configure, to $shared_ldflags [and -shared to corresponding gcc target]... aix53 aix53 uname -srvp AIX 3 5 powerpc aix53 cc -qversion IBM XL C/C++ Enterprise Edition V8.0 for AIX Version: 08.00.. aix53 aix53 # 1) We have -G inside -Wl (incorrect result: we have entry point) aix53 cc -v -DOPENSSL_THREADS -qthreaded -DDSO_DLFCN -DHAVE_DLFCN_H -q64 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -q64 -Wl,-G,-bexpall,-bnolibpath,-bM:SRE -o libssl.so.0.9.8 libssl.o -L. -lcrypto exec: export(export,XL_CONFIG=/etc/vac.cfg:cc,NULL) exec: /bin/ld(/bin/ld,-b64,/lib/crt0_64.o,-bpT:0x1,-bpD:0x11000,-G,-bexpall,-bnolibpath,-bM:SRE,-o,libssl.so.0.9.8,libssl.o,-L.,-lcrypto,-L/usr/vac/lib,-lxlopt,-lc,NULL) ld: 0711-224 WARNING: Duplicate symbol: p_xargc ld: 0711-224 WARNING: Duplicate symbol: p_xargv ld: 0711-224 WARNING: Duplicate symbol: p_xrcfg ld: 0711-224 WARNING: Duplicate symbol: p_xrc ld: 0711-224 WARNING: Duplicate symbol: end ld: 0711-224 WARNING: Duplicate symbol: .bcopy ld: 0711-224 WARNING: Duplicate symbol: .memcpy ld: 0711-224 WARNING: Duplicate symbol: .memmove ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. AIX doesn't stop to amaze/puzzple... I don't have regular access to AIX, but I can't recall such messages... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl 0.9.8h on Solaris 10.3 amd64 blues
Dear Doug,
Thanks a lot for the fast reply. The no-asm did it. I imagine this may
have some performance penalties since it seems to use it for shared
memory.
On the side, os/compiler option debug-solaris-x86-gcc doesn't seem to be
supported in 0.9.8h.
Unfortunately the whole stack trace is within libc, before it reaches the
entry point main(). I did compiled with -g when I run it through gdb, but
still nothing to look at.
Again it worked like a charm and many thanks for the fast reply. You
really saved the day.
Thanks,
Nikos
Let me correct the previous note. I had added no-asm when building the
debug version. With a non-debug version and no-asm the tests work. So
the problem apears to be with the asm modules.
Douglas E. Engert wrote:
[EMAIL PROTECTED] wrote:
Hi,
I've waisted most of my day today with openssl deployment on the
aforementioned server. Any help would be greatly appreciated.
I compile using gcc32 with the following options:
Configure solaris-x86-gcc threads no-krb5
I definitely need threads. Compilation goes through without problems
but
when I do a make test I get:
Doing certs
touch rehash.time
testing...
make[1]: Entering directory `/opt/kannel/openssl-0.9.8h/test'
make[2]: Entering directory `/opt/kannel/openssl-0.9.8h'
making all in apps...
make[3]: Entering directory `/opt/kannel/openssl-0.9.8h/apps'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/opt/kannel/openssl-0.9.8h/apps'
make[2]: Leaving directory `/opt/kannel/openssl-0.9.8h'
../util/shlib_wrap.sh ./destest
make[1]: *** [test_des] Segmentation Fault (core dumped)
make[1]: Leaving directory `/opt/kannel/openssl-0.9.8h/test'
make: *** [tests] Error 2
I was getting the same error. gdb showed it was failing in _init()
Configuring with debug-solaris-x86-gcc got around the problem.
Solaris 5.10 on x86
gcc is from Sun in /usr/sfw/bin:
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
I am getting the same results when I try to use it with external
applications (runtime core).
The Solaris kernel is 64 bit, but I am compiling the code in 32 bits.
This
is not a problem with other applications.
Something funny happens with libc at the beginning before I get the
chance
to put a breakpoint on main in destest.
I had built the debug version to try with gdb, but the debug version
works! I have not gotten back to why the non-debug version fails.
I speculate it is a gcc bug, or something to do with _init with
asm code in the lib.
I had built the debug version with no-asm also. Building without
the debug version, but with no-asm works.
I added the line (wrapped for the e-mail):
debug-solaris-x86-gcc,gcc:-O -g -fomit-frame-pointer -march=pentium
-Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM::-D_REENTRANT::-lsocket -lnsl
-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:
solaris-shared:-fPIC:-shared:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
I also tried changing from -O3 to -O:
solaris-x86-gcc,gcc:-O -fomit-frame-pointer -march=pentium
-Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM::-D_REENTRANT::-lsocket -lnsl
-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:
solaris-shared:-fPIC:-shared:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
but this also failed, the only difference is -g.
Sorry, I had also added no-asm. So it has something to do with asm.
Any ideas?
Thanks,
Nikos
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
Douglas E. Engert [EMAIL PROTECTED]
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: openssl 0.9.8h on Solaris 10.3 amd64 blues
[EMAIL PROTECTED] wrote:
Dear Doug,
Thanks a lot for the fast reply. The no-asm did it. I imagine this may
have some performance penalties since it seems to use it for shared
memory.
I also tried the fix Andy pointed out in the PROBLEMS file.
http://www.openssl.org/~appro/values.c
It creates the value-X*.o files that gcc 3.4.3 on Solaris appears to not
have created, but refers to in the specs file. This also works,
and you get the improved performance.
On the side, os/compiler option debug-solaris-x86-gcc doesn't seem to be
supported in 0.9.8h.
No, I added the line to try and get a trace.
Unfortunately the whole stack trace is within libc, before it reaches the
entry point main(). I did compiled with -g when I run it through gdb, but
still nothing to look at.
Yes, I saw that too even with -g.
Again it worked like a charm and many thanks for the fast reply. You
really saved the day.
Try Andy's solution too.
Thanks,
Nikos
Let me correct the previous note. I had added no-asm when building the
debug version. With a non-debug version and no-asm the tests work. So
the problem apears to be with the asm modules.
Douglas E. Engert wrote:
[EMAIL PROTECTED] wrote:
Hi,
I've waisted most of my day today with openssl deployment on the
aforementioned server. Any help would be greatly appreciated.
I compile using gcc32 with the following options:
Configure solaris-x86-gcc threads no-krb5
I definitely need threads. Compilation goes through without problems
but
when I do a make test I get:
Doing certs
touch rehash.time
testing...
make[1]: Entering directory `/opt/kannel/openssl-0.9.8h/test'
make[2]: Entering directory `/opt/kannel/openssl-0.9.8h'
making all in apps...
make[3]: Entering directory `/opt/kannel/openssl-0.9.8h/apps'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/opt/kannel/openssl-0.9.8h/apps'
make[2]: Leaving directory `/opt/kannel/openssl-0.9.8h'
../util/shlib_wrap.sh ./destest
make[1]: *** [test_des] Segmentation Fault (core dumped)
make[1]: Leaving directory `/opt/kannel/openssl-0.9.8h/test'
make: *** [tests] Error 2
I was getting the same error. gdb showed it was failing in _init()
Configuring with debug-solaris-x86-gcc got around the problem.
Solaris 5.10 on x86
gcc is from Sun in /usr/sfw/bin:
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
I am getting the same results when I try to use it with external
applications (runtime core).
The Solaris kernel is 64 bit, but I am compiling the code in 32 bits.
This
is not a problem with other applications.
Something funny happens with libc at the beginning before I get the
chance
to put a breakpoint on main in destest.
I had built the debug version to try with gdb, but the debug version
works! I have not gotten back to why the non-debug version fails.
I speculate it is a gcc bug, or something to do with _init with
asm code in the lib.
I had built the debug version with no-asm also. Building without
the debug version, but with no-asm works.
I added the line (wrapped for the e-mail):
debug-solaris-x86-gcc,gcc:-O -g -fomit-frame-pointer -march=pentium
-Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM::-D_REENTRANT::-lsocket -lnsl
-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:
solaris-shared:-fPIC:-shared:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
I also tried changing from -O3 to -O:
solaris-x86-gcc,gcc:-O -fomit-frame-pointer -march=pentium
-Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM::-D_REENTRANT::-lsocket -lnsl
-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:
solaris-shared:-fPIC:-shared:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
but this also failed, the only difference is -g.
Sorry, I had also added no-asm. So it has something to do with asm.
Any ideas?
Thanks,
Nikos
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
Douglas E. Engert [EMAIL PROTECTED]
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
Douglas E. Engert [EMAIL PROTECTED]
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
__
OpenSSL Project
Re: openssl 0.9.8h on Solaris 10.3 amd64 blues
Yes. I tried it myself and works. Indeed it is an incompatibility between
solaris linker and solaris gcc. It is recommended not only because of
performance, but because a broken gcc might affect all future
compilations.
I hope the guys in gcc get wind of this.
Many thanks to Andy, as well.
[EMAIL PROTECTED] wrote:
Dear Doug,
Thanks a lot for the fast reply. The no-asm did it. I imagine this may
have some performance penalties since it seems to use it for shared
memory.
I also tried the fix Andy pointed out in the PROBLEMS file.
http://www.openssl.org/~appro/values.c
It creates the value-X*.o files that gcc 3.4.3 on Solaris appears to not
have created, but refers to in the specs file. This also works,
and you get the improved performance.
On the side, os/compiler option debug-solaris-x86-gcc doesn't seem to
be
supported in 0.9.8h.
No, I added the line to try and get a trace.
Unfortunately the whole stack trace is within libc, before it reaches
the
entry point main(). I did compiled with -g when I run it through gdb,
but
still nothing to look at.
Yes, I saw that too even with -g.
Again it worked like a charm and many thanks for the fast reply. You
really saved the day.
Try Andy's solution too.
Thanks,
Nikos
Let me correct the previous note. I had added no-asm when building the
debug version. With a non-debug version and no-asm the tests work. So
the problem apears to be with the asm modules.
Douglas E. Engert wrote:
[EMAIL PROTECTED] wrote:
Hi,
I've waisted most of my day today with openssl deployment on the
aforementioned server. Any help would be greatly appreciated.
I compile using gcc32 with the following options:
Configure solaris-x86-gcc threads no-krb5
I definitely need threads. Compilation goes through without problems
but
when I do a make test I get:
Doing certs
touch rehash.time
testing...
make[1]: Entering directory `/opt/kannel/openssl-0.9.8h/test'
make[2]: Entering directory `/opt/kannel/openssl-0.9.8h'
making all in apps...
make[3]: Entering directory `/opt/kannel/openssl-0.9.8h/apps'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/opt/kannel/openssl-0.9.8h/apps'
make[2]: Leaving directory `/opt/kannel/openssl-0.9.8h'
../util/shlib_wrap.sh ./destest
make[1]: *** [test_des] Segmentation Fault (core dumped)
make[1]: Leaving directory `/opt/kannel/openssl-0.9.8h/test'
make: *** [tests] Error 2
I was getting the same error. gdb showed it was failing in _init()
Configuring with debug-solaris-x86-gcc got around the problem.
Solaris 5.10 on x86
gcc is from Sun in /usr/sfw/bin:
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
I am getting the same results when I try to use it with external
applications (runtime core).
The Solaris kernel is 64 bit, but I am compiling the code in 32 bits.
This
is not a problem with other applications.
Something funny happens with libc at the beginning before I get the
chance
to put a breakpoint on main in destest.
I had built the debug version to try with gdb, but the debug version
works! I have not gotten back to why the non-debug version fails.
I speculate it is a gcc bug, or something to do with _init with
asm code in the lib.
I had built the debug version with no-asm also. Building without
the debug version, but with no-asm works.
I added the line (wrapped for the e-mail):
debug-solaris-x86-gcc,gcc:-O -g -fomit-frame-pointer -march=pentium
-Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM::-D_REENTRANT::-lsocket
-lnsl
-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:
solaris-shared:-fPIC:-shared:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
I also tried changing from -O3 to -O:
solaris-x86-gcc,gcc:-O -fomit-frame-pointer -march=pentium
-Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM::-D_REENTRANT::-lsocket
-lnsl
-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:
solaris-shared:-fPIC:-shared:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
but this also failed, the only difference is -g.
Sorry, I had also added no-asm. So it has something to do with asm.
Any ideas?
Thanks,
Nikos
__
OpenSSL Project
http://www.openssl.org
Development Mailing List
openssl-dev@openssl.org
Automated List Manager
[EMAIL PROTECTED]
--
Douglas E. Engert [EMAIL PROTECTED]
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Memory leak : again and always
Hi, I'm currently developping an application using libcrypto, I find some memory leak with valgrind (please don't say me to compile with -DPURIFY, I know that and in fact, my problem is not uninitialized data, but rather memory leak) : ==26823== 1,552 (168 direct, 1,384 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 2 ==26823==at 0x4C22FAB: malloc (vg_replace_malloc.c:207) ==26823==by 0x40ACB2: CRYPTO_malloc (in /home/nicolas/admkey) ==26823==by 0x41CBBA: RSA_new_method (in /home/nicolas/admkey) ==26823==by 0x41CECC: rsa_cb (in /home/nicolas/admkey) ==26823==by 0x428C02: asn1_item_ex_combine_new (in /home/nicolas/admkey) ==26823==by 0x42BC17: ASN1_item_ex_d2i (in /home/nicolas/admkey) ==26823==by 0x42BD13: ASN1_item_d2i (in /home/nicolas/admkey) ==26823==by 0x4284E3: d2i_PrivateKey (in /home/nicolas/admkey) ==26823==by 0x4097F7: PEM_read_bio_PrivateKey (in /home/nicolas/admkey) ==26823==by 0x409A30: PEM_read_PrivateKey (in /home/nicolas/admkey) ==26823==by 0x40953E: PEM_read_RSAPrivateKey (in /home/nicolas/admkey) ==26823==by 0x401CE5: change_passphrase (admkey.c:133) ==26823== ==26823== ==26823== 1,384 bytes in 16 blocks are indirectly lost in loss record 2 of 2 ==26823==at 0x4C22FAB: malloc (vg_replace_malloc.c:207) ==26823==by 0x40ACB2: CRYPTO_malloc (in /home/nicolas/admkey) ==26823==by 0x413F37: BN_new (in /home/nicolas/admkey) ==26823==by 0x4271A4: bn_c2i (in /home/nicolas/admkey) ==26823==by 0x42A069: asn1_ex_c2i (in /home/nicolas/admkey) ==26823==by 0x42AB56: asn1_d2i_ex_primitive (in /home/nicolas/admkey) ==26823==by 0x42B875: ASN1_item_ex_d2i (in /home/nicolas/admkey) ==26823==by 0x42AF37: asn1_template_noexp_d2i (in /home/nicolas/admkey) ==26823==by 0x42B1FE: asn1_template_ex_d2i (in /home/nicolas/admkey) ==26823==by 0x42B9CC: ASN1_item_ex_d2i (in /home/nicolas/admkey) ==26823==by 0x42BD13: ASN1_item_d2i (in /home/nicolas/admkey) ==26823==by 0x4284E3: d2i_PrivateKey (in /home/nicolas/admkey) I call PEM_read_RSAPrivateKey() as you can see, I've tried lots of solution including call to these function : EVP_cleanup (); ERR_free_strings (); CRYPTO_cleanup_all_ex_data (); but valgrind still complains. I've also downloaded the latest snapshot, but it seems that this problem is not currently fix. I have also check in the documentation of PEM_read_RSAPrivateKey(), but nothing says how to free this memory. Please can someone help me, cause it's not acceptable for me. Thanks!!!
Re: Fix VIA Padlock RNG support ?
Hi guys, ist has been 10 days since I posted this mail about certain questions with regard to the suboptimal integration of VIA padlock support in OpenSSL. Is there some kind of taboo against this topic or some bad history that I'm missing? If yes, I'm sorry to hear that. In any case, I am here, I have time, and I will do whatever it takes to the code to make you guys happy with it for integration. So please talk to me ;) Thanks again. On Mon, Sep 01, 2008 at 09:51:30PM +0800, Harald Welte wrote: Hi Michal, Hi OpenSSL developers, as part of my work for VIA, I am trying to find out what we can do to make sure the VIA Padlock RNG is activated by default. I have read the comments in the source code, referring that the RNG is not used the way that VIA recommends for secure applications. I have also read the padlock programming guides from http://linux.via.com.tw/support/beginDownload.action?eleid=181fid=261 and http://linux.via.com.tw/support/beginDownload.action?eleid=181fid=281 So from what I can tell, Michal Ludvig originally included RNG support in his patch, but it was deactivated by the OpenSSL maintainers due to security concerns. Can somebody please indicate what exactly those concerns were? I would be willing to put in some of my own time to come up with a patch to address the concerns, and then have that patch reviewed by OpenSSL guys, Michal as well as the respective Padlock security expert inside VIA. I also have a question about Michal's SHA1/224/256 patch at http://marc.info/?l=openssl-devm=115243758508970w=2 It never received any feedback on the list, and it wasn't merged into mainline OpenSSL. Was this simply lost? Can I (or VIA) do anything to help this along? Thanks in advance, -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Fix VIA Padlock RNG support ?
* Harald Welte ([EMAIL PROTECTED]) wrote: Hi guys, ist has been 10 days since I posted this mail about certain questions with regard to the suboptimal integration of VIA padlock support in OpenSSL. Is there some kind of taboo against this topic or some bad history that I'm missing? If yes, I'm sorry to hear that. In any case, I am here, I have time, and I will do whatever it takes to the code to make you guys happy with it for integration. So please talk to me ;) Hi Harald, No taboo, no bad history that I'm aware of, just plain old open-source, everyone's-always-got-something-else-less-free-to-do indifference. Don't take it personally :-) I just took a look at Michal's SHA patch and nothing lept out as overly terrifying. Perhaps Michal will comment if he's aware of any discussion about it? (I don't recall.) Otherwise did you happen to search the request tracker or mail archives about this? (Ie. beyond the fact that Michal's post didn't have a threaded response.) As for the RNG stuff, if you are able to find any references to discussion and/or cvs commits regarding the deactivation by OpenSSL maintainers then that would make it easier for me to follow up too. TIA. Cheers, Geoff Thanks again. On Mon, Sep 01, 2008 at 09:51:30PM +0800, Harald Welte wrote: Hi Michal, Hi OpenSSL developers, as part of my work for VIA, I am trying to find out what we can do to make sure the VIA Padlock RNG is activated by default. I have read the comments in the source code, referring that the RNG is not used the way that VIA recommends for secure applications. I have also read the padlock programming guides from http://linux.via.com.tw/support/beginDownload.action?eleid=181fid=261 and http://linux.via.com.tw/support/beginDownload.action?eleid=181fid=281 So from what I can tell, Michal Ludvig originally included RNG support in his patch, but it was deactivated by the OpenSSL maintainers due to security concerns. Can somebody please indicate what exactly those concerns were? I would be willing to put in some of my own time to come up with a patch to address the concerns, and then have that patch reviewed by OpenSSL guys, Michal as well as the respective Padlock security expert inside VIA. I also have a question about Michal's SHA1/224/256 patch at http://marc.info/?l=openssl-devm=115243758508970w=2 It never received any feedback on the list, and it wasn't merged into mainline OpenSSL. Was this simply lost? Can I (or VIA) do anything to help this along? Thanks in advance, -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fix VIA Padlock RNG support ?
Hi Geoff, thanks for your quick response. On Wed, Sep 10, 2008 at 09:56:36PM -0400, Geoff Thorpe wrote: No taboo, no bad history that I'm aware of, just plain old open-source, everyone's-always-got-something-else-less-free-to-do indifference. Don't take it personally :-) ok, thanks. that's good to hear. I just took a look at Michal's SHA patch and nothing lept out as overly terrifying. Perhaps Michal will comment if he's aware of any discussion about it? (I don't recall.) Otherwise did you happen to search the request tracker or mail archives about this? (Ie. beyond the fact that Michal's post didn't have a threaded response.) I searched the list archives but couldn't find anything apart from that single message by Michal to the list. He is talking about someobody having asked him to add testsuite support, but he didn't exactly know what he needs to add. I could not find any evidence of any prior or later discussion on that subject. Maybe Michal could enlighten us :) As for the RNG stuff, if you are able to find any references to discussion and/or cvs commits regarding the deactivation by OpenSSL maintainers then that would make it easier for me to follow up too. TIA. At http://www.logix.cz/michal/devel/padlock/index.xp?show_selected=1msgid=1050 I found the quote Stock OpenSSL as packaged in linux distros or as available from openssl.org has the RNG engine intentionally disabled. Thus no-RNG. My patches have it enables, so you see RNG. See the source for the reasons to enable/disable RNG. which seems to indicate that Michal Ludvig's original code has it enabled, but OpenSSL mainline disabled it. I searched the list archives and RT before, but didn't find anything on either the RNG or the SHA issue. Cheers, -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
