[openssl.org #364] Fw: BUG ?: ssl_bio.c increase reference count (BIO_push), but doesn't remove it (BIO_pop)

2002-11-26 Thread Jonas Sundgren via RT

Below msg is a re-send to the correct address [EMAIL PROTECTED] -- Sorry for
mailing it to the wrong place!! /Jonas

- Original Message -
From: Jonas Sundgren [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 26, 2002 2:43 AM
Subject: BUG ?: ssl_bio.c increase reference count (BIO_push), but doesn't
remove it (BIO_pop)


 Env: openssl-0.9.6g (9-aug-2002), VC6/masm, WinXP

 Hi,

 When you do BIO_push on a SSL BIO object, reference count
(CRYPTO_LOCK_BIO)
 is increased on next BIO object. The problem is when you later pop the SSL
 BIO, then the reference count isn't decreased. This isn't a problem as
long
 as you're supposed to do BIO_free twice on next BIO (a socket BIO in my
 case). I want to do one, single BIO_free on my socket BIO and it should
 shutdown/close the socket--but that doesn't work! (Example code below,
after
 the diff)

 Is this correct behavior? Have I missed something? If not, below fix works
 for me:

 Index: crypto/bio/bio_lib.c
 ===
 RCS file: c:\cvsroot/openssl-0.9.6g/crypto/bio/bio_lib.c,v
 retrieving revision 1.1
 diff -u -r1.1 bio_lib.c
 --- crypto/bio/bio_lib.c 2 Nov 2002 13:02:10 - 1.1
 +++ crypto/bio/bio_lib.c 26 Nov 2002 00:48:15 -
 @@ -381,6 +381,9 @@

   if (b == NULL) return(NULL);
   ret=b-next_bio;
 +
 +/* called to do internal process before bio is unlinked */
 +BIO_ctrl(b,BIO_CTRL_POP,0,NULL);

   if (b-prev_bio != NULL)
b-prev_bio-next_bio=b-next_bio;
 @@ -389,7 +392,6 @@

   b-next_bio=NULL;
   b-prev_bio=NULL;
 - BIO_ctrl(b,BIO_CTRL_POP,0,NULL);
   return(ret);
   }

 Index: ssl/bio_ssl.c
 ===
 RCS file: c:\cvsroot/openssl-0.9.6g/ssl/bio_ssl.c,v
 retrieving revision 1.1
 diff -u -r1.1 bio_ssl.c
 --- ssl/bio_ssl.c 2 Nov 2002 13:03:47 - 1.1
 +++ ssl/bio_ssl.c 26 Nov 2002 01:28:44 -
 @@ -399,6 +399,8 @@
 {
 BIO_free_all(ssl-wbio);
 }
 +  if (b-next_bio != NULL)
 +   CRYPTO_add(b-next_bio-references,-1,CRYPTO_LOCK_BIO);
ssl-wbio=NULL;
ssl-rbio=NULL;
break;


 Example code:
 ...
 sockbio = BIO_new_socket(s, BIO_CLOSE);
 sslbio = BIO_new_ssl(g_Ssl.ctx, TRUE);
 if (!sslbio)
 goto cleanup;

 BIO_push(sslbio, sockbio);
 if (BIO_do_connect(sslbio) = 0)
 goto cleanup;

 SendHttpRequest(sslbio);
 ReadHttpResponse(sslbio);

 BIO_ssl_shutdown(sslbio);
 BIO_pop(sslbio);

 success = TRUE;

 cleanup:
 /* BUG ?: Have to do BIO_free twice on sockbio, otherwise it won't
free
 it nor close the socket */
 BIO_free(sockbio);
 BIO_free(sslbio);
 ...


 Thanks,
 Jonas Sundgren

 PS. The same problem exists in openssl-0.9.7-beta4 as well.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #346] 0.9.7-beta4: can't compile with kerberos support

2002-11-26 Thread Richard Levitte via RT

I have disabled Heimdal support from Configure.  It's possible to 
force the use of Heimdal, but that comes with warnings.

This ticket is now resolved.

[[EMAIL PROTECTED] - Tue Nov 19 16:10:23 2002]:

 Hi,
 
 I tried these configuration options:
 
 --with-krb5-flavor=Heimdal \
 --with-krb5-dir=/usr \
 --with-krb5-lib=/usr \
 --with-krb5-include=-I/usr/include/heimdal \
 
 The build fails with these errors:
 
 make[1]: Entering directory `/usr/src/packages/BUILD/openssl-
0.9.7_beta4/ssl'
 gcc -I../crypto -I.. -I../include -I/usr/include/heimdal -fPIC
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-DKRB5_HEIMDAL -DL_ENDIAN -DOPENSSL_NO_RC5 -DOPENSSL_NO_IDEA -O2
-march=i586 -mcpu=i686 -fmessage-length=0 -fomit-frame-pointer
-DTERMIO -Wall  -DSHA1_ASM -DMD5_ASM -DRMD160_ASM   -c -o 
s2_meth.o
s2_meth.c
 In file included from ../include/openssl/ssl.h:179,
  from ssl_locl.h:129,
  from s2_meth.c:59:
 ../include/openssl/kssl.h:155: parse error before KSSL_ERR
 ../include/openssl/kssl.h:157: parse error before 
krb5_ticket_times
 ../include/openssl/kssl.h:159: parse error before '*' token
 ../include/openssl/kssl.h:165: parse error before 
krb5_ticket_times
 ../include/openssl/kssl.h:167: parse error before KSSL_ERR
 make[1]: *** [s2_meth.o] Error 1
 make[1]: Leaving directory `/usr/src/packages/BUILD/openssl-
0.9.7_beta4/ssl'
 make: *** [sub_all] Error 1
 
 
 BTW, I have to prefix the include path like this:
 --with-krb5-include=-I/usr/include/heimdal \
 ^^
 to make the Configure script to put it like that into the 
Makefiles.
 Without the -I it is only the path that ends up on the command 
line.
 
 Peter


-- 
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #358] patch for openssl-SNAP-20021120. Attempt to improve configurability.

2002-11-26 Thread Richard Levitte via RT

I can understand wanting to disable the use of sockets.  I can't 
understand why OCSP or speed should be disabled, however.  Please 
explain.

[[EMAIL PROTECTED] - Sat Nov 23 19:46:14 2002]:

 Hi,
 
 This patch makes it possible to build apps/openssl without the 
speed
 and ocsp programs and without sockets.
 
 to disable apps/speed.c (openssl speed) just Configure with 
no-speed.
 
 Thank you,
 Enrique
 
 diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
20021120/apps/ocsp.c ./apps/ocsp.c
 --- /tmp/openssl-SNAP-20021120/apps/ocsp.c  2002-11-13
17:00:24.0 +0100
 +++ ./apps/ocsp.c   2002-11-22 04:00:56.0 +0100
 @@ -55,6 +55,7 @@
   * Hudson ([EMAIL PROTECTED]).
   *
   */
 +#ifndef OPENSSL_NO_OCSP
 
  #include stdio.h
  #include string.h
 @@ -722,7 +723,12 @@
 }
 else if (host)
 {
 +#ifndef OPENSSL_NO_SOCK
 cbio = BIO_new_connect(host);
 +#else
 +   BIO_printf(bio_err, Error creating connect
BIO - sockets not supported.\n);
 +   goto end;
 +#endif
 if (!cbio)
 {
 BIO_printf(bio_err, Error creating connect
BIO\n);
 @@ -1139,7 +1145,11 @@
 bufbio = BIO_new(BIO_f_buffer());
 if (!bufbio)
 goto err;
 +#ifndef OPENSSL_NO_SOCK
 acbio = BIO_new_accept(port);
 +#else
 +  BIO_printf(bio_err, Error setting up accept BIO - sockets not
supported.\n);
 +#endif
 if (!acbio)
 goto err;
 BIO_set_accept_bios(acbio, bufbio);
 @@ -1226,3 +1236,4 @@
 return 1;
 }
 
 +#endif
 diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
20021120/apps/progs.h ./apps/progs.h
 --- /tmp/openssl-SNAP-20021120/apps/progs.h 2002-08-26
14:00:21.0 +0200
 +++ ./apps/progs.h  2002-11-22 04:01:11.0 +0100
 @@ -100,7 +100,9 @@
  #if !defined(OPENSSL_NO_SOCK)  !(defined(OPENSSL_NO_SSL2) 
defined(OPENSSL_NO_SSL3))
 {FUNC_TYPE_GENERAL,s_client,s_client_main},
  #endif
 +#ifndef OPENSSL_NO_SPEED
 {FUNC_TYPE_GENERAL,speed,speed_main},
 +#endif
  #if !defined(OPENSSL_NO_SOCK)  !(defined(OPENSSL_NO_SSL2) 
