Re: [openssl.org #124] [PATCH] OS/2 shared build support
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 12:49:18 +1000 (EST), Brian Havard [EMAIL PROTECTED] said: brianh Applied to the 0.9.7 branch as well as HEAD. Thanks. brianh brianh Cool, though a new problem has been introduced (not directly related to the brianh ticket). In crypto/rand/rand.h rev 1.27, this was done: I applied your change. Thanks. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #148] Re: 0.9.7 PATCH (strcasecmp)
Actually, I found that strcasecmp() is often declared in strings.h, so it still needs to be included in most places. Therefore, I applied your original patch. This ticket is now resolved. [levitte - Tue Jul 16 09:03:42 2002]: Quick question: does string.h in Unixware define strcasecmp()? strings.h is non-standard while string.h is standard, as far as I know. We should change that in any case, unless someone has a different opinion. [[EMAIL PROTECTED] - Mon Jul 15 09:33:16 2002]: This patch seems to have been lost. I'm resending the patch against the OpenSSL_0_9_7-stable branch (Jul 13) I'd like to have my UnixWare platforms working before I look at my SCO platforms. On Sun, 17 Feb 2002, Tim Rice wrote: Attached is a patch against the OpenSSL_0_9_7-stable branch (Feb 17) that fixes the build on UnixWare 2.x Files changed: Configure, apps/apps.c, and apps/ca.c I've added -lresolv so it can find strcasecmp(). UnixWare 2.0x does not have strings.h so I changed apps.c and ca.c It has string.h ... # ifdef NO_STRINGS_H int strcasecmp(); # else #include strings.h # endif /* NO_STRINGS_H */ ... -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: zencod engine for openssl 0.9.6x 0.9.7
In message [EMAIL PROTECTED] on Wed, 17 Jul 2002 14:10:58 -0400 (EDT), Geoff Thorpe [EMAIL PROTECTED] said: geoff 0.9.6* releases are strictly for bug-fixes, so that is out of geoff the question. 0.9.7 is already in beta-testing so I'd similarly geoff doubt inclusion of anything new in there - especially as it geoff only has to trip up compilation on one platform for it to break geoff the release at this late stage. Given the size of the geoff attachments you sent, I expect that this risk would be geoff considered unacceptable, though other team members may have geoff differing views on that ...? I'd like to add that for 0.9.7+ engines, we usually recommend building the engine as a separate dynamically loadable library. We know it works, and there's a demo that one can look at, that implements some crypto algorithms using the RSAref library (I've tested it on Solaris, Linux and VMS). -- Richard Levitte [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~levitte/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #73] make failing under MAC OS X (darwin)
This most likely yet again the problem with the way ld works on MacOS X. I'll attach the PROBLEMS file that has a section about this particular problem and possible solutions. I hereby consider this ticket resolved. [jaenicke - Tue Jun 11 13:55:44 2002]: [[EMAIL PROTECTED] - Tue Jun 4 19:09:40 2002]: cc -o openssl -DMONOLITH -I../include -fPIC -DTHREADS -D_REENTRANT -O3 -D_DARWIN -DB_ENDIAN openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o -L.. -lssl -L.. -lcrypto /usr/bin/ld: Undefined symbols: _ENGINE_by_id _ENGINE_free _ENGINE_set_default _ENGINE_load_private_key _ENGINE_ctrl _RSA_set_default_openssl_method /usr/bin/ld: warning unused multiple definitions of symbol _crypt /usr/lib/libcrypto.dylib(fcrypt.o) definition of _crypt /usr/lib/libSystem.dylib(crypt.o) unused definition of _crypt make[1]: *** [openssl] Erreur 1 make: *** [sub_all] Erreur 1 To which version of OpenSSL do you refer? Did you see any error message while building in the crypto/engine/ subdirectory? Best regards, Lutz -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #104] Make fails with undefined reference
Has this problem been dealt with yet? [jaenicke - Tue Jun 18 12:30:24 2002]: On Mon, Jun 17, 2002 at 07:43:18PM +0200, [EMAIL PROTECTED] via RT wrote: redhat linux never upgraded libraries are rpm's glibc-2.1.92-14 and glibc-devel-2.1.92-14. it's redhat 7.0. I think sysconf is unistd.h. Some other headers are in /usr/i386-glibc21- linux/include, and since I'm not much of a programmer I don't know if they're important or not I dc. i don't even know if that's really old enough to upgrade. anyhow, i don't think it was in an archive of the mailing list, so that's why I posted it. I added it to the Request Tracker, as on standard platforms ./config should detect enough of the settings that compilation should succeed. I consider Redhat Linux to be kind of standard enough. Does anybody know the resolution of this problem? Lutz -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #118] How to implement OPENssl on AS 400
I've seen no further communications on this subject. Has this issue been dealt with? Is there a change that we should apply, or shall we just kill this ticket? [jaenicke - Tue Jun 25 22:25:56 2002]: [[EMAIL PROTECTED] - Tue Jun 25 20:51:20 2002]: Hello friend, I am working for IBM server technology group(U.S.) I am trying to implement open ssl on AS400. I know it works on unix,windows,vms etc platforms but can anybody suggest me howe to implement it on AS 400 which is IBM iseries platform ? friends, I will really appreciate the help and pointers. Waiting, The keyword AS400 triggerd SuSE Linux in my head. They seem to work on Linux for the iseries platform. If this is what you are interested in, you should contact them (they are in a partnership with IBM anyway). If you are looking for something different: A research in the mailing list archive with the keyword AS400 revealed one short thread without any result. Please be more detailed with respect to your intentions. Best regards, Lutz -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #151] S/MIME implemementation doesn't follow MIMEspec. Patch included.
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 11:17:41 +0200, Bodo Moeller [EMAIL PROTECTED] said: moeller I think this is wrong. moeller moeller The output file is opened in text mode (not binary), so on systems moeller where line ends are usually CRLF, the \r\n will result in CR CR LF moeller sequences because \n is converted into CRLF by the system library. Good point. OK, I'll reverse that change and review the ticket... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #151] S/MIME implemementation doesn't follow MIME spec. Patch included.
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 11:17:41 +0200, Bodo Moeller [EMAIL PROTECTED] said: moeller I think this is wrong. moeller moeller The output file is opened in text mode (not binary), so on systems moeller where line ends are usually CRLF, the \r\n will result in CR CR LF moeller sequences because \n is converted into CRLF by the system library. Good point. OK, I'll reverse that change and review the ticket... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #125] [Enhancement] --certdir option for cert/key directory
Often, the cert/key directory is not used at all; otherwise it should be easy to use symbolic links to get the desired effect. Thus it should be possible to do without the '--certdir' patch. A reason for *not* introducing '--certdir' is that the '--prefix'/'--openssldir' situation is already a little bit complicated w.r.t. default values, and there have been proposals to simplify it. '--certdir' would further complicate the current situation. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #151] S/MIME implemementation doesn't follow MIME spec. Patch included.
I've reversed the patch. Bodo is correct, it's not OpenSSL's
responsability to do the various conversions that may be done by the
C run-time library anyway. If there are problems passing the
resulting file to some library that expects the formating to CRLF
line ends in a text file, the appropriate action is to filter the
file through something that adds the CR appropriately, for example:
# ^M is the actual control character
sed -e 's/\(^\|[^\^M]\)$/\1\^M/'
Can this be enough of a solution and good enough to resolve this
ticket?
[[EMAIL PROTECTED] - Tue Jul 16 09:04:08 2002]:
The OpenSSL S/MIME implementation doesn't follow the MIME
specification when writing out messages in that format. As a
result,
messages created with this library will choke when passed through
strictly compliant SMTP libraries.
A patch is below, against today's mid-afternoon CVS tree (EST).
The
problem was found and the patch created by Zachary Girouard
[EMAIL PROTECTED].
diff --exclude=*Makefile* -ur openssl/apps/smime.c openssl-
zakk/apps/smime.c
--- openssl/apps/smime.c Wed May 8 11:12:59 2002
+++ openssl-zakk/apps/smime.c Tue Jul 16 01:31:09 2002
@@ -530,9 +530,9 @@
} else if(operation == SMIME_PK7OUT) {
PEM_write_bio_PKCS7(out, p7);
} else {
- if(to) BIO_printf(out, To: %s\n, to);
- if(from) BIO_printf(out, From: %s\n, from);
- if(subject) BIO_printf(out, Subject: %s\n,
subject);
+ if(to) BIO_printf(out, To: %s\r\n, to);
+ if(from) BIO_printf(out, From: %s\r\n, from);
+ if(subject) BIO_printf(out, Subject: %s\r\n,
subject);
if(outformat == FORMAT_SMIME)
SMIME_write_PKCS7(out, p7, in, flags);
else if(outformat == FORMAT_PEM)
diff --exclude=*Makefile* -ur openssl/crypto/dso/dso_lib.c openssl-
zakk/crypto/dso/dso_lib.c
--- openssl/crypto/dso/dso_lib.c Mon Jul 15 11:35:39 2002
+++ openssl-zakk/crypto/dso/dso_lib.c Mon Jul 15 16:59:53 2002
@@ -394,7 +394,7 @@
{
char *result = NULL;
- if(dso == NULL || dir == NULL)
+ if(dso == NULL)
{
DSOerr(DSO_F_DSO_MERGE,ERR_R_PASSED_NULL_PARAMETER);
return(NULL);
diff --exclude=*Makefile* -ur openssl/crypto/pkcs7/pk7_mime.c
openssl-
zakk/crypto/pkcs7/pk7_mime.c
--- openssl/crypto/pkcs7/pk7_mime.c Tue Jan 30 08:38:59 2001
+++ openssl-zakk/crypto/pkcs7/pk7_mime.c Mon Jul 15 16:57:29
2002
@@ -164,34 +164,34 @@
bound[i] = c;
}
bound[32] = 0;
- BIO_printf(bio, MIME-Version: 1.0\n);
+ BIO_printf(bio, MIME-Version: 1.0\r\n);
BIO_printf(bio, Content-Type: multipart/signed;);
BIO_printf(bio,
protocol=\application/x-pkcs7-signature\;);
- BIO_printf(bio, micalg=sha1;
boundary=\%s\\n\n, bound);
+ BIO_printf(bio, micalg=sha1;
boundary=\%s\\r\n\r\n,
bound);
BIO_printf(bio, This is an S/MIME signed
message\n\n);
/* Now write out the first part */
BIO_printf(bio, --%s\n, bound);
- if(flags PKCS7_TEXT) BIO_printf(bio, Content-Type:
text/plain\n\n);
+ if(flags PKCS7_TEXT) BIO_printf(bio, Content-Type:
text/plain\r\n\r\n);
while((i = BIO_read(data, linebuf, MAX_SMLEN)) 0)
BIO_write(bio,
linebuf, i);
- BIO_printf(bio, \n--%s\n, bound);
+ BIO_printf(bio, \n--%s\r\n, bound);
/* Headers for signature */
- BIO_printf(bio, Content-Type:
application/x-pkcs7-signature;
name=\smime.p7s\\n);
- BIO_printf(bio, Content-Transfer-Encoding:
base64\n);
- BIO_printf(bio, Content-Disposition: attachment;
filename=\smime.p7s\\n\n);
+ BIO_printf(bio, Content-Type:
application/x-pkcs7-signature;
name=\smime.p7s\\r\n);
+ BIO_printf(bio, Content-Transfer-Encoding:
base64\r\n);
+ BIO_printf(bio, Content-Disposition: attachment;
filename=\smime.p7s\\r\n\r\n);
B64_write_PKCS7(bio, p7);
- BIO_printf(bio,\n--%s--\n\n, bound);
+ BIO_printf(bio,\r\n--%s--\r\n\r\n, bound);
return 1;
}
/* MIME headers */
- BIO_printf(bio, MIME-Version: 1.0\n);
- BIO_printf(bio, Content-Disposition: attachment;
filename=\smime.p7m\\n);
- BIO_printf(bio, Content-Type: application/x-pkcs7-mime;
name=\smime.p7m\\n);
- BIO_printf(bio, Content-Transfer-Encoding: base64\n\n);
+ BIO_printf(bio, MIME-Version: 1.0\r\n);
+ BIO_printf(bio, Content-Disposition: attachment;
filename=\smime.p7m\\r\n);
+ BIO_printf(bio, Content-Type: application/x-pkcs7-mime;
name=\smime.p7m\\r\n);
+ BIO_printf(bio, Content-Transfer-Encoding:
[openssl.org #50] openssl-0.9.6d 'make test' fails (gcc, Solaris)
In similar configurations with gcc version 2.95.2, I observe none of these problems. This suggests that the problems may be due to compiler bugs in your gcc version; please try gcc 2.95.2 or a different newer release and report if the problems persist. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #118] How to implement OPENssl on AS 400
This is not a report on an actual problem in OpenSSL, and there has been no updated to the original request since June 25th; so nothing to do for us about this at the moment. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #149] [PATCH] apps/ca.c crl issuer patch
apps/ca.c has now been changed as suggested; thanks for the patch. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
shatest.c - SHA_Update()
Hi all, I am looking into the shatest.c file since i want to make use of sha-1 message digest. In this file openssl-0.9.6d/crypto/sha/shatest.c, 141 for (i=0; i1000; i++) 142 SHA_Update(c,buf,1000); 143 SHA_Final(md,c); For chunks of data we can call the SHA_Update() with those of chunks of data separately. for eg: if there are two buffers buf1 and buf2, you should call the update function twice. But here the SHA_Update is called 1000 times with the same buffer. Is it right? I am newbie and please help me in this regard. Thanks in Advance, Srini * Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. * __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #47] RC4 test failure
It's in the middle of the afternoon, so I'm resolving this ticket. I've mailed [EMAIL PROTECTED] about the whole issue. Whenever I get a good answer, I'll make appropriate changes. Until then, MacOS X will simply need to be tweaked before one can compile OpenSSL on it. [levitte - Wed Jul 17 13:08:26 2002]: [levitte - Wed Jul 17 09:25:24 2002]: [...] As for 0.9.8-dev, forget it for the moment, there are too damn many symbols missing in /usr/lib/libcrypto.dylib. I just tried building with shared support, and it actually works with a little extra work in the makefiles (MacOS X uses DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH, it seems), which I will commit in a moment. I'd like to resolve this ticket with the comments now found in the PROBLEMS file (it's new, so it currently only exists in snapshots) unless someone comes up with something more on this subject. I'll wait for answer until tomorrow afternoon, swedish time. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: shatest.c - SHA_Update()
On Thu, Jul 18, 2002 at 05:06:20PM +0530, Srinivas Cheruku wrote: I am looking into the shatest.c file since i want to make use of sha-1 message digest. In this file openssl-0.9.6d/crypto/sha/shatest.c, 141 for (i=0; i1000; i++) 142 SHA_Update(c,buf,1000); 143 SHA_Final(md,c); For chunks of data we can call the SHA_Update() with those of chunks of data separately. for eg: if there are two buffers buf1 and buf2, you should call the update function twice. But here the SHA_Update is called 1000 times with the same buffer. Is it right? Yes. It is done to test the algorithm. Actually 100 bytes are processed by adding the same 1000 bytes (all being `a` anyway) 1000 times. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Moving towards autoconf
Thus spake Richard Levitte - VMS Whacker: In message [EMAIL PROTECTED] on Wed, 17 Jul 2002 13:33:09 -0500, Stephen Sprunk [EMAIL PROTECTED] said: stephen I'd like to take on moving OpenSSL towards an autoconf stephen system. First of all, if anyone else is working on this, stephen please let me know :) Others have done that, but it's so far not been a hot topic. The trouble with autoconf is that it's very sh-bound (or at least the end result is), which means is largely Unix-bound, and it generates a number of variables that are often difficult to keep up woth manually no the systems where autoconf and sh don't exist or work badly. Okay, I hadn't thought about VMS, Windows, etc. I'll come back when I have a better clue how to do it :) stephen Second, I'd like to move all OS-specific defines and includes to a stephen common place, such as openssl/common.h. This would hopefully stephen eliminate the need for openssl/e_os2.h entirely. Comments? So basically, you'd like e_os2.h to be renamed to common.h. Or did you want to throw in the stuff that you find in e_os.h as well? Not exactly. There's a lot of OS-specific pollution in the source tree proper. A first target would be elimination of the OPENSSL_SYS_system family and replacing it with HAVE_feature and HAVE_header_h. You need to understand that e_os.h is private to OpenSSL (it can mess things up if used outside of OpenSSL) while e_os2.h is the public part, so mixing them in the same file would be a bad idea. IMHO, stuff like this doesn't belong in the main sources: #ifdef OPENSSL_SYS_WINDOWS #define strcasecmp _stricmp #else #include strings.h #endif It's much easier for individual contributors to maintain this: #ifdef HAVE_STRINGS_H # include strings.h #endif And then the folks concerned with porting to a new OS would only have a single place to worry about: wherever the OS is translated into the HAVE_ macros. The reason to stay away from things likt uint8 is that it isn't standardised yet. On some compilers, __uint8 is available instead, on others it's u_int8 or u_int_8... Basically, we would have to define our own in terms of whatever we find out there... Here's something from the AES refence code; there are similar examples from most of the other crypto units: typedef unsigned long u32; typedef unsigned short u16; typedef unsigned char u8; On a variety of systems, you have no idea how long a long or an int is going to be, and that should be hidden in some generic header (like e_os[2].h) so that we can use uint32's in our code without worrying that we'll accidentally get a 16-bit or 64-bit int. ISO C95/99 define these pretty explicitly in stdint.h, and e_os[2].h should be able to hack around that on non-compliant systems. S -- Stephen Sprunk So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSSalways said exactly what pleased me. --Albert Einstein __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #124] [PATCH] OS/2 shared build support
On Thu, 18 Jul 2002 09:22:49 +0200 (CEST), Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 12:49:18 +1000 (EST), Brian Havard [EMAIL PROTECTED] said: brianh Applied to the 0.9.7 branch as well as HEAD. Thanks. brianh brianh Cool, though a new problem has been introduced (not directly related to the brianh ticket). In crypto/rand/rand.h rev 1.27, this was done: I applied your change. Thanks. Builds cleanly now, thanks. -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | -- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #125] [Enhancement] --certdir option for cert/key directory
On Thu, 18 Jul 2002, Bodo Moeller via RT wrote: Often, the cert/key directory is not used at all; otherwise it should be Well, at least pine and lynx do. And there will be others... easy to use symbolic links to get the desired effect. Thus it should be possible to do without the '--certdir' patch. It is certainly possible to do without the option. I can use a symbolic link or fiddle around with environment variables. The point is that I have to do it manually, after installation. And I thought that this is what the configure scripts etc. are for: to produce a completely configured and properly set up installation. Put all the knowledge into the configure parameters and that's it. A reason for *not* introducing '--certdir' is that the '--prefix'/'--openssldir' situation is already a little bit complicated w.r.t. default values, and there have been proposals to simplify it. '--certdir' would further complicate the current situation. It may be a little complicated the way the parameters are named now but I think that seperating architecture-dependent files from architecture-independent files and from version-independent files should be a minimal requirement. -Gerald __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: shatest.c - SHA_Update()
But here the SHA_Update is called 1000 times with the same buffer. Is it right? It's just a test, so it's like calling SHA_Upodate with a 1000 buffers that are all the same. It's just to ensure that the hash input is large. Normally, you'd call SHA_Update once on your data. /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RE : zencod engine for openssl 0.9.6x 0.9.7
Hi there, On Thu, 18 Jul 2002, Frederic DONNAT wrote: I've sent the first release of our engine for 0.9.6x more than 6 months ago. Later on, I've sent a release for the 0.9.7dev long before the 0.9.7beta versions. This has been an ongoing problem, for which we apologise. It's the main reason why RT exists - the submission of changes, new code, feature requests, bug reports, [ad infinitum] was outstripping our ability to keep track of things without most of it slipping through the cracks. W.r.t. ENGINE submissions - I have had innumerable mails from various hardware vendors who will, are, or have been developing implementations. For many of those, I have had multiple emails on various subjects from development problems, licensing/copyright issues, how to submit, openssl release timelines, blah blah blah. In the end, it's extremely difficult to know who has sent what, when, and how, and moreover what is currently waiting on action from me and what isn't. I know Richard has had his fair share of the same. So before dealing specifically with your mail, let me clarify something. Richard and I are currently working on an improved scheme for the ENGINE library code, with the hopes of having it ready in time for 0.9.8. In this scheme, all ENGINEs would be built as stand-alone shared-libraries - so whether the source is bundled with openssl or not has less bearing on a vendor's ability to support openssl on their clients' machines. The idea is that when an application (or admin/user/configuration) requests the use of engine foo, openssl will check its internal list (as is currently the case), but when it finds no such ENGINE will take the additional step of probing a compiled-in installation directory such as $OPENSSLDIR/engines/ (though overridable by an environment variable) for the presence of a shared-library implementing foo (ie. using some canonical conversions, eg. libengine_foo.so, eng_foo.dll, etc). Right now we have numerous ENGINE implementations compiling in every openssl version on every platform and imposing a significant footprint on *every* openssl image. All this despite the fact that 99% of openssl users don't have any of these devices, most of the remaining 1% have at most one of these devices, and most of the supported devices themselves will never operate on more than 1 or 2 of the support platforms - despite the ENGINE support being compiled for every platform. In short, it's bloating out. Moreover, the speed at which new ENGINEs are coming in is increasing, to the point that we will have no choice soon but to unbundle them in *some* way. back to your post ... We've tested in Linux (2.4.x), Windows (2k) and Solaris (8) platforms. If it is mandatory to test in several platforms, please send me a list. I'll be happy to do it :-) Until the late-binding support I mentioned is mature, your code would need to compile smoothly on every platform support by openssl for it to be included. Whilst that can be difficult to achieve in theory, getting compilation perfect (no warnings, and no ugly hacks to stop warnings) on a number of different platforms is a good start - anything else that remains will usually get noticed by someone else, particular during beta testing. You'd also need to give permission for the source to be covered by the openssl license. On the other hand, I've proposed a patch for mod_ssl concerning the random in crypto cards. Yes I saw that, and I believe Richard was looking at the equivalent points you mentioned in one or two openssl utilities (s_client and s_server IIRC)? Could you please open a ticket on the openssl request-tracker for this? http://www.openssl.org/support/rt2.html That's the appropriate place for this sort of change request. ok. I was not aware of the RT 'til now. That's why I sent the code in the mailing list. OK - once it's in RT it won't get lost in list traffic. The only way for it to get completely passed by is for one of us to maliciously delete it, in which case you'll know who to chase and abuse :-) Note also that once it's on RT, anyone can look at the code and provide some peer-review, regardless of whether they're on the development team. Sorry for any inconvinience but I think i'm not pushing too hard, am I? I don't think so, and again I apologise if you've found us a little unresponsive but I hope the above comments explain why, at least w.r.t. ENGINE implementations, things have been a little messy until RT came along. We have been steadily approaching a situation where we have to change the way these implementations are bundled, compiled, and loaded. That combined with the number of mails from various parties we get about ENGINE stuff makes it very difficult to keep track of everything and respond to all mail that deserves it. Cheers, Geoff PS: Now I'm going to have to bookmark this post when it hits the archives so I can use it as a canned response ... :-) -- Geoff Thorpe [EMAIL PROTECTED]
Re: [openssl.org #75] DJGPP (DOS) Patch for 0.9.7
On Thu, 18 Jul 2002, Richard Levitte via RT wrote:
I've been away from this ticket for a while, sorry about the delay.
Thanks for getting back to it.
I think I've solved the problem. Since the tests are the biggest
problem with my suggestion, I deviced a mechanism to generate dummy
test programs for the missing algorithms.
That is basically what I tried to do. Each of the {algorithm}test.c
files has a dummy section for cases where NO_{algorithm} is defined.
Note that I don't clear the symbolic links quite yet, but am
prepared to avoid building them in the distribution, just as you
suggest.
The attached patch contains my suggestion. Would you mind looking
it over and comment on it, perhaps even test it?
Sure, I'll test it. I am too busy at work to get to it for the next few
days, however.
Doug
__
Doug Kaufman
Internet: [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: HMAC_SHA1
Yes Please read the man page for HMAC(http://www.openssl.org/docs/crypto/hmac.html) and EVP_sha1 (http://www.openssl.org/docs/crypto/evp.html) HTH Edson E. W. --- Srinivas Cheruku [EMAIL PROTECTED] wrote: Hi, Is there an implementation for Keyed Hash functions like HMAC_SHA1, HMAC_MD5 in OpenSSL. If so, can you please direct me where the function is and how to use it. Many Thanks, Srini * Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. * __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ___ Yahoo! Encontros O lugar certo para encontrar a sua alma gêmea. http://br.encontros.yahoo.com/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #139] [Fwd: Bug#150260: openssl: unnecessarily chatty on stderr]
As far as I know, most programs deliver verbosity to stderr rather than stdout. One could argue that OpenSSL should have optional verbosity, and I would agree. I'm not sure if this belongs in the important range of fixes, however. If a -verbose flag is to be added, I don't know if I want to do that for 0.9.7 or earlier. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #144] declaration bug between openssl.c / apps.c
Hey Andrew,
Actually, OpenSSL hasn't really been possible to build in
non-monolith mode, as far as I know. Honestly, I don't think
we should go the non-monolith path eaither, if you consider commands
like passwd...
If you tell me why you want to go non-monolith, I might change my
mind. No promises, though...
[[EMAIL PROTECTED] - Fri Jul 12 09:07:56 2002]:
line 142 openssl.c:
CONF *config=NULL;
needed by apps.c line 1325:
int load_config(BIO *err, CONF *cnf)
{
if (!cnf)
cnf = config; -
is not resolved in the case of NON - MONOLITH builds, as in
building a
standalone s_client executable by linking app_rand.o, apps.o,
s_cb.o,
s_client.o, s_socket.o against libeay and libcrypto . (amongst
numerous
others as well)
fix:
move or ifndef MONOLITH CONF *config=NULL; to apps.c
(all tests pass freebsd4.5-stable)
Thats the small one, make_serial_index(...)/unpack_revinfo(...) and
do_subject(...) implemented within ca.c and then called from ocsp.c
and
req.c - also break non MONOLITH builds in much the same way.
i'll send along in a bit as a patch as soon as i figure out all the
inner dependencies
Andrew
--
Richard Levitte
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #144] declaration bug between openssl.c / apps.c
[levitte - Thu Jul 18 19:41:51 2002]: Hey Andrew, Actually, OpenSSL hasn't really been possible to build in non-monolith mode, as far as I know. I meant to write hasn't really been possible to build in non-monolith mode *in a long time*... -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #147] [PATCH] The function print_name in apps/apps.c truncates X509_NAM Es that are longer than 255 characters
Fixed by letting X509_NAME_oneline() allocate the string. This ticket is now resolved. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #156] Bugs in doc/crypto/{DH,DSA}_set_method.pod
Those two files are copies of the 0.9.6d [engine] variants. However, most functionality has been restored back to the pre-engine days (or rather, the ENGINE framework has become much more transparent). I'm tempted to just revert those two files back to what they are in 0.9.6d, but I'd like someone to doublecheck for me that it's the right thing to do. Geoff? -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #59] 0.9.7 EVP manual pages incomplete
I just did a tentative addition of history. Please check it and complete it if needed. [levitte - Thu Jul 18 11:19:52 2002]: Has this been dealt with? [jaenicke - Wed May 29 21:45:30 2002]: The manual pages about the EVP wrapper do not reflect the complete history. Example: EVP_DigestInit.pod contains the function EVP_MD_CTX_init and a HISTORY section, but it does not mention, that the function was only added in 0.9.7. As especially the EVP interface has been significantly enhanced and the behaviour has changed for the 0.9.7 version, the documentation about it must reflect the changes. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #86] Bug in RSA_check_key
For now, I've added a note in the documentation of RSA_check_key() that explains that it doesn't work properly for hard keys and why. We will ponder a little more on this issue. [[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]: It wouldn't take much to make this function compatible, or the others that I haven't used and that have the same problem, maybe create a new flag for the RSA keys, I already use RSA_FLAG_EXT_PKEY, what about something like RSA_FLAG_ENGINE_PKEY, I imagine that it would force peoples to modify there code for their engines, to add this flag when they load a key. Actually, there's no reason to add yet another flag, since RSA_FLAG_EXT_PKEY is designed to point out that the key is stored externally (the comment in rsa.h explicitely mentions external hardware). -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #86] Bug in RSA_check_key
Just attaching a little more state to this ticket ... [[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]: The problem is that the use oF engines should be totaly transparent to the higher API, but apparently it's not. I don't call RSA_check_key for a hardware key, I call it for my CA private key, and I don't know if it's a hardware or software key since it's transparent. [snip] Richard just added a couple of notes to the documentation at the same time I was working on it. I may or may not put my changes over the top of his yet, but in the mean time ... I think the ultimate solution to this problem will be similar to the ultimate solution to the problem of generic key generation - ie. key generation that is independant of the ENGINE implementation being used. When you think about the underlying problem, the solution is rather obvious (but perhaps annoying to implement); the basic problem is that RSA_generate_key() and RSA_check_key() both directly deal with structure elements rather than using members of the RSA_METHOD vt. If RSA_public_decrypt() did the same thing, it would have the same problem of not working with replacement RSA implementations. I think the check_key functionality needs to go into a handler callback in the RSA_METHOD itself so that any implementation that alters the way key material is stored and managed can similarly implement a corresponding mechanism for verifying key integrity. In the mean time, the short-term solution (bear in mind this will break binary compatibility to some extent and will require all ENGINEs to be adapted) is to alter the documentation to describe the situation. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #151] S/MIME implemementation doesn't follow MIMEspec. Patch included.
Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 11:17:41 +0200, Bodo Moeller [EMAIL PROTECTED] said: moeller I think this is wrong. moeller moeller The output file is opened in text mode (not binary), so on systems moeller where line ends are usually CRLF, the \r\n will result in CR CR LF moeller sequences because \n is converted into CRLF by the system library. Good point. OK, I'll reverse that change and review the ticket... The issue as reported to me was that the body had CRLF, but headers LF only... Seems to me they should be consistent. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #151] S/MIME implemementation doesn't follow MIME spec. Patch included.
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 21:07:10 +0100, Ben Laurie [EMAIL PROTECTED] said: ben The issue as reported to me was that the body had CRLF, but headers LF ben only... ben ben Seems to me they should be consistent. I agree. However, what kinds of complications does that add regarding proper signatures and so on? Also, right now, I've no idea what the impact on VMS is. I guess I should play a bit... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #151] S/MIME implemementation doesn't follow MIME spec. Patch included.
Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 11:17:41 +0200, Bodo Moeller [EMAIL PROTECTED] said: moeller I think this is wrong. moeller moeller The output file is opened in text mode (not binary), so on systems moeller where line ends are usually CRLF, the \r\n will result in CR CR LF moeller sequences because \n is converted into CRLF by the system library. Good point. OK, I'll reverse that change and review the ticket... The issue as reported to me was that the body had CRLF, but headers LF only... Seems to me they should be consistent. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #151] S/MIME implemementation doesn't follow MIMEspec. Patch included.
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 22:07:57 +0200 (METDST), Ben Laurie via RT [EMAIL PROTECTED] said: rt The issue as reported to me was that the body had CRLF, but headers LF rt only... I just tried to find the places where the body would get a \r anywhere, and failed. Did that report give any more details? Otherwise, I think I'll consider that to be incorrect... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #151] S/MIME implemementation doesn't follow MIME spec. Patch included.
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 22:07:57 +0200 (METDST), Ben Laurie via RT [EMAIL PROTECTED] said: rt The issue as reported to me was that the body had CRLF, but headers LF rt only... I just tried to find the places where the body would get a \r anywhere, and failed. Did that report give any more details? Otherwise, I think I'll consider that to be incorrect... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #151] S/MIME implemementation doesn't follow MIMEspec. Patch included.
In message [EMAIL PROTECTED] on Thu, 18 Jul 2002 21:07:10 +0100, Ben Laurie [EMAIL PROTECTED] said: ben The issue as reported to me was that the body had CRLF, but headers LF ben only... ben ben Seems to me they should be consistent. I agree. However, what kinds of complications does that add regarding proper signatures and so on? Also, right now, I've no idea what the impact on VMS is. I guess I should play a bit... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #115] aix 5.1 openssl compiling problem and solution
I just realised that the configuration entries for AIX currently assume a 32-bit environment. The question is how gcc view this, and especially what size an int is, and also the size of a long. If either of them is 64 bits, a different configuration entry may be useful, perhaps called aix43-gcc64, which is a copy if the aix43-gcc entry, with BN_LLONG changed to SIXTY_FOUR_BIT (if the size of int is 8 bytes) or SIXTY_FOUR_BIT_LONG (if int is only 4 bytes but long is 8 bytes). Wanna try that out with -O3 and say if that made a difference? Otherwise, I'm still inclined at saying we've a compiler bug to deal with and leave it at that. [[EMAIL PROTECTED] - Wed Jul 17 21:39:38 2002]: [[EMAIL PROTECTED] - Sun Jun 23 16:44:16 2002]: hi, i try to compile openssl 0.9.6d and 0.9.7-beta2 under AIX 5.1 (ML 510002) in a 64Bit environment with gcc-2.9AIX51.xx. when i run 'make test' the following errors appear: -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #59] 0.9.7 EVP manual pages incomplete
G'day, [levitte - Thu Jul 18 20:55:58 2002]: I just did a tentative addition of history. Please check it and complete it if needed. Yup the history stuff looks great, thanks Richard. However I'm not sure who understands the EVP behavioural changes well enough to comment/document them definitively. I sure don't. I have a feeling the two most likely contenders are Ben and Steve, though both of them will probably redirect all mail from me to /dev/null for suggesting such a thing... Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #86] Bug in RSA_check_key
OK, I'm going to close this ticket down now as we have at least solved the bug, albeit that it was a bit of a short-cut ... we documented the existing behaviour rather than changing it :-) If anyone feels strongly that this is not resolved until RSA_check_key() is modified to use a new RSA_METHOD handler (ie. to allow verification of special keys), then please consider opening a new ticket without the word bug in it - it's a feature request. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #104] Make fails with undefined reference
Since this hasn't been reported by anyone else and we haven't heard from the original requestor in a while, I'm stalling this ticket. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #115] aix 5.1 openssl compiling problem and solution
Richard Levitte via RT wrote: I just realised that the configuration entries for AIX currently assume a 32-bit environment. The question is how gcc view this, and especially what size an int is, and also the size of a long. If either of them is 64 bits, a different configuration entry may be useful, perhaps called aix43-gcc64, which is a copy if the aix43-gcc entry, with BN_LLONG changed to SIXTY_FOUR_BIT (if the size of int is 8 bytes) or SIXTY_FOUR_BIT_LONG (if int is only 4 bytes but long is 8 bytes). Wanna try that out with -O3 and say if that made a difference? Otherwise, I'm still inclined at saying we've a compiler bug to deal with and leave it at that. [[EMAIL PROTECTED] - Wed Jul 17 21:39:38 2002]: [[EMAIL PROTECTED] - Sun Jun 23 16:44:16 2002]: hi, i try to compile openssl 0.9.6d and 0.9.7-beta2 under AIX 5.1 (ML 510002) in a 64Bit environment with gcc-2.9AIX51.xx. when i run 'make test' the following errors appear: -- Richard Levitte [EMAIL PROTECTED] Dear Richard, see under: http://aix43.uwaterloo.ca/aix/AIX510-Relnotes.html#Header_20 Application Support The 64-bit kernel supports both 32-bit and 64-bit applications. Application source and binaries are portable between AIX 5L Version 5.1 64-bit and 32-bit kernel systems, in the absence of any application dependencies on internal kernel details or on kernel extensions that are not supported under the 64-bit kernel but are supported under the 32-bit kernel. I think AIX build openssl as an 32bit binary and openssh also. Solaris 8 use the same mechanism. best regards thomas __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #156] Bugs in doc/crypto/{DH,DSA,RSA}_set_method.pod and doc/crypto/{dh,dsa,rsa}.pod
I'm taking a look at this now ... please hold off on reverting back to 0.9.6 (non-engine) versions of the docs until I get my head around it again (I haven't looked at this stuff for a while) ... Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Newbie Question Re: Public Key Encryption [Please help!!]
Hi,
I am trying to encrypt a session key that I created using DES_KEY_SCHEDULE. I am using
RSA_public_encrypt to encrypt the session key (8 bytes) with the public key using
RSA_PKCS1_OEAP_PADDING. This creates a 64byte encrypted session key. I send this to
the
Server on the windows machine. But 'Importing the Encrypted Session Key' on that
server
fails. That's implemented using wincrypt.h functions such as CryptImportObjectEx.
Further info: I used the public key received from the server (created using the
asymmetric_encrypt_algorithm) and I imported that using:
rsaPubKey = (RSA*) d2i_RSA_PUBKEY_bio(pub,NULL);
Now, I use this to encrypt the session key:
unsigned char ciphertext[512];
unsigned char iv[8];
unsigned char iv1[8];
RAND_seed(rnd_seed, sizeof (rnd_seed));
RAND_pseudo_bytes(iv,8);
bytecopy(iv,iv1,8);
encryptlen = RSA_public_encrypt (8, (*ks)-ks.cblock,
ciphertext, rsaPubKey,
RSA_PKCS1_OAEP_PADDING);
if(encryptlen == -1)
{
fprintf (stderr, ERROR: Failed to encrypt using public key\n);
goto proc_exit;
}
The length after this is 64, which is preferred. So, after all this when I finally
send
the 'ciphertext' chars as the encrypted session key, the server fails to import it
using
CryptImportKey (from wincrypt.h). The ERROR RECEIVED says:
Either the algorithm that works with the public key you are trying to import
is not supported by this CSP, or an attempt was made to import a session key that was
encrypted with something other than one of your public keys
If anyone has come into a similar problem or anything close, please let me
know. Any help will be tremendously appreciated. If you like to know more details or
are
interested in working with me on this, please let me know.
Thanx in advance,
J..
=
- J
|
- [EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #86] Bug in RSA_check_key
Indeed it would be a good idea, especially for RSA_generate_key, since people have to generate their key thru an interface that is extern to OpenSSL, then sign their CSR with that key using OpenSSL, when everything could be implemented within OpenSSL. The major benefit would come for, a PKI architecture based on OpenSSL, imagine a CA tree, if I want the key of the ROOT CA, the SUB-CAs to be stocked in a hardware device, you can't make it thru OpenSSL, and it become a pain in the butt if your architecture is managed thru the network, you will have to physically go on the CA computer, to generate each of the SUB-CAs keys. --- Geoff Thorpe via RT [EMAIL PROTECTED] wrote: Just attaching a little more state to this ticket ... [[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]: The problem is that the use oF engines should be totaly transparent to the higher API, but apparently it's not. I don't call RSA_check_key for a hardware key, I call it for my CA private key, and I don't know if it's a hardware or software key since it's transparent. [snip] Richard just added a couple of notes to the documentation at the same time I was working on it. I may or may not put my changes over the top of his yet, but in the mean time ... I think the ultimate solution to this problem will be similar to the ultimate solution to the problem of generic key generation - ie. key generation that is independant of the ENGINE implementation being used. When you think about the underlying problem, the solution is rather obvious (but perhaps annoying to implement); the basic problem is that RSA_generate_key() and RSA_check_key() both directly deal with structure elements rather than using members of the RSA_METHOD vt. If RSA_public_decrypt() did the same thing, it would have the same problem of not working with replacement RSA implementations. I think the check_key functionality needs to go into a handler callback in the RSA_METHOD itself so that any implementation that alters the way key material is stored and managed can similarly implement a corresponding mechanism for verifying key integrity. In the mean time, the short-term solution (bear in mind this will break binary compatibility to some extent and will require all ENGINEs to be adapted) is to alter the documentation to describe the situation. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ Post your ad for free now! http://personals.yahoo.ca __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
