[openssl.org #766] minor bug in apps/apps.c
Hello folks,
there seems to be a minor bug
in the pasword getter:
Bye
Goetz
Index: apps/apps.c
===
RCS file: /usr/cvsroot/openssl/apps/apps.c,v
retrieving revision 1.73
diff -u -r1.73 apps.c
--- apps/apps.c 2003/10/29 14:25:50 1.13
+++ apps/apps.c 2003/11/14 14:54:45
@@ -501,7 +501,7 @@
{
const char *password =
((PW_CB_DATA *)UI_get0_user_data(ui))-password;
- if (password[0] != '\0')
+ if (password password[0] != '\0')
{
UI_set_result(ui, uis, password);
return 1;
@@ -525,7 +525,7 @@
{
const char *password =
((PW_CB_DATA *)UI_get0_user_data(ui))-password;
- if (password[0] != '\0')
+ if (password password[0] != '\0')
return 1;
}
default:
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #747] -pre and -post cmd line params for openssl cmds
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #747] -pre and -post cmd line params for openssl cmds
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES counter mode
Hello Richard,
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED]
on Thu, 26 Jun 2003 12:55:22 -0400, Lee Dilkie [EMAIL PROTECTED] said:
OK, I've been follownig this discussion for a while, and it's time I
ake action. Basically, to provide for all the current and future ways
of handling the IV, I can see three alternatives:
- have the application provide a function that manipulates the IV.
- have the application specify exactly which part of the IV is the
actual counter (in bit positions, or would byte positions be
enough?).
The application specifies 4 datas:
1. a step size
2. a bit mask.
3. a (optional) pointer to a function that is called if the
step bits that are not in the bit mask:
4. a (optional) pointer to a function doing the counting;
A quick draft of my idea:
typedef struct _CounterData CounterData;
struct _CounterData
{
Counter_Number nActual; /* the actual counter value */
Counter_Number nStep;/* Step size added each step */
Counter_Number nStepMask;/* Mask indikating when counter leaves
range */
int (*Count)(CounterData *pCounter); /* optional: handle a step,
returns: 0: error
returns: 0: OK. */
int (*Range)(CounterData *pCounter); /* optional: is called if
Count() returns out of range.
returns: 0: error
returns: 0: OK */
};
int Count(CounterData *pCounter)
{
if (!pCounter)
return -1;
pCounter-nActual+= pCounter-nStep;
return 1;
}
int Range_restart(CounterData *pCounter)
{
if (!pCounter)
return -1;
pCounter-nActual = ~pCounter-nStepMask;
return 1;
}
int Range_terminate(CounterData *pCounter)
{
return -1;
}
int Do_Counter(CounterData *pCounter)
{
int nRet;
if (!pCounter)
return -1;
if (pCounter-Count)
nRet = pCounter-Count(pCounter);
else
nRet = Count(pCounter);
if (nRet 0)
return nRet;
if (pCounter-nActual ~pCounter-nStepMask)
{
if (pCounter-Range)
return pCounter-Range(pCounter);
else
return Range_restart(pCounter);
}
return nRet;
}
OK.
The Mask could be an upper bound...
Any comments ?
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
smime.p7s
Description: S/MIME Cryptographic Signature
Re: 64-bit vs 32-bit systems
Hello, [EMAIL PROTECTED] wrote: 64-bit vs 32-bit systems It looks to me like a 64-bit client cant connect to a 32-bit server. The ASN1 structures/headers have int's and longs scattered throughout them (and probably in other parts of the openssl libraries). In fact, the 32-bit server fails to recieve a connection with the error bad asn1 object header. That are 2 different kind of shoes. Structures and headers are not direct related to the data on the wire.. I think you have configured on a 32 bit system and build on a 64 bit system, or build the library on a 32 bit system and your program on a 64 bit system... My question is, how self contained is this software. Could the longs be replace by ints to keep the structures the same size on both systems? Why ? You need the headers only if you build a program. And you shouldn't link a openssl build on a 32 bit system with a program build on a 64 bit system... Has this issue been discusses before? AFAIK not. perhaps openssl should migrate to the types defined in stding.h ? But that comes with ISO C99, so an fallback should be supported... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: [CVS] OpenSSL: OpenSSL_0_9_7-stable: openssl/ CHANGES openssl/crypto/r...
Hello Bodo, Bodo Moeller wrote: Server: cvs.openssl.org Name: Bodo Moeller Root: /e/openssl/cvs Email: [EMAIL PROTECTED] Module: openssl Date: 19-Mar-2003 19:58:56 Branch: OpenSSL_0_9_7-stable Handle: 2003031918585302 Log: make sure RSA blinding works when the PRNG is not properly seeded; disable it automatically only for the built-in engine patch -p0 '@@ .' Index: openssl/crypto/rsa/rsa.h $ cvs diff -u -r1.36.2.5 -r1.36.2.6 rsa.h --- openssl/crypto/rsa/rsa.h 30 Jan 2003 18:52:52 - 1.36.2.5 +++ openssl/crypto/rsa/rsa.h 19 Mar 2003 18:58:55 - 1.36.2.6 @@ -158,6 +158,11 @@ #define RSA_FLAG_CACHE_PUBLIC0x02 #define RSA_FLAG_CACHE_PRIVATE 0x04 #define RSA_FLAG_BLINDING0x08 +#define RSA_FLAG_NO_BLINDING 0x80 /* new with 0.9.7b; the built-in RSA + * implementation now uses blinding by + * default (ignoring RSA_FLAG_BLINDING), + * but other engines might not need it + */ [...] #define RSA_FLAG_SIGN_VER0x4 + +#define RSA_FLAG_NO_BLINDING 0x80 ??? Why define it two times ? Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl.org #492] SSL: server root certs and client auth.
Hello Steve, Stephen Henson via RT wrote: I've committed a fix to address this issue which will appear in the next dev and stable snapshot (i.e. so it will appear in 0.9.7a). Let me know of any problems ASAP. I finally got around to do some quick tests. Seems to be OK. Could SSL_MODE_NO_AUTO_CHAIN be the default, with an additional flag SSL_MODE_AUTO_CHAIN ? Now I have to ask Ralf Engelschall to set the flag in mod_ssl... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: IMPORTANT: please test snapshot openssl-0.9.7-stable-SNAP-20030214.tar.gz
Hello Bodo, Bodo Moeller wrote: Please test snapshot openssl-0.9.7-stable-SNAP-20030214.tar.gz (or later), which will be available today around 8 p.m. GMT at URL: ftp://ftp.openssl.org/snapshot;type=d . OpenSSL 0.9.7a-dev XX xxx 2003 built on: Fri Feb 14 22:35:41 CET 2003 platform: debug-linux-pentium options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -mcpu=pentium -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM make test OK. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl.org #492] SSL: server root certs and client auth.
Hello Steve, Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Mon Feb 10 16:53:48 2003]: Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Fri Feb 7 14:09:28 2003]: It really needs replacing with something less horrible. For example it might: 1. Build the chain using the normal certificate verify code including the usual checks on validity and using appropriate purpose and trust. 2. Give a (fatal?) error if the verification fails. 3. Include a flag to exclude the root CA from outputted chain 4. Include an flag to disable the automatic chain building altogether and rely on the chain being correctly present in the extra certs of the context. I don't see a need for points 3 and 4. Points 1 to 3 are largely doing what it does now but properly. However it would require some changes to OpenSSL and some new APIs for example for new selectable purposes and trust settings for the chain build and (possibly) a new cert store. OK. I should clarify myself: It is to do it correctly, but not needed to fix the actual problem. However option 4 easy to do and could be argued as being a bug fix. OK. Perhaps something like: build the chain only with the certs supplied with SSL_CTX_add_extra_chain_cert() If the CA certs for the server cert are in a seperate list, the content of the cert chain is in control of the user. And if he doesn't want the root cert in the chain, he only has to exclude them in the config file. The actual bug is only because OpenSSL tried to be to smart and included in the list certificates it never was told to include... All I want to have is something like: build the list of server CA certs from the given file (or build by SSL_CTX_add_extra_chain_cert()) (in the order I give) and _don't_ include any other certificates... That's exactly what point 4 would do. You do something like: SSL_CTX_set_mode(ctx, SSL_MODE_NO_AUTO_CHAIN); at some stage and it would then just use the supplied certificate(s) in SSL_CTX_add_extra_chain_cert(). That are two different things: 1. build the chain with the certs from SSL_CTX_add_extra_chain_cert() 2. verify the chain is correct (trust settings OK, certs not expired,...) 5. Cache the path after it has been determined. Or build it one time and reuse it... Which leads to the interesting problem of when to build the chain. If its done on first use this will result in configuration errors only being apparent after a client connects. I think it should be done in SSL_CTX_add_extra_chain_cert(). But the return value contains to few information: only OK or failed. But the chain has 3 states: * error in cert chain * chain certs vaild but incomplete * chain certs valid and complete How integrate that in the actual interface ? since at least mod_ssl test for != 0, a quick solution would be: * error in cert chain = 0 * chain certs vaild but incomplete = 1 * chain certs valid and complete = 2 On the other hand the way that the various certificates and stores are presented in arbitrary order, not to mention a new SSL_MODE_NO_AUTO_CHAIN flag makes it trickier to determine when its OK to build the chain. As I suggested: Build it in SSL_CTX_add_extra_chain_cert() and return a different code for a complete chain... Of course the cached chain might also become invalid at some point in the future, such as when a certificate expires... Opens an other question: There are two validity models for cert chains: 1. A CA cert needs only to be be valid the moment the end entity cert is issued 2. A CA cert must be valid the complete life time of the end entity cert. In both cases you only have to check for expired CA certificates when you add a certificate to the chain... Becomes more complicated if you add OCSP... So you check the complete chain in SSL_CTX_add_extra_chain_cert() and check the host certificate when it is needed... But if you want to use the chain until any certificate in it expires, you can add a time stamp to it (this chain expires at ...) Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #492] SSL: server root certs and client auth.
Hello Steve, Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Mon Feb 10 20:02:40 2003]: OK. I should clarify myself: It is to do it correctly, but not needed to fix the actual problem. However option 4 easy to do and could be argued as being a bug fix. OK. Perhaps something like: build the chain only with the certs supplied with SSL_CTX_add_extra_chain_cert() Perhaps I should clarify myself too :-) The current situation is not good. If the primitive auto chain building comes up with the wrong answer then there isn't any easy method I can think of that will allow it to fix things. ACK Giving no certificate store at all and doing all its own verification might work but it's a hack. As a result IMHO we need a way to do *something* in OpenSSL 0.9.7X. If it is decided that a 0.9.7X fix is needed then this should be a minimal bug fix solution that keeps the changes in functionality down to a minimum but gives the application some method of correcting things when the chain build breaks. ACK For that maybe a new flag or possibly auto disable of the chain build if any extra certs are added. After all if the application is supplying extra certs it presumably is expecting the auto chain build to fail anyway? I can't see any legitimate reason for supplying extra certs *and* having auto chain build. That confused me too. The extra certs would be sent verbatim which is what 0.9.7 currently does anyway. Doing things properly will need new functionality and new functions and possibly break existing applications. As such that should be a 0.9.8 target. ACK For example what purpose and trust settings do you use in the chain building? The defaults will be SSL server for servers and SSL client for clients but some applications might need something different which the current primitive chain build will handle but the correct version wont. I don't think that we should do there to much checks. We should check: * the validity period (begin end) of all certs * the trust settings for all certificates * the purpose for the CA certs I don't think we really should check the purpose of the own certificate. (At least not break if it doesn't matches.) A mismatching purpose should result in a warning but not in an error. But since OpenSSL has no warnings... If the purpose of the certificate doesn't match, the peer should decide if a connection is established. In special cases it is usefull to use a client cert for a server and a server key for a client. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem / unwanted behavior with SSL server and CA certs
Hello Lutz, Lutz Jaenicke wrote: On Thu, Feb 06, 2003 at 07:42:39PM +0100, Götz Babin-Ebell wrote: Hell folks, there seems to be a strange behavior with CA certificates in SSL server: I create a SSL_CTX for a server, set the certificate and the private key and add some CA certificates for client auth. with SSL_CTX_add_client_CA(). (I don't set a server CA certificate, but in the list of client CA certificates are 2 certificates with a DN that matches the issuer DN of the server certificate) But opening a SSL conection, my server still sends a CA certificate. How can I prevent the server from sending the root CA ? With the current API it is not possible to influence this behaviour: if the cert chain is incomplete, the library will automatically try to round up from the store of trusted CAs. But the chain is complete. Whe have for one root key pair issued 2 certificates with the same DN. One with a validity ending 2005, the other ending 2011. older browsers have the 2005 cert and newer ones the 2011 cert. Now want some of our customers (using apache) to use client authentication with certificates issued by us. So if they put the 2005 cert in their client CA cert list, customers with newer Mozilla / Netscape 7 complain that the server cert is not trusted (issued by an unknown CA)... Using the 2011 CA cert doesnt help, because then clients with an older browser (containing the 2005 cert) complain... Hmm. I vaguely remember a report quite some time ago, that in a similar situation the wrong CA certificate could be picked and thus an invalid chain might be created... If this also happens in your case, please file a bug report to [EMAIL PROTECTED] Done. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: PKCS#11 engines revisited]
Geoff Thorpe schrieb: (b) any/all access information (eg. control commands, authorisation data, the ENGINE id if necessary, etc) that you *want* to include in the key file should not go into the raw PEM format itself but instead should be embedded in the per-'nid' data blob. This way, you can define bigger and better 'nid's later on rather than having to figure out how to fit new ideas into old structures. I don't agree here. This seems to be a way to handle some few keys on one machine. But imagine: You have to work with = 100 keys one = 2 machines. And you have to change your configuration. This way you must open the key file, decrypt the PEM encryption, access and change the configuration, encrypt and save the key data. And this for 100 keys with different pass phrases. The rack with your servers get's a new meaning... Note that Goetz's reply mentioned he would rather not include all access information in the key files - I don't necessarily think that is required by this approach. However the idea of having to configure and manage the information in a distinct service is no better - you have to solve all the same problems, you have to manage an interface between the OpenSSL code and this general service, and you've got two points where things can go wrong rather than one. But storing all access information in the key files results in 2 points where things can go wrong, too: 1. The key file and 2. the configuration in your programms to access the key files The data you have to change for a changed configuration is: * key access data stored in pem files: 2 * (number of) keys * key access data stored in configuration: 2 * (number of) applications Have you more keys or applications ? At least we have more keys than key using applications... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: [Announce] OpenSSL 0.9.7-beta3 (Security)
Lutz Jaenicke schrieb: On Tue, Jul 30, 2002 at 09:35:40PM +0200, Götz Babin-Ebell wrote: PLEASE: could these message be digitally signed ? We will update our release procedures. Fine... (A signature file for the 0.9.7e beta would be nice...) The signature file is available from the ftp-repository. I've written 0.9.7e beta but meant 0.9.7-beta3... On the ftp-server are files containing the md5 hash. But if somebody can modify the *.tar.gz, he can modify the *.tar.gz.md5... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: [Announce] OpenSSL 0.9.7-beta3 (Security)
Lutz Jaenicke schrieb: Hello, The third beta release of OpenSSL 0.9.7 is now available from the OpenSSL FTP site URL: ftp://ftp.openssl.org/source/. Quite a lot of code changed between the 0.9.6 release and the 0.9.7 release, so a series of 3 or 4 beta releases is planned before the final release. SECURITY INFORMATION: o Several security fixes were newly introduced to OpenSSL 0.9.6e, see OpenSSL Security Advisory [30 July 2002]. o OpenSSL 0.9.7-beta3 is the first 0.9.7-beta release containing these fixes. Users of older beta versions or snapshots are urged to upgrade to 0.9.7-beta3. [...] As mentioned before: PLEASE: could these message be digitally signed ? (A signature file for the 0.9.7e beta would be nice...) Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: openssl/crypto/evp c_all.c evp.h
Lutz Jaenicke schrieb:
On Sat, Jun 15, 2002 at 01:01:08AM +0200, Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Fri, 14 Jun 2002
20:59:59 +0200 (MET DST), [EMAIL PROTECTED] said:
jaenicke diff -u -r1.7.8.1 -r1.7.8.2
jaenicke --- c_all.c 2002/02/23 02:09:25 1.7.8.1
jaenicke +++ c_all.c 2002/06/14 18:59:53 1.7.8.2
jaenicke @@ -61,6 +61,7 @@
jaenicke#include openssl/evp.h
jaenicke
jaenicke#undef OpenSSL_add_all_algorithms
jaenicke +void OpenSSL_add_all_algorithms(void);
jaenicke
jaenickevoid OpenSSL_add_all_algorithms(void)
jaenicke {
Please explain why you need to declare that function just before you
define it. I can't see how that makes sense...
This was done by Goetz's patch. I have also seen gcc complain about functions
without prototype just when they where defined.
Building OpenSSL with debug (at least on linux)
will generate build lines like
gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -DOPENSSL_NO_KRB5
-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -ggdb
-g2 -Wformat -Wshadow -Wmissing-prototypes -Wmissing-declarations
-Werror -c -o hw_ncipher.o hw_ncipher.c
and the -Wmissing-declarations with the -Werror will
terminate the build process on not declared functions.
They have to either be declared or static...
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
smime.p7s
Description: S/MIME Cryptographic Signature
[openssl.org #105] Problem build 0.9.7 SNAP with ./Configure debug
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #98] Re: OpenSSL engine ctrl: handling of strings
Lutz Jaenicke schrieb:
On Sat, Jun 15, 2002 at 07:38:40PM -0400, Geoff Thorpe wrote:
On Fri, 14 Jun 2002, [ISO-8859-15] Götz Babin-Ebell wrote:
In the ..._ctrl()-Function of the engines a passed string
is only referenced and not copyed.
This is bad if the buffer with the passed data is overwritten...
[snip]
Could you please;
(a) put this into the bug-tracker,
I have already bounced the report into the request tracker when I read it.
(It was assigned ticket #98.)
(b) use -u context diffs so they're easier to follow
That's indeed true.
Sorry for that. (Please see attachment)
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
diff -u -r openssl-0.9.7-stable-SNAP-20020618/crypto/engine/eng_dyn.c
openssl-0.9.7-stable-SNAP-20020618_new/crypto/engine/eng_dyn.c
--- openssl-0.9.7-stable-SNAP-20020618/crypto/engine/eng_dyn.c Thu Nov 22 11:08:49
2001
+++ openssl-0.9.7-stable-SNAP-20020618_new/crypto/engine/eng_dyn.c Tue Jun 18
+14:08:05 2002
-157,6 +157,10
dynamic_data_ctx *ctx = (dynamic_data_ctx *)ptr;
if(ctx-dynamic_dso)
DSO_free(ctx-dynamic_dso);
+if (ctx-DYNAMIC_LIBNAME)
+ OPENSSL_free((void*)(ctx-DYNAMIC_LIBNAME));
+if (ctx-engine_id)
+ OPENSSL_free((void*)(ctx-engine_id));
OPENSSL_free(ctx);
}
}
-169,7 +173,7
{
dynamic_data_ctx *c;
c = OPENSSL_malloc(sizeof(dynamic_data_ctx));
- if(!ctx)
+ if(!c)
{
ENGINEerr(ENGINE_F_SET_DATA_CTX,ERR_R_MALLOC_FAILURE);
return 0;
-310,8 +314,13
/* a NULL 'p' or a string of zero-length is the same thing */
if(p (strlen((const char *)p) 1))
p = NULL;
- ctx-DYNAMIC_LIBNAME = (const char *)p;
- return 1;
+if (ctx-DYNAMIC_LIBNAME)
+ OPENSSL_free((void*)(ctx-DYNAMIC_LIBNAME));
+if (p)
+ ctx-DYNAMIC_LIBNAME = BUF_strdup(p);
+else
+ ctx-DYNAMIC_LIBNAME = NULL;
+return ctx-DYNAMIC_LIBNAME != NULL ? 1 : 0;
case DYNAMIC_CMD_NO_VCHECK:
ctx-no_vcheck = ((i == 0) ? 0 : 1);
return 1;
-319,8 +328,13
/* a NULL 'p' or a string of zero-length is the same thing */
if(p (strlen((const char *)p) 1))
p = NULL;
- ctx-engine_id = (const char *)p;
- return 1;
+if (ctx-engine_id)
+ OPENSSL_free((void*)(ctx-engine_id));
+if (p)
+ ctx-engine_id = BUF_strdup(p);
+else
+ ctx-engine_id = NULL;
+return ctx-engine_id != NULL ? 1 : 0;
case DYNAMIC_CMD_LIST_ADD:
if((i 0) || (i 2))
{
diff -u -r openssl-0.9.7-stable-SNAP-20020618/crypto/engine/hw_4758_cca.c
openssl-0.9.7-stable-SNAP-20020618_new/crypto/engine/hw_4758_cca.c
--- openssl-0.9.7-stable-SNAP-20020618/crypto/engine/hw_4758_cca.c Wed May 22
10:03:17 2002
+++ openssl-0.9.7-stable-SNAP-20020618_new/crypto/engine/hw_4758_cca.c Tue Jun 18
+14:08:28 2002
-124,8 +124,27
/* static variables */
/*--*/
-static const char def_CCA4758_LIB_NAME[] = CCA_LIB_NAME;
-static const char *CCA4758_LIB_NAME = def_CCA4758_LIB_NAME;
+static const char *CCA4758_LIB_NAME = NULL;
+static const char *get_CCA4758_LIB_NAME()
+{
+ if (CCA4758_LIB_NAME)
+ return CCA4758_LIB_NAME;
+ else
+ return CCA_LIB_NAME;
+}
+static void free_CCA4758_LIB_NAME()
+{
+ if (CCA4758_LIB_NAME)
+ OPENSSL_free((char*)CCA4758_LIB_NAME);
+ CCA4758_LIB_NAME = NULL;
+}
+static long set_CCA4758_LIB_NAME(const char *newName)
+{
+ if (CCA4758_LIB_NAME)
+ OPENSSL_free((char*)CCA4758_LIB_NAME);
+ return (CCA4758_LIB_NAME = BUF_strdup(newName)) != NULL ? 1 : 0;
+}
+
#ifndef OPENSSL_NO_RSA
static const char* n_keyRecordRead = CSNDKRR;
static const char* n_digitalSignatureGenerate = CSNDDSG;
-232,6 +251,7
static int ibm_4758_cca_destroy(ENGINE *e)
{
ERR_unload_CCA4758_strings();
+free_CCA4758_LIB_NAME();
return 1;
}
-243,7 +263,7
goto err;
}
- dso = DSO_load(NULL, CCA4758_LIB_NAME , NULL, 0);
+ dso = DSO_load(NULL, get_CCA4758_LIB_NAME() , NULL, 0);
if(!dso)
{
CCA4758err(CCA4758_F_IBM_4758_CCA_INIT,CCA4758_R_DSO_FAILURE);
-299,7 +319,8
static int ibm_4758_cca_finish(ENGINE *e)
{
- if(dso)
+ free_CCA4758_LIB_NAME();
+ if(!dso)
{
CCA4758err(CCA4758_F_IBM_4758_CCA_FINISH
Re: [openssl.org #97] About 0.9.6a(b) and des_encrypt1()
Richard Levitte - VMS Whacker wrote: From: Jani Taskinen [EMAIL PROTECTED] sniper From CHANGES: sniper sniper *) Rename 'des_encrypt' to 'des_encrypt1'. This avoids the clashes sniper with des_encrypt() defined on some operating systems, like Solaris sniper and UnixWare. sniper [Richard Levitte] sniper sniper sniper Just wanted to let you guys know, that also sniper this symbol is in use by Solaris (7), libcrypt: sniper sniper # nm /usr/lib/libcrypt.a | grep des_encrypt sniper U _des_encrypt sniper des_encrypt.o: sniper T _des_encrypt1 sniper W des_encrypt1 sniper 025c T _des_encrypt sniper U _des_encrypt1 sniper 025c W des_encrypt sniper 01bc t des_encrypt_nolock Hmm, it feels like it's really time for a rename (basically, change des to DES in all names, and thereby follow the convention used everywhere else in OpenSSL), or this becomes an impossible task. openssl_des_... ? in the sources we can have a #define des_...() openssl_des_...() By Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #98] OpenSSL engine ctrl: handling of strings
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #89] missing prototypes for functions
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #63] something like a bug in pkcs12: p12_kiss.c
Götz Babin-Ebell via RT wrote:
Oups.
It seems I didn't mention the OpenSSL version:
0.9.6c / 0.9.7 (snap from 28.05.2002)
Sorry...
Hello folks,
there seems to be a bug in pkcs12/p12_kiss.c:
PKCS12_parse():
if you enter the function with an allocated
ca stack and the parse fails,
the ca stack will be deallocated and the pointer not cleared.
[...]
[...]
int PKCS12_parse (PKCS12 *p12, const char *pass, EVP_PKEY **pkey, X509
**cert,
STACK_OF(X509) **ca)
{
int freeca=0;
/* Check for NULL PKCS12 structure */
if(!p12) {
PKCS12err(PKCS12_F_PKCS12_PARSE,PKCS12_R_INVALID_NULL_PKCS12_POINTER);
return 0;
}
/* Allocate stack for ca certificates if needed */
if ((ca != NULL) (*ca == NULL)) {
if (!(*ca = sk_X509_new_null())) {
PKCS12err(PKCS12_F_PKCS12_PARSE,ERR_R_MALLOC_FAILURE);
return 0;
}
freeca=1;
}
[...]
err:
if (pkey *pkey) EVP_PKEY_free(*pkey);
if (cert *cert) X509_free(*cert);
if (ca freeca) sk_X509_pop_free(*ca, X509_free);
return 0;
[...]
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: 4/23/2002 11:59:51 PM
Ralf S. Engelschall wrote: In article [EMAIL PROTECTED] you wrote: On Tue, Apr 23, 2002 at 10:24:23PM -0600, Kurt Seifried wrote: [...] I cannot comment on the OpenSSL-Announce list. Only the core members should be allowed to send via this list. Probably the list should be switched to moderated (it currently does not seem to be moderated, does it?). Hmm... yes, correct, it not moderated, but allows only the team members to post. Hmmm.. but as said, this does not prevent this new form of spamming. I've switched it to full moderation status now. Thanks for the hint. And only accept mails with a valid signature from an allowed sender ? Would be good to force some kind of signature on *announce anyway... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: Best way to handle includes?
John Cebasek wrote: Hi All; Hello John, I need some comments. We've been creating some 'black boxes' for other developers in our company to work with. One of the black boxes is opensll. We want to distribute to our developers just 'enough'. So they'll be getting the libraries, but what do I have to give them in the way of includes. Should the developers just get the include/openssl directory or can I trim that down more. Why would you do that ? You can't hide any information about OpenSSL that way. If your developer want to see the full list of headers, they can get them from www.openssl.org. (besides the sources...) And figuring out which header they need costs time you really should spent on doing something usefull. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
RAND_status() returns to few info.
Hello,
is there a way to ask the random engine about how much randomness
it contains ?
RAND_status() returns 1 if the random pool contains at least
20 bytes (ENTROPY_NEEDED in rand_lcl.h).
That is OK for SSL handshake, but for asymetric key generation
we need a lot of more entropy.
Something like RAND_status1(size_t needed) would be better...
eg:
...
if (RAND_status1(key_length) = 0)
{ /* this part never reached if we have a crypto device... */
RAND_load_file(...); /* load some additional ramdom data */
}
...
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
smime.p7s
Description: S/MIME Cryptographic Signature
e_os.h allways defines _REENTRANT on sun ?
from e_os.h: #if defined(THREADS) || defined(sun) ^^^ #ifndef _REENTRANT #define _REENTRANT #endif #endif why ? and why is it exported ? Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: Changes to openssl genrsa
Dave Barter wrote: I hope I have the right list for this, my apologies if I don't. I would like to modify the openssl genrsa program to quietly generate keys, ie. Not print the '.' and '+' characters to STDOUT when generation occurs. Basically I would like to add the flag -quiet to the genrsa command line. I guess this may be useful in other functions as well, or it may be that I am the only person annoyed by it ! I have had a brief glance at the code to try and ascertaint the best way to do this, and notice that in genrsa.c for example all output to the screen goes through a function called BIO_printf(). I was considering modifying this function to suppress output if the -quiet flag was present. openssl-SNAP-20011003 grep BIO_printf crypto/*/*.c ssl/*.c | wc -l 227 Are you really shure you don't break something with this change ? Could somebody on the list give me a brief summary of the BIO_printf function and also advise whether there would be a better method to achieve my aim. it is a printf for the BIO interface. If you don't want these outputs, change the callbacks that print them... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: openssl/crypto mem_dbg.c
[EMAIL PROTECTED] wrote: Index: mem_dbg.c === if (mh == NULL) return; + /* Need to turn off memory checking when allocated BIOs ... especially + * as we're creating them at a time when we're trying to check we've not + * left anything un-free()'d!! */ + MemCheck_off(); if ((b=BIO_new(BIO_s_file())) == NULL) return; + MemCheck_on(); Um. If BIO_new(BIO_s_file()) fails, you yust turned mem checking of... better is: MemCheck_off(); b=BIO_new(BIO_s_file()); MemCheck_on(); if (b == NULL) return; By Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: About 0.9.6a(b) and des_encrypt1()
Richard Levitte - VMS Whacker wrote: From: Jani Taskinen [EMAIL PROTECTED] sniper From CHANGES: sniper sniper *) Rename 'des_encrypt' to 'des_encrypt1'. This avoids the clashes sniper with des_encrypt() defined on some operating systems, like Solaris sniper and UnixWare. sniper [Richard Levitte] sniper sniper sniper Just wanted to let you guys know, that also sniper this symbol is in use by Solaris (7), libcrypt: sniper sniper # nm /usr/lib/libcrypt.a | grep des_encrypt sniper U _des_encrypt sniper des_encrypt.o: sniper T _des_encrypt1 sniper W des_encrypt1 sniper 025c T _des_encrypt sniper U _des_encrypt1 sniper 025c W des_encrypt sniper 01bc t des_encrypt_nolock Hmm, it feels like it's really time for a rename (basically, change des to DES in all names, and thereby follow the convention used everywhere else in OpenSSL), or this becomes an impossible task. openssl_des_... ? in the sources we can have a #define des_...() openssl_des_...() By Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: [ANNOUNCE] OpenSSL 0.9.6b
Richard Levitte wrote: Hello Richard, As a few people noticed, not only was the announcement of OpenSSL 0.9.6b sent more than once (due to, eh, technical error...), but the version number was 0.9.6a everywhere in the message body! Shit happens... OpenSSL version 0.9.6b released === [...] The distribution file names are: o openssl-0.9.6b.tar.gz [normal] o openssl-engine-0.9.6b.tar.gz [engine] Yours, The OpenSSL Project Team... Could you start signing such mails ? And please, include a hash for the distribution files. Server can be hacked and this is a security sensitive area... By Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: OpenSSL IV and -K oddness
Andy Brown wrote: I believe I've found a bug with the UNIX command-line "openssl enc" It's not a bug, it's a feature... ;-) utility. If you specify the hex key (with -K) on the command line, the IV is some randomish garbage, probably whatever happens to be in memory. Shouldn't the default IV be zero in this case? No. As long the IV is not set, the program selects one. When the hex key (-K) is specified: 1) A garbage salt is presented 2) A garbage IV is presented That is OK... The garbage salt and IVs are sometimes different on different shell instances. They are also sometimes different if I specify the base64 output (-a) option: $ openssl enc -des -K -P salt=FFBEFB68 key= iv =FFBEF568000277FC $ openssl enc -des -a -K -P salt=FFBEFB60 key= iv =FFBEF56277FC This leads me to believe it's an allocation problem. It is not. If no IV is set, it is undefined and some random value is used. (an uninitialized part of the memory...) Perhaps it would be better to fill it with random data... By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl CHANGES
[EMAIL PROTECTED] wrote: levitte 29-Mar-2001 09:45:09 Modified:crypto/des Tag: OpenSSL_0_9_6-stable xcbc_enc.c speed.c pcbc_enc.c ofb_enc.c ofb64enc.c ncbc_enc.c ede_cbcm_enc.c ecb_enc.c des_opts.c des_enc.c des.h cfb_enc.c cfb64enc.c cbc_cksm.c .Tag: OpenSSL_0_9_6-stable CHANGES Log: Since there has been reports of clashes between OpenSSL's des_encrypt() and des_encrypt() defined on some systems (Solaris and Unixware and maybe others), we rename des_encrypt() to des_encrypt1(). This should have very little impact on external software unless someone has written a mode of DES, since that's all des_encrypt() is meant for. I think OPENSSL_des_encrypt would have been a better choice... By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 Visit us at CeBIT 2001 in Hall 06, booth C40 S/MIME Cryptographic Signature
EVP: sign/verify and padding
Hallo, has the EVP interface (sign/verify) a way to specify the padding for the signed data ? And I would like to add a way to support other padding types (something like RSA_add_padding(..., int adding, int (*fct)(unsigned char *to, int tlen, unsigned char *from,int flen)) ) By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