defined(OPENSSL_NO_SSL3))
 {FUNC_TYPE_GENERAL,s_time,s_time_main},
  #endif
 @@ -120,7 +122,9 @@
 {FUNC_TYPE_GENERAL,smime,smime_main},
 {FUNC_TYPE_GENERAL,rand,rand_main},
 {FUNC_TYPE_GENERAL,engine,engine_main},
 +#ifndef OPENSSL_NO_OCSP
 {FUNC_TYPE_GENERAL,ocsp,ocsp_main},
 +#endif
  #ifndef OPENSSL_NO_MD2
 {FUNC_TYPE_MD,md2,dgst_main},
  #endif
 diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
20021120/apps/speed.c ./apps/speed.c
 --- /tmp/openssl-SNAP-20021120/apps/speed.c 2002-11-19
01:00:57.0 +0100
 +++ ./apps/speed.c  2002-11-21 23:33:02.0 +0100
 @@ -71,6 +71,8 @@
 
  /* most of this code has been pilfered from my libdes speed.c 
program
*/
 
 +#ifndef OPENSSL_NO_SPEED
 +
  #undef SECONDS
  #define SECONDS3
  #define RSA_SECONDS10
 @@ -2569,3 +2571,4 @@
 return 1;
 }
  #endif
 +#endif
 diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
20021120/crypto/x509v3/ext_dat.h ./crypto/x509v3/ext_dat.h
 --- /tmp/openssl-SNAP-20021120/crypto/x509v3/ext_dat.h  2002-06-13
15:00:47.0 +0200
 +++ ./crypto/x509v3/ext_dat.h   2002-11-22 09:33:10.0 +0100
 @@ -90,17 +90,23 @@
  v3_crld,
  v3_ext_ku,
  v3_crl_reason,
 +#ifndef OPENSSL_NO_OCSP
  v3_crl_invdate,
 +#endif
  v3_sxnet,
  v3_info,
 +#ifndef OPENSSL_NO_OCSP
  v3_ocsp_nonce,
  v3_ocsp_crlid,
  v3_ocsp_accresp,
  v3_ocsp_nocheck,
  v3_ocsp_acutoff,
  v3_ocsp_serviceloc,
 +#endif
  v3_sinfo,
 +#ifndef OPENSSL_NO_OCSP
  v3_crl_hold
 +#endif
  };
 
  /* Number of standard extensions */
 diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
20021120/crypto/x509v3/v3_ocsp.c ./crypto/x509v3/v3_ocsp.c
 --- /tmp/openssl-SNAP-20021120/crypto/x509v3/v3_ocsp.c  2001-02-23
05:01:03.0 +0100
 +++ ./crypto/x509v3/v3_ocsp.c   2002-11-22 09:33:03.0 +0100
 @@ -56,6 +56,8 @@
   *
   */
 
 +#ifndef OPENSSL_NO_OCSP
 +
  #include stdio.h
  #include cryptlib.h
  #include openssl/conf.h
 @@ -270,3 +272,4 @@
  err:
 return 0;
 }
 +#endif
 diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
20021120/ssl/bio_ssl.c ./ssl/bio_ssl.c
 --- /tmp/openssl-SNAP-20021120/ssl/bio_ssl.c2002-01-12
17:00:41.0 +0100
 +++ ./ssl/bio_ssl.c 2002-11-21 23:06:11.0 +0100
 @@ -526,6 +526,7 @@
 
  BIO *BIO_new_ssl_connect(SSL_CTX *ctx)
 {
 +#ifndef OPENSSL_NO_SOCK
 BIO *ret=NULL,*con=NULL,*ssl=NULL;
 
 if ((con=BIO_new(BIO_s_connect())) == NULL)
 @@ -538,6 +539,7 @@
  err:
 if (con != NULL) BIO_free(con);
 if (ret != NULL) BIO_free(ret);
 +#endif
 return(NULL);
 }
 
 


-- 
Richard Levitte

[openssl.org #349] 0.9.7 b4 kssl patches

2002-11-26 Thread Richard Levitte via RT

Applied.  Thanks.

This ticket is now resolved.

[[EMAIL PROTECTED] - Tue Nov 19 20:25:21 2002]:

 The following minor problems need to be corrected in 0.9.7 b4 
compiled
 against the MIT Kerberos distribution:
 
 diff -cw openssl-0.9.7-beta4\ssl/kssl.h openssl-0.9.7-beta4-
 modified\ssl/kssl.h
 *** openssl-0.9.7-beta4\ssl/kssl.h Tue Nov 12 08:23:26 2002
 --- openssl-0.9.7-beta4-modified\ssl/kssl.h Tue Nov 19 12:12:22 
2002
 ***
 *** 110,122 
   #define KSSL_CLOCKSKEW  300;
   #endif
 
 ! /* Unused
   #define KSSL_ERR_MAX255
   typedef struct kssl_err_st  {
   int  reason;
   char text[KSSL_ERR_MAX+1];
   } KSSL_ERR;
 ! */
 
   /*  Context for passing
   **  (1) Kerberos session key to SSL, and
 --- 110,122 
   #define KSSL_CLOCKSKEW  300;
   #endif
 
 ! /* Unused - really ? */
   #define KSSL_ERR_MAX255
   typedef struct kssl_err_st  {
   int  reason;
   char text[KSSL_ERR_MAX+1];
   } KSSL_ERR;
 !
 
   /*  Context for passing
   **  (1) Kerberos session key to SSL, and
 diff -cw openssl-0.9.7-beta4\ssl/ssl3.h openssl-0.9.7-beta4-
 modified\ssl/ssl3.h
 *** openssl-0.9.7-beta4\ssl/ssl3.h Tue Oct 15 15:31:08 2002
 --- openssl-0.9.7-beta4-modified\ssl/ssl3.h Tue Nov 19 12:14:30 
2002
 ***
 *** 228,233 
 --- 228,234 
   #define SSL3_TXT_KRB5_RC2_40_CBC_SHA
EXP-KRB5-RC2-CBC-SHA
   #define SSL3_TXT_KRB5_RC4_40_SHAEXP-KRB5-RC4-SHA
   #define SSL3_TXT_KRB5_DES_40_CBC_MD5
EXP-KRB5-DES-CBC-MD5
 + #define SSL3_TXT_KRB5_RC2_40_CBC_MD5
EXP-KRB5-RC2-CBC-MD5
   #define SSL3_TXT_KRB5_DES_40_CBC_MD5
EXP-KRB5-DES-CBC-MD5
   #define SSL3_TXT_KRB5_RC4_40_MD5EXP-KRB5-RC4-MD5
 
 diff -cw openssl-0.9.7-beta4\ssl/ssltest.c openssl-0.9.7-beta4-
 modified\ssl/ssltest.c
 *** openssl-0.9.7-beta4\ssl/ssltest.c Fri Nov 15 17:43:46 2002
 --- openssl-0.9.7-beta4-modified\ssl/ssltest.c Tue Nov 19 12:16:36
 2002
 ***
 *** 697,703 
   if(strlen(localhost) == sizeof localhost-1)
   {
   BIO_printf(bio_err,localhost name 
too long\n);
 ! got end;
   }
   kssl_ctx_setstring(c_ssl-kssl_ctx, 
KSSL_SERVER,
   localhost);
 --- 697,703 
   if(strlen(localhost) == sizeof localhost-1)
   {
   BIO_printf(bio_err,localhost name 
too long\n);
 ! goto end;
   }
   kssl_ctx_setstring(c_ssl-kssl_ctx, 
KSSL_SERVER,
   localhost);
 


-- 
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #355] Bug: RSA_PKCS1_PADDING use in rsa/rsa_sign.c

2002-11-26 Thread Nils Larsch via RT

Eric Cronin via RT wrote:
 At one point in time, RSA_PKCS1_PADDING was evidently #defined as '11', 
 the size in bytes of the extra room needed for PKCS1 padding in an RSA 
 block.  In the current CVS version of OpenSSL it is #defined to 1 and 
 is just used as a selector in switch statements.  Except in rsa_sign.c:
 
   if(type == NID_md5_sha1) {
   ...
   i = SSL_SIG_LENGTH;
   } else {
   ...
   i=i2d_X509_SIG(sig,NULL);
   }
   j=RSA_size(rsa);
   if ((i-RSA_PKCS1_PADDING)  j)
   ...
 
 Even if RSA_PKCS1_PADDING is replaced with 11, the logic is still wrong 
 here I believe.  It's if the hash *plus* the pad is greater than the 
 keysize that you run into problems.
 
 If I'm completely missing the point of this check, I'd be interested in 
 what the real reason for it is...  muddling through this stuff makes my 
 brain hurt.

I think it's a bug (but not a very serious one, because
RSA_padding_add_PKCS1_type_1() would detect the error (if
you use the OpenSSL internal signing method)). I think
the correct if-statement should be:

--- /home/nla/openssl-SNAP-20021118/crypto/rsa/rsa_sign.c   Mon Jun 
11 03:01:50 2001
+++ crypto/rsa/rsa_sign.c   Tue Nov 26 11:25:43 2002
@@ -113,7 +113,7 @@
 i=i2d_X509_SIG(sig,NULL);
 }
 j=RSA_size(rsa);
-   if ((i-RSA_PKCS1_PADDING)  j)
+   if ((i + 11)  j)
 {
 RSAerr(RSA_F_RSA_SIGN,RSA_R_DIGEST_TOO_BIG_FOR_RSA_KEY);
 return(0);

because at least 10 padding bytes are prepended (using EMSA-PKCS1-v1_5
padding) and the padded result should have one octet less than the
modulus (see PKCS#1 RSASSA-PKCS1-v1_5 signature generation).

Regards,
Nils

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[PATCH] fix Solaris/x86 GCC build

2002-11-26 Thread Joe Orton
ssltest.c doesn't currently build (from 0.9.7-stable branch) with GCC
2.95.x on Solaris/x86 platforms; failures are like:

gcc -I.. -I../include  -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -O3 -fomit-frame-pointer -m486 -Wall 
-DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DSHA1_ASM -DMD5_ASM -DRMD160_ASM  -c  
ssltest.c
In file included from ../include/openssl/bio.h:65,
 from ssltest.c:128:
/usr/local/lib/gcc-lib/i386-pc-solaris2.6/2.95.3/include/stdarg.h:170: 
conflicting types for `va_list'
/usr/include/stdio.h:90: previous declaration of `va_list'
*** Error code 1

The #define _XOPEN_SOURCE 600 is the culprit, it seems, which is for
Linux systems apparently.  The glibc unistd.h I have defines gethostname
on this conditional:

#if defined __USE_BSD || defined __USE_XOPEN2K

so this seems like a reasonable fix:

--- ssltest.c.orig  Tue Nov 26 10:47:12 2002
+++ ssltest.c   Tue Nov 26 10:46:11 2002
@@ -109,7 +109,7 @@
  *
  */
 
-#define _XOPEN_SOURCE 600  /* Or gethostname won't be declared properly
+#define _BSD_SOURCE 1  /* Or gethostname won't be declared properly
   on Linux and GNU platforms. */
 #define _XOPEN_SOURCE_EXTENDED 1 /* Or gethostname won't be declared properly
   on Compaq platforms (at least with DEC C).


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #355] Bug: RSA_PKCS1_PADDING use in rsa/rsa_sign.c

2002-11-26 Thread Richard Levitte via RT

Your analysis is correct.  Thanks.  I've just committed a change.

This ticket is now resolved.

[[EMAIL PROTECTED] - Fri Nov 22 10:27:03 2002]:

 At one point in time, RSA_PKCS1_PADDING was evidently #defined as
 '11',
 the size in bytes of the extra room needed for PKCS1 padding in an 
RSA
 block.  In the current CVS version of OpenSSL it is #defined to 1 
and
 is just used as a selector in switch statements.  Except in
 rsa_sign.c:
 
   if(type == NID_md5_sha1) {
   ...
   i = SSL_SIG_LENGTH;
   } else {
   ...
   i=i2d_X509_SIG(sig,NULL);
   }
   j=RSA_size(rsa);
   if ((i-RSA_PKCS1_PADDING)  j)
   ...
 
 Even if RSA_PKCS1_PADDING is replaced with 11, the logic is still
 wrong
 here I believe.  It's if the hash *plus* the pad is greater than 
the
 keysize that you run into problems.
 
 If I'm completely missing the point of this check, I'd be 
interested
 in
 what the real reason for it is...  muddling through this stuff 
makes
 my
 brain hurt.
 
 Thanks,
 Eric
 


-- 
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: DES CBC Error in 0.9.7 B4

2002-11-26 Thread Ben Laurie
Chris Brook wrote:

Forget my previous email.  destest is actually only passing 29 bytes I see,
so the predicted ciphertext will of course be wrong if I pass 32 bytes for
encryption.


So what was the correct test entry in the end?

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]



[openssl.org #343] Fw: When scrubbing secrets in memory doesn't work

2002-11-26 Thread Richard Levitte via RT

[levitte - Thu Nov 21 23:09:40 2002]:

 Hmm...  I think I'm gonna call this a showstopper.  It's way too 
late
 tonight to fix it in a panic and do a panic release.  That's just 
not
 the right way.
 
 So, if noone else does it, I'm fixing this problem within the next 
few
 days, and releasing 0.9.6h during next week.  Sorry about that.

Just a short note: I'm on this, using the CRYPTO_cleanse() that 
Geoff Thorpe proposed, plus a few extras that he suggested to me 
privately.

To be committed tomorrow (or perhaps this evening if I can find the 
time).

-- 
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #365] SGc certificates

2002-11-26 Thread Josephine Suganthi via RT

Hi Lutz,

  How can I get one SGC certificate for my testing? Using 
Openssl can I create one or do you aware of any other tools?


Please help me in this.


Thanks
Josephine


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



RE: DES CBC Error in 0.9.7 B4

2002-11-26 Thread Chris Brook
I set the plaintext and ciphertext strings to 32 characters as below and
test_evp is now OK, encrypt/decrypt.
Chris Brook

// DES CBC tests (from destest)
DES-CBC:0123456789abcdef:fedcba9876543210:37363534333231204E6F7720697320746
8652074696D6520666F72200031:ccd173ffab2039f4acd8aefddfd8a1eb468e91157888
ba68b706462c7a95ca8d,



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ben Laurie
Sent: Tuesday, November 26, 2002 8:40 AM
To: [EMAIL PROTECTED]
Subject: Re: DES CBC Error in 0.9.7 B4


Chris Brook wrote:
 Forget my previous email.  destest is actually only passing 29 bytes I
see,
 so the predicted ciphertext will of course be wrong if I pass 32 bytes for
 encryption.

So what was the correct test entry in the end?

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]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



RE: [openssl.org #353] 0.9.7 B4 testssl with no-dh fails

2002-11-26 Thread Chris Brook
I played around with the testssl script in the tests directory and the
following change seems to take care of the no-dh issue so that the tests run
to completion.  This is the last section of the script:

###
if ../apps/openssl no-dh; then
  echo skipping anonymous DH tests
else
  echo test tls1 with 1024bit anonymous DH, multiple handshakes
  $ssltest -v -bio_pair -tls1 -cipher ADH -dhe1024dsa -num 10 -f -time
$extra || exit 1
fi

if ../apps/openssl no-rsa; then
  echo skipping RSA tests
else
  echo test tls1 with 1024bit RSA, no DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -no_dhe -num
10 -f -time $extra || exit 1
fi

if ../apps/openssl no-dh; then
  echo skipping 1024bit DHE tests
else
  echo test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -dhe1024dsa -num
10 -f -time $extra || exit 1
fi
##

Chris Brook


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Chris Brook via RT
Sent: Wednesday, November 20, 2002 3:36 PM
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #353] 0.9.7 B4 testssl with no-dh fails



I have compiled OpenSSL 0.9.7 Beta 4 with the NO-DH option.  The compilation
is fine but ssltest fails when trying to run the -dhe1024* tests.  A fix
was added in Beta 3 to handle the -dhe1024  -dhe1024dsa parameters when
NO-DH was used but ssltest still tries to run and fails with:

ERROR in CLIENT
22172:error:140830B5:SSL routines:SSL3_CLIENT_HELLO:no ciphers
available:s3_clnt.c:569:

It would seem that the DH tests should be skipped altogether if the NO-DH
option is used, rather than trying to run and failing.  The result is that
make test does not complete.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



RE: OpenSSL and compression using ZLIB

2002-11-26 Thread Le Saux, Eric
Again I want to clarify this point: the issue is in the way ZLIB is used by
OpenSSL, not in ZLIB itself.  The compressor's state is built and destroyed
on every record because OpenSSL uses ZLIB's compress() call, which in turn
calls the lower-level deflateInit(), deflate() and deflateEnd() functions.

This ensures that the records are compression-independent from one another,
and the initial question that started this thread was about the existence of
any requirement in the definition of SSL that required such independence.

Most people discussing this point here do not believe there is such a
requirement, but I am not sure if we have a definitive opinion on this.
Some standards body will have to address that.

One thing is sure though: for specific applications where client and server
are under the control of the same developers, it does make sense to use ZLIB
differently when it is definitely known that the underlying protocol is
indeed reliable.  That is why I am currently testing a very small addition
to OpenSSL's compression methods that I called streamzlib (I am considering
another name suggested yesterday on this mailing list).  Some preliminary
tests with ZLIB showed that I can go from 2:1 compression factor to 6:1.  

For completeness I must also say that for specific applications, compression
can be done just before and outside of the OpenSSL library.  My personal
decision to push it down there is to avoid adding another encapsulation
layer in that part of our code that is written in C.

Now when compression within SSL matures, it will be necessary to have more
control over the compressor's operation than just turning it on.  In ZLIB
you have the choice of 10 compression levels which trade-off between
compression quality and speed of execution.  There are other options that
you could set, such as the size of the dictionary that you use.  Future
compression methods supported by SSL will probably have their own different
set of options.

All this will be an excellent subject of discussion in some SSL standard
committee.

Cheers,

Eric Le Saux
Electronic Arts

-Original Message-
From: Howard Chu [mailto:[EMAIL PROTECTED]] 
Sent: Monday, November 25, 2002 9:01 PM
To: [EMAIL PROTECTED]
Subject: RE: OpenSSL and compression using ZLIB

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Le Saux, Eric

 In the current implementation of OpenSSL,
 compression/decompression state is
 initialized and destroyed per record.  It cannot possibly
 interoperate with
 a compressor that maintains compression state across records.  The
 decompressor does care, unfortunately.

This is surprising. I haven't looked at the code recently, but my experience
has been that a special bit sequence is emitted to signal a dictionary
flush.
I haven't tested it either, so if you say it didn't work I believe you. But
plain old LZW definitely does not have this problem, the compressor can do
whatever it wants, and the decompressor will stay sync'd up because it
detects these reset codes.

  -- Howard Chu
  Chief Architect, Symas Corp.   Director, Highland Sun
  http://www.symas.com   http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



RE: [openssl.org #353] 0.9.7 B4 testssl with no-dh fails

2002-11-26 Thread Chris Brook via RT

I played around with the testssl script in the tests directory and the
following change seems to take care of the no-dh issue so that the tests run
to completion.  This is the last section of the script:

###
if ../apps/openssl no-dh; then
  echo skipping anonymous DH tests
else
  echo test tls1 with 1024bit anonymous DH, multiple handshakes
  $ssltest -v -bio_pair -tls1 -cipher ADH -dhe1024dsa -num 10 -f -time
$extra || exit 1
fi

if ../apps/openssl no-rsa; then
  echo skipping RSA tests
else
  echo test tls1 with 1024bit RSA, no DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -no_dhe -num
10 -f -time $extra || exit 1
fi

if ../apps/openssl no-dh; then
  echo skipping 1024bit DHE tests
else
  echo test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -dhe1024dsa -num
10 -f -time $extra || exit 1
fi
##

Chris Brook


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Chris Brook via RT
Sent: Wednesday, November 20, 2002 3:36 PM
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #353] 0.9.7 B4 testssl with no-dh fails



I have compiled OpenSSL 0.9.7 Beta 4 with the NO-DH option.  The compilation
is fine but ssltest fails when trying to run the -dhe1024* tests.  A fix
was added in Beta 3 to handle the -dhe1024  -dhe1024dsa parameters when
NO-DH was used but ssltest still tries to run and fails with:

ERROR in CLIENT
22172:error:140830B5:SSL routines:SSL3_CLIENT_HELLO:no ciphers
available:s3_clnt.c:569:

It would seem that the DH tests should be skipped altogether if the NO-DH
option is used, rather than trying to run and failing.  The result is that
make test does not complete.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: OpenSSL and compression using ZLIB

2002-11-26 Thread Geoff Thorpe
Salut Eric,

Thanks for describing what you're up to and thanks (in advance) for 
contributing your implementation(s). OpenSSL is used for a lot more than 
building free webservers, despite misconceptions to the contrary, and 
having an reasonably-optimal zlib compression layer right there in the 
SSL/TLS implementation will be useful to many people (and for some, as an 
unexpected and no-hassle bonus to their apps).

On November 26, 2002 01:24 pm, Le Saux, Eric wrote:
 All this will be an excellent subject of discussion in some SSL
 standard committee.

Standards ... ah yes, where the customer is always wrong. I dare suggest 
that the best way forward in that respect is to get a widely used SSL/TLS 
implementation supporting compression in a sensible and tried-and-tested 
manner, let it become a de-facto standard, then let standards authors 
grumble over who'll get to backfit some RFC to it. At least that way 
around, the dog wags the tail I suppose ... :-)

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #358] patch for openssl-SNAP-20021120. Attempt to improve configurability.

2002-11-26 Thread enrique
Hi,

I am working on trying to build the libraries (libcrypto and libssl) to
run on an embedded system with limited storage. To give you an idea, i have
approximately 1.5 megabytes of diskspace in the system. I need to reduce the
footprint of the libraries as much as possible.  

We dont plan to use OCSP in our system. This is the reason we want to turn
it off and save space. Although the gain (in this specific case) is small
regarding to footprint the idea of having a configurable library is in my
opinion good. 

apps/openssl is used by some of the test scripts in the test directory. I
need to be able to run the tests to verify that I have a working library.
This is why patches for the apps/ are provided to.

BTW, if you have any suggestions, it may be config options, stuff in the
TODO lists or anything that may help reduce the footprint of the library 
please let me know.

Thank you,
Enrique


On Tue, Nov 26, 2002 at 10:39:33AM +0100, Richard Levitte via RT wrote:
 
 I can understand wanting to disable the use of sockets.  I can't 
 understand why OCSP or speed should be disabled, however.  Please 
 explain.
 
 [[EMAIL PROTECTED] - Sat Nov 23 19:46:14 2002]:
 
  Hi,
  
  This patch makes it possible to build apps/openssl without the 
 speed
  and ocsp programs and without sockets.
  
  to disable apps/speed.c (openssl speed) just Configure with 
 no-speed.
  
  Thank you,
  Enrique
  
  diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
 20021120/apps/ocsp.c ./apps/ocsp.c
  --- /tmp/openssl-SNAP-20021120/apps/ocsp.c  2002-11-13
 17:00:24.0 +0100
  +++ ./apps/ocsp.c   2002-11-22 04:00:56.0 +0100
  @@ -55,6 +55,7 @@
* Hudson ([EMAIL PROTECTED]).
*
*/
  +#ifndef OPENSSL_NO_OCSP
  
   #include stdio.h
   #include string.h
  @@ -722,7 +723,12 @@
  }
  else if (host)
  {
  +#ifndef OPENSSL_NO_SOCK
  cbio = BIO_new_connect(host);
  +#else
  +   BIO_printf(bio_err, Error creating connect
 BIO - sockets not supported.\n);
  +   goto end;
  +#endif
  if (!cbio)
  {
  BIO_printf(bio_err, Error creating connect
 BIO\n);
  @@ -1139,7 +1145,11 @@
  bufbio = BIO_new(BIO_f_buffer());
  if (!bufbio)
  goto err;
  +#ifndef OPENSSL_NO_SOCK
  acbio = BIO_new_accept(port);
  +#else
  +  BIO_printf(bio_err, Error setting up accept BIO - sockets not
 supported.\n);
  +#endif
  if (!acbio)
  goto err;
  BIO_set_accept_bios(acbio, bufbio);
  @@ -1226,3 +1236,4 @@
  return 1;
  }
  
  +#endif
  diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
 20021120/apps/progs.h ./apps/progs.h
  --- /tmp/openssl-SNAP-20021120/apps/progs.h 2002-08-26
 14:00:21.0 +0200
  +++ ./apps/progs.h  2002-11-22 04:01:11.0 +0100
  @@ -100,7 +100,9 @@
   #if !defined(OPENSSL_NO_SOCK)  !(defined(OPENSSL_NO_SSL2) 
 defined(OPENSSL_NO_SSL3))
  {FUNC_TYPE_GENERAL,s_client,s_client_main},
   #endif
  +#ifndef OPENSSL_NO_SPEED
  {FUNC_TYPE_GENERAL,speed,speed_main},
  +#endif
   #if !defined(OPENSSL_NO_SOCK)  !(defined(OPENSSL_NO_SSL2) 
 defined(OPENSSL_NO_SSL3))
  {FUNC_TYPE_GENERAL,s_time,s_time_main},
   #endif
  @@ -120,7 +122,9 @@
  {FUNC_TYPE_GENERAL,smime,smime_main},
  {FUNC_TYPE_GENERAL,rand,rand_main},
  {FUNC_TYPE_GENERAL,engine,engine_main},
  +#ifndef OPENSSL_NO_OCSP
  {FUNC_TYPE_GENERAL,ocsp,ocsp_main},
  +#endif
   #ifndef OPENSSL_NO_MD2
  {FUNC_TYPE_MD,md2,dgst_main},
   #endif
  diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
 20021120/apps/speed.c ./apps/speed.c
  --- /tmp/openssl-SNAP-20021120/apps/speed.c 2002-11-19
 01:00:57.0 +0100
  +++ ./apps/speed.c  2002-11-21 23:33:02.0 +0100
  @@ -71,6 +71,8 @@
  
   /* most of this code has been pilfered from my libdes speed.c 
 program
 */
  
  +#ifndef OPENSSL_NO_SPEED
  +
   #undef SECONDS
   #define SECONDS3
   #define RSA_SECONDS10
  @@ -2569,3 +2571,4 @@
  return 1;
  }
   #endif
  +#endif
  diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
 20021120/crypto/x509v3/ext_dat.h ./crypto/x509v3/ext_dat.h
  --- /tmp/openssl-SNAP-20021120/crypto/x509v3/ext_dat.h  2002-06-13
 15:00:47.0 +0200
  +++ ./crypto/x509v3/ext_dat.h   2002-11-22 09:33:10.0 +0100
  @@ -90,17 +90,23 @@
   v3_crld,
   v3_ext_ku,
   v3_crl_reason,
  +#ifndef OPENSSL_NO_OCSP
   v3_crl_invdate,
  +#endif
   v3_sxnet,
   v3_info,
  +#ifndef OPENSSL_NO_OCSP
   v3_ocsp_nonce,
   v3_ocsp_crlid,
   v3_ocsp_accresp,
   v3_ocsp_nocheck,
   v3_ocsp_acutoff,
   v3_ocsp_serviceloc,
  +#endif
   v3_sinfo,
  +#ifndef OPENSSL_NO_OCSP
   v3_crl_hold
  +#endif
   };
  
   /* Number of standard extensions */
  diff 

[openssl.org #358] patch for openssl-SNAP-20021120. Attempt to improve configurability.

2002-11-26 Thread [EMAIL PROTECTED] via RT

Hi,

I am working on trying to build the libraries (libcrypto and libssl) to
run on an embedded system with limited storage. To give you an idea, i have
approximately 1.5 megabytes of diskspace in the system. I need to reduce the
footprint of the libraries as much as possible.  

We dont plan to use OCSP in our system. This is the reason we want to turn
it off and save space. Although the gain (in this specific case) is small
regarding to footprint the idea of having a configurable library is in my
opinion good. 

apps/openssl is used by some of the test scripts in the test directory. I
need to be able to run the tests to verify that I have a working library.
This is why patches for the apps/ are provided to.

BTW, if you have any suggestions, it may be config options, stuff in the
TODO lists or anything that may help reduce the footprint of the library 
please let me know.

Thank you,
Enrique


On Tue, Nov 26, 2002 at 10:39:33AM +0100, Richard Levitte via RT wrote:
 
 I can understand wanting to disable the use of sockets.  I can't 
 understand why OCSP or speed should be disabled, however.  Please 
 explain.
 
 [[EMAIL PROTECTED] - Sat Nov 23 19:46:14 2002]:
 
  Hi,
  
  This patch makes it possible to build apps/openssl without the 
 speed
  and ocsp programs and without sockets.
  
  to disable apps/speed.c (openssl speed) just Configure with 
 no-speed.
  
  Thank you,
  Enrique
  
  diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
 20021120/apps/ocsp.c ./apps/ocsp.c
  --- /tmp/openssl-SNAP-20021120/apps/ocsp.c  2002-11-13
 17:00:24.0 +0100
  +++ ./apps/ocsp.c   2002-11-22 04:00:56.0 +0100
  @@ -55,6 +55,7 @@
* Hudson ([EMAIL PROTECTED]).
*
*/
  +#ifndef OPENSSL_NO_OCSP
  
   #include stdio.h
   #include string.h
  @@ -722,7 +723,12 @@
  }
  else if (host)
  {
  +#ifndef OPENSSL_NO_SOCK
  cbio = BIO_new_connect(host);
  +#else
  +   BIO_printf(bio_err, Error creating connect
 BIO - sockets not supported.\n);
  +   goto end;
  +#endif
  if (!cbio)
  {
  BIO_printf(bio_err, Error creating connect
 BIO\n);
  @@ -1139,7 +1145,11 @@
  bufbio = BIO_new(BIO_f_buffer());
  if (!bufbio)
  goto err;
  +#ifndef OPENSSL_NO_SOCK
  acbio = BIO_new_accept(port);
  +#else
  +  BIO_printf(bio_err, Error setting up accept BIO - sockets not
 supported.\n);
  +#endif
  if (!acbio)
  goto err;
  BIO_set_accept_bios(acbio, bufbio);
  @@ -1226,3 +1236,4 @@
  return 1;
  }
  
  +#endif
  diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
 20021120/apps/progs.h ./apps/progs.h
  --- /tmp/openssl-SNAP-20021120/apps/progs.h 2002-08-26
 14:00:21.0 +0200
  +++ ./apps/progs.h  2002-11-22 04:01:11.0 +0100
  @@ -100,7 +100,9 @@
   #if !defined(OPENSSL_NO_SOCK)  !(defined(OPENSSL_NO_SSL2) 
 defined(OPENSSL_NO_SSL3))
  {FUNC_TYPE_GENERAL,s_client,s_client_main},
   #endif
  +#ifndef OPENSSL_NO_SPEED
  {FUNC_TYPE_GENERAL,speed,speed_main},
  +#endif
   #if !defined(OPENSSL_NO_SOCK)  !(defined(OPENSSL_NO_SSL2) 
 defined(OPENSSL_NO_SSL3))
  {FUNC_TYPE_GENERAL,s_time,s_time_main},
   #endif
  @@ -120,7 +122,9 @@
  {FUNC_TYPE_GENERAL,smime,smime_main},
  {FUNC_TYPE_GENERAL,rand,rand_main},
  {FUNC_TYPE_GENERAL,engine,engine_main},
  +#ifndef OPENSSL_NO_OCSP
  {FUNC_TYPE_GENERAL,ocsp,ocsp_main},
  +#endif
   #ifndef OPENSSL_NO_MD2
  {FUNC_TYPE_MD,md2,dgst_main},
   #endif
  diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
 20021120/apps/speed.c ./apps/speed.c
  --- /tmp/openssl-SNAP-20021120/apps/speed.c 2002-11-19
 01:00:57.0 +0100
  +++ ./apps/speed.c  2002-11-21 23:33:02.0 +0100
  @@ -71,6 +71,8 @@
  
   /* most of this code has been pilfered from my libdes speed.c 
 program
 */
  
  +#ifndef OPENSSL_NO_SPEED
  +
   #undef SECONDS
   #define SECONDS3
   #define RSA_SECONDS10
  @@ -2569,3 +2571,4 @@
  return 1;
  }
   #endif
  +#endif
  diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
 20021120/crypto/x509v3/ext_dat.h ./crypto/x509v3/ext_dat.h
  --- /tmp/openssl-SNAP-20021120/crypto/x509v3/ext_dat.h  2002-06-13
 15:00:47.0 +0200
  +++ ./crypto/x509v3/ext_dat.h   2002-11-22 09:33:10.0 +0100
  @@ -90,17 +90,23 @@
   v3_crld,
   v3_ext_ku,
   v3_crl_reason,
  +#ifndef OPENSSL_NO_OCSP
   v3_crl_invdate,
  +#endif
   v3_sxnet,
   v3_info,
  +#ifndef OPENSSL_NO_OCSP
   v3_ocsp_nonce,
   v3_ocsp_crlid,
   v3_ocsp_accresp,
   v3_ocsp_nocheck,
   v3_ocsp_acutoff,
   v3_ocsp_serviceloc,
  +#endif
   v3_sinfo,
  +#ifndef OPENSSL_NO_OCSP
   v3_crl_hold
  +#endif
   };
  
   /* Number of standard extensions */
  diff 

Re: OpenSSL and compression using ZLIB

2002-11-26 Thread David Rees
On Tue, Nov 26, 2002 at 02:00:43PM -0500, Geoff Thorpe wrote:
 
 Thanks for describing what you're up to and thanks (in advance) for
 contributing your implementation(s). OpenSSL is used for a lot more
 than building free webservers, despite misconceptions to the contrary,
 and having an reasonably-optimal zlib compression layer right there in
 the SSL/TLS implementation will be useful to many people (and for
 some, as an unexpected and no-hassle bonus to their apps).

I for one would love to see SSL/TLS implementations support a standard
compression standard, especially for the purpose of serving web pages.
At this point in time, there aren't any good options for compressing
encrypted content if you want to use Apache and support a wide array of
clients.  Especially if you want to compress SSL data.

Does anyone know if any browsers out there support at all for zlib
compression under SSL/TLS?

-Dave
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #359] Calling SSL_read and SSL_write with non-emptyerror stack may cause an error

2002-11-26 Thread Arne Ansper


 Adding ERR_clear_errors() into SSL_read() etc seems to be the correct
 approach. It is already handled this way in _accept(), _connect(), but
 not that obvious, because it is found e.g. in ssl3_accept() which is
 called depending on the method selected.

 You will often find ERR_clear_errors() combined with clear_sys_error()
 but obviously not in all occasions.

I just checked. Seems that SSL_CTX_use_certificate_chain_file has a same
problem. Other uses of ERR_peek_error seem to be immune to the old entries
in error stack.

 Unfortunately it is not obvious enough to simply add it without some
 further investigation. I will thus put this issue into the 0.9.7 queue
 and will not consider it for 0.9.6h anymore.

0.9.7 is fine for me.

Arne

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error

2002-11-26 Thread Arne Ansper via RT



 Adding ERR_clear_errors() into SSL_read() etc seems to be the correct
 approach. It is already handled this way in _accept(), _connect(), but
 not that obvious, because it is found e.g. in ssl3_accept() which is
 called depending on the method selected.

 You will often find ERR_clear_errors() combined with clear_sys_error()
 but obviously not in all occasions.

I just checked. Seems that SSL_CTX_use_certificate_chain_file has a same
problem. Other uses of ERR_peek_error seem to be immune to the old entries
in error stack.

 Unfortunately it is not obvious enough to simply add it without some
 further investigation. I will thus put this issue into the 0.9.7 queue
 and will not consider it for 0.9.6h anymore.

0.9.7 is fine for me.

Arne

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #365] SGc certificates

2002-11-26 Thread Richard Levitte via RT

This is not a bug, so I'm killing the ticket.  Please discuss this 
on [EMAIL PROTECTED]

[[EMAIL PROTECTED] - Tue Nov 26 17:34:03 2002]:

 Hi Lutz,
 
   How can I get one SGC certificate for my testing? Using 
 Openssl can I create one or do you aware of any other tools?
 
 
 Please help me in this.
 
 
 Thanks
 Josephine
 
 


-- 
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: 0.9.7-beta4: test_rsa fails on ia64

2002-11-26 Thread Andy Polyakov
 the test 'trsa' in the testsuite fails on ia64:
 
testing rsa conversions
p - d
p - p
d - d
make[1]: *** [test_rsa] Error 1
make[1]: Leaving directory
`/usr/src/packages/BUILD/openssl-0.9.7_beta4/test'
make: *** [tests] Error 2

I managed to reproduce the problem under nue (IA-64 emulator for Linux)
and with gcc 2.96 (the one found in nue-fs-1.2-1). It's a compiler bug:

*** ./crypto/asn1/a_d2i_fp.c.orig   Sun Nov 24 18:14:40 2002
--- ./crypto/asn1/a_d2i_fp.cSun Nov 24 18:15:16 2002
***
*** 149,155 
ASN1_CTX c;
int want=HEADER_SIZE;
int eos=0;
!   int off=0;
int len=0;
  
b=BUF_MEM_new();
--- 149,155 
ASN1_CTX c;
int want=HEADER_SIZE;
int eos=0;
!   size_t off=0;
int len=0;
  
b=BUF_MEM_new();

Does this help gcc 3.2.1? This patch takes me to the next failing test,
test/dsatest to be specific, which surely also caused by another
compiler bug[which I didn't track down yet].

I also tested ecc 5.0.1 (Intel compiler). That one required following
patch:

*** ./crypto/aes/aes_cbc.c.orig Sat Nov 23 00:16:50 2002
--- ./crypto/aes/aes_cbc.c  Sun Nov 24 14:54:31 2002
***
*** 64,70 
 unsigned char *ivec, const int enc) {
  
unsigned long n;
!   unsigned long len = length;
unsigned char tmp[AES_BLOCK_SIZE];
  
assert(in  out  key  ivec);
--- 64,70 
 unsigned char *ivec, const int enc) {
  
unsigned long n;
!   long len = length;
unsigned char tmp[AES_BLOCK_SIZE];
  
assert(in  out  key  ivec);
*** ./crypto/bn/bn_lcl.h.orig   Tue Mar 26 00:14:50 2002
--- ./crypto/bn/bn_lcl.hFri Nov 22 21:59:01 2002
***
*** 337,347 
  
  #define LBITS(a)  ((a)BN_MASK2l)
  #define HBITS(a)  (((a)BN_BITS4)BN_MASK2l)
! #define   L2HBITS(a)  ((BN_ULONG)((a)BN_MASK2l)BN_BITS4)
  
  #define LLBITS(a) ((a)BN_MASKl)
  #define LHBITS(a) (((a)BN_BITS2)BN_MASKl)
  #define   LL2HBITS(a) ((BN_ULLONG)((a)BN_MASKl)BN_BITS2)
  
  #define mul64(l,h,bl,bh) \
{ \
--- 337,346 
  
  #define LBITS(a)  ((a)BN_MASK2l)
  #define HBITS(a)  (((a)BN_BITS4)BN_MASK2l)
! #define   L2HBITS(a)  (((a)BN_BITS4)BN_MASK2)
  
  #define LLBITS(a) ((a)BN_MASKl)
  #define LHBITS(a) (((a)BN_BITS2)BN_MASKl)
  
  #define mul64(l,h,bl,bh) \
{ \

Yepp, it's a mess... I've never tested ecc 6.0.1. Unlike 5.0.1, that one
is native IA-64 binary code and therefore are way too slow to run in
simulated environment. Do you have real IA-64 hardware? Preferably
Itanium 2 as the assembler module needs tuning just for it. If answer is
yes, is it possible to arrange an account?

Some general IA-64 ABI notes if anybody cares/is interested. As usual
'I' stands for integer, 'L' for long and 'P' for pointer. If not
explicitely mentioned, size is assumed to be 32 bits. In other words
LP64 means sizeof(int)==4, sizeof(long)==8, sizeof(void*)==8.

Linux supports LP64 ABI only.

HP/UX supports both LP64 and ILP32 ABIs. LP64 is the only one currently
supported/recognized by OpenSSL (on HP/UX/IA-64 that is). If anybody is
interested in ILP32 support, contact [EMAIL PROTECTED] and get
prepared to answer zillions of small questions.

Win64 in turn implements P64 ABI with *run-time* option for P32.
Run-time option for P32 means that compiler itself is basically not
aware of this, i.e. generates the code without regard to this. P32 is
engaged at run-time basically through limiting virtual address space to
2GB. You can choose it by linking with /LARGEADDRESSAWARE:NO or
modifying the existing binary with EDITBIN /LAGEADDRESSAWARE:NO. Idea
with P32 is to provide working environment for legacy apps which freely
cast pointers to integer and vice versa. But note this never applies to
handlers to kernel objects as some earlier post on the list implied. I
mean it's perfectly possible to cast handlers to kernel objects to
integers and vice versa even though they are declared as void * even in
P64! Simply because handlers to kernel objects are not pointers, but
indexes in per-process table. Of course problem is that in such large
and diverse API it's very easy to loose the track which interfaces
return handler to kernel object and which ones - real pointers to
user-land objects.

A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #354] openssl problem on tru64

2002-11-26 Thread Andy Polyakov
 We're making test on DUnix Tru 64 and we had problem with this library:
 make test result:
 
 test BN_sqr
 Square test failed!

 Our op. sys is: OSF1 link.softax.local V5.1 732 alpha
 our compiler is:
 Compaq C V6.3-025 on Compaq Tru64 UNIX V5.1 (Rev. 732)

I failed to reproduce the problem with Compaq C under Alpha Linux. I've
experienced very similar problem with

- Intel ecc for IA-64 which turned to be a compiler bug (try attached
patch);

- ./config has failed on 64-bit platform;

Can you post output from 'apps/openssl version -a'?

Cheers. A.
*** ./crypto/bn/bn_lcl.h.orig   Tue Mar 26 00:14:50 2002
--- ./crypto/bn/bn_lcl.hFri Nov 22 21:59:01 2002
***
*** 337,347 
  
  #define LBITS(a)  ((a)BN_MASK2l)
  #define HBITS(a)  (((a)BN_BITS4)BN_MASK2l)
! #define   L2HBITS(a)  ((BN_ULONG)((a)BN_MASK2l)BN_BITS4)
  
  #define LLBITS(a) ((a)BN_MASKl)
  #define LHBITS(a) (((a)BN_BITS2)BN_MASKl)
  #define   LL2HBITS(a) ((BN_ULLONG)((a)BN_MASKl)BN_BITS2)
  
  #define mul64(l,h,bl,bh) \
{ \
--- 337,346 
  
  #define LBITS(a)  ((a)BN_MASK2l)
  #define HBITS(a)  (((a)BN_BITS4)BN_MASK2l)
! #define   L2HBITS(a)  (((a)BN_BITS4)BN_MASK2)
  
  #define LLBITS(a) ((a)BN_MASKl)
  #define LHBITS(a) (((a)BN_BITS2)BN_MASKl)
  
  #define mul64(l,h,bl,bh) \
{ \
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #354] openssl problem on tru64

2002-11-26 Thread Andy Polyakov via RT

 We're making test on DUnix Tru 64 and we had problem with this library:
 make test result:
 
 test BN_sqr
 Square test failed!

 Our op. sys is: OSF1 link.softax.local V5.1 732 alpha
 our compiler is:
 Compaq C V6.3-025 on Compaq Tru64 UNIX V5.1 (Rev. 732)

I failed to reproduce the problem with Compaq C under Alpha Linux. I've
experienced very similar problem with

- Intel ecc for IA-64 which turned to be a compiler bug (try attached
patch);

- ./config has failed on 64-bit platform;

Can you post output from 'apps/openssl version -a'?

Cheers. A.
*** ./crypto/bn/bn_lcl.h.orig   Tue Mar 26 00:14:50 2002
--- ./crypto/bn/bn_lcl.hFri Nov 22 21:59:01 2002
***
*** 337,347 
  
  #define LBITS(a)  ((a)BN_MASK2l)
  #define HBITS(a)  (((a)BN_BITS4)BN_MASK2l)
! #define   L2HBITS(a)  ((BN_ULONG)((a)BN_MASK2l)BN_BITS4)
  
  #define LLBITS(a) ((a)BN_MASKl)
  #define LHBITS(a) (((a)BN_BITS2)BN_MASKl)
  #define   LL2HBITS(a) ((BN_ULLONG)((a)BN_MASKl)BN_BITS2)
  
  #define mul64(l,h,bl,bh) \
{ \
--- 337,346 
  
  #define LBITS(a)  ((a)BN_MASK2l)
  #define HBITS(a)  (((a)BN_BITS4)BN_MASK2l)
! #define   L2HBITS(a)  (((a)BN_BITS4)BN_MASK2)
  
  #define LLBITS(a) ((a)BN_MASKl)
  #define LHBITS(a) (((a)BN_BITS2)BN_MASKl)
  
  #define mul64(l,h,bl,bh) \
{ \

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #257] openssl-0.9.7-beta3 on Irix

2002-11-26 Thread Andy Polyakov
 No, I get exactly same error:
 
 NIST curve P-521 -- Generator:
  x =
 
0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
  y =
 
0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650
 verify group order ...ectest.c:525: ABORT
 make[1]: *** [test_ec] Error 1
 make[1]: Leaving directory 
`/software/scratch/openssl-0.9.7-stable-SNAP-20021116/test'

I can't reprodice this. I've tried MIPSpro cc versions 7.3.1.2m and
7.2.1.3m, all three ABIs (O32, N32, 64)... What's your compiler version?
Run cc -version. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #257] openssl-0.9.7-beta3 on Irix

2002-11-26 Thread Martin MOKREJ© via RT

On Wed, 27 Nov 2002, Andy Polyakov wrote:

  No, I get exactly same error:
 
  NIST curve P-521 -- Generator:
   x =
  
0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
   y =
  
0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650
  verify group order ...ectest.c:525: ABORT
  make[1]: *** [test_ec] Error 1
  make[1]: Leaving directory 
`/software/scratch/openssl-0.9.7-stable-SNAP-20021116/test'

 I can't reprodice this. I've tried MIPSpro cc versions 7.3.1.2m and
 7.2.1.3m, all three ABIs (O32, N32, 64)... What's your compiler version?
 Run cc -version. A.

Hi,

I have

MIPSpro Compilers: Version 7.3.1.3m

CC=cc
CFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include
-I/usr/local/include/ncurses -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses -I/usr/local/BerkeleyDB.4.0/include
-I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2
-I/software/@sys/usr/include/libxml2 -I/software/@sys/usr/include/libwmf'
CPPFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include
-I/usr/local/include/ncurses -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses -I/usr/local/BerkeleyDB.4.0/include
-I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2
-I/software/@sys/usr/include/libxml2 -I/software/@sys/usr/include/libwmf'
CXX=CC
CXXFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include
-I/software/@sys/usr/include -I/usr/local/include/ncurses
-I/usr/local/BerkeleyDB.4.0/include -I/software/@sys/usr/include/ncurses
-I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2
-I/software/@sys/usr/include/libxml2 -I/software/@sys/usr/include/libwmf'
LD_LIBRARY_PATH=/usr/local/BerkeleyDB.4.0/lib:/usr/local/lib32:/usr/lib32:/usr/lib32/internal:/lib32:/opt/lib32:/usr/local/lib:/usr/athena/lib:/var/arch/lib32:/usr/gfx/arch/IP22NG1:/software/msi/972/irix5r3/biosymso:/usr/local/BerkeleyDB.3.3/lib:/usr/local/BerkeleyDB.2.7/lib:/software/@sys/usr/lib32
LIBS='-L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/BerkeleyDB.4.0/lib -L/usr/local/openssl/lib'



-- 
Martin Mokrejs [EMAIL PROTECTED], [EMAIL PROTECTED]
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics http://mips.gsf.de
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: 0.9.7-beta4: test_rsa fails on ia64

2002-11-26 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Wed, 27 Nov 2002 00:14:42 +0100, Andy 
Polyakov [EMAIL PROTECTED] said:

appro I managed to reproduce the problem under nue (IA-64 emulator for Linux)
appro and with gcc 2.96 (the one found in nue-fs-1.2-1). It's a compiler bug:
appro 
appro *** ./crypto/asn1/a_d2i_fp.c.origSun Nov 24 18:14:40 2002
appro --- ./crypto/asn1/a_d2i_fp.c Sun Nov 24 18:15:16 2002
appro ***
appro *** 149,155 
appro  ASN1_CTX c;
appro  int want=HEADER_SIZE;
appro  int eos=0;
appro !int off=0;
appro  int len=0;
appro   
appro  b=BUF_MEM_new();
appro --- 149,155 
appro  ASN1_CTX c;
appro  int want=HEADER_SIZE;
appro  int eos=0;
appro !size_t off=0;
appro  int len=0;
appro   
appro  b=BUF_MEM_new();

Uhmm, I'm sorry, exactly what kind of difference does that make?
Since it's otherwise used with ints (len and i, mostly), and size_t
usually is unsigned, that becomes quite a mix of unsigned vs. signed.

appro *** ./crypto/aes/aes_cbc.c.orig  Sat Nov 23 00:16:50 2002
appro --- ./crypto/aes/aes_cbc.c   Sun Nov 24 14:54:31 2002
appro ***
appro *** 64,70 
appro   unsigned char *ivec, const int enc) {
appro   
appro  unsigned long n;
appro !unsigned long len = length;
appro  unsigned char tmp[AES_BLOCK_SIZE];
appro   
appro  assert(in  out  key  ivec);
appro --- 64,70 
appro   unsigned char *ivec, const int enc) {
appro   
appro  unsigned long n;
appro !long len = length;
appro  unsigned char tmp[AES_BLOCK_SIZE];
appro   
appro  assert(in  out  key  ivec);

Same problem.

I'll have to analyse the rest tomorrow.

In any case, if those are caused by compiler bugs, I'd say that the
compiler in question is automagically rejected and needs to be fixed.
I can't see that there's any excuse to change OpenSSL's code because
the compiler is buggy...

And yes, you're right, there are other problems, especially in Windows
64bit, where all ints and longs are 32 bit wide, except for size_t
which is 64 bits...

-- 
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: [PATCH] supporting the x86_64 architecture

2002-11-26 Thread Andy Polyakov
 to facilitate building openssl on the x86_64 platform I suggest to apply
 the attached patch.

 +linux-x86_64, gcc:-DL_ENDIAN -DNO_ASM:

Linux/x86_64 suports two ABIs. As far as I understand it's perfectly
possible to compile gcc so that it supports both. Which one will be
default? To ensure that intended ABI is chosen I'd recommend to add -m64
to command line.

Why don't you use -O? I had no problem with -O3 and gcc-3.2...

As for NO_ASM. Do you have real x86_64 hardware? I have been working on
BN assembler aided implementation that would need some benchmarking. It
should give around 3x speed-up... If you have real hardware is it
possible to get an account?

A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #257] openssl-0.9.7-beta3 on Irix

2002-11-26 Thread Martin MOKREJ
On Wed, 27 Nov 2002, Andy Polyakov wrote:

  No, I get exactly same error:
 
  NIST curve P-521 -- Generator:
   x =
  
0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
   y =
  
0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650
  verify group order ...ectest.c:525: ABORT
  make[1]: *** [test_ec] Error 1
  make[1]: Leaving directory 
`/software/scratch/openssl-0.9.7-stable-SNAP-20021116/test'

 I can't reprodice this. I've tried MIPSpro cc versions 7.3.1.2m and
 7.2.1.3m, all three ABIs (O32, N32, 64)... What's your compiler version?
 Run cc -version. A.

Hi,

I have

MIPSpro Compilers: Version 7.3.1.3m

CC=cc
CFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include
-I/usr/local/include/ncurses -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses -I/usr/local/BerkeleyDB.4.0/include
-I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2
-I/software/@sys/usr/include/libxml2 -I/software/@sys/usr/include/libwmf'
CPPFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include
-I/usr/local/include/ncurses -I/software/@sys/usr/include
-I/software/@sys/usr/include/ncurses -I/usr/local/BerkeleyDB.4.0/include
-I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2
-I/software/@sys/usr/include/libxml2 -I/software/@sys/usr/include/libwmf'
CXX=CC
CXXFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include
-I/software/@sys/usr/include -I/usr/local/include/ncurses
-I/usr/local/BerkeleyDB.4.0/include -I/software/@sys/usr/include/ncurses
-I/usr/local/openssl/include -I/software/@sys/usr/include/freetype2
-I/software/@sys/usr/include/libxml2 -I/software/@sys/usr/include/libwmf'
LD_LIBRARY_PATH=/usr/local/BerkeleyDB.4.0/lib:/usr/local/lib32:/usr/lib32:/usr/lib32/internal:/lib32:/opt/lib32:/usr/local/lib:/usr/athena/lib:/var/arch/lib32:/usr/gfx/arch/IP22NG1:/software/msi/972/irix5r3/biosymso:/usr/local/BerkeleyDB.3.3/lib:/usr/local/BerkeleyDB.2.7/lib:/software/@sys/usr/lib32
LIBS='-L/usr/local/lib -L/software/@sys/usr/lib
-L/usr/local/BerkeleyDB.4.0/lib -L/usr/local/openssl/lib'



-- 
Martin Mokrejs [EMAIL PROTECTED], [EMAIL PROTECTED]
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics http://mips.gsf.de
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax:+49-89-3187 3585
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]