Re: Release of OpenSSL 1.0.1 approaching...
hi, since a few days the current snapshots seem to provoke a tar: A lone zero block at has there been any change in producing the tar.gz? /P __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2639] When running pkits-test.pl on 1.0.0e or trunk, three tests fail
There appear to be problems with the test data in these three cases. I've reported this and hope to see it resolved soon. In OpenSSL HEAD and 1.0.1 by uncommenting out a line in the perl script (to use and older date for validation) you can still run the older tests: they all pass. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2639] When running pkits-test.pl on 1.0.0e or trunk, three tests fail
[steve - Sun Dec 11 17:25:42 2011]: There appear to be problems with the test data in these three cases. I've reported this and hope to see it resolved soon. In OpenSSL HEAD and 1.0.1 by uncommenting out a line in the perl script (to use and older date for validation) you can still run the older tests: they all pass. Scrub that last bit. I've made the script now auto detect the older data. This only works for OpenSSL 1.0.1 and HEAD though as the necessary functionality isn't in 1.0.0 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1794] [PATCH] SRP in OpenSSL 0.9.9
Enclosed two patches for head and stable to remove unnecessary code
for srp and to add some comments to s_client.
- the callback to provide a user during client connect is
no longer necessary since rfc 5054 a connection attempt
with an srp cipher and no user is terminated when the
cipher is acceptable
- comments to indicate in s_client the (non-)usefulness of
th primalaty tests for non known group parameters.
diff -r -c5 openssl-1.0.1-stable-SNAP-20111211/apps/s_client.c openssl-1.0.1-stable-SNAP-20111211PS/apps/s_client.c
*** openssl-1.0.1-stable-SNAP-20111211/apps/s_client.c 2011-11-16 01:00:33.0 +0100
--- openssl-1.0.1-stable-SNAP-20111211PS/apps/s_client.c 2011-12-11 12:58:54.528530406 +0100
***
*** 401,411
int strength /* minimal size for N */ ;
} SRP_ARG;
#define SRP_NUMBER_ITERATIONS_FOR_PRIME 64
! static int SRP_Verify_N_and_g(BIGNUM *N, BIGNUM *g)
{
BN_CTX *bn_ctx = BN_CTX_new();
BIGNUM *p = BN_new();
BIGNUM *r = BN_new();
int ret =
--- 401,411
int strength /* minimal size for N */ ;
} SRP_ARG;
#define SRP_NUMBER_ITERATIONS_FOR_PRIME 64
! static int srp_Verify_N_and_g(BIGNUM *N, BIGNUM *g)
{
BN_CTX *bn_ctx = BN_CTX_new();
BIGNUM *p = BN_new();
BIGNUM *r = BN_new();
int ret =
***
*** 429,438
--- 429,453
if(bn_ctx)
BN_CTX_free(bn_ctx);
return ret;
}
+ /* This callback is used here for two purposes:
+- extended debugging
+- making some primality tests for unknown groups
+The callback is only called for a non default group.
+
+An application does not need the call back at all if
+only the stanard groups are used. In real life situations,
+client and server already share well known groups,
+thus there is no need to verify them.
+Furthermore, in case that a server actually proposes a group that
+is not one of those defined in RFC 5054, it is more appropriate
+to add the group to a static list and then compare since
+primality tests are rather cpu consuming.
+ */
+
static int MS_CALLBACK ssl_srp_verify_param_cb(SSL *s, void *arg)
{
SRP_ARG *srp_arg = (SRP_ARG *)arg;
BIGNUM *N = NULL, *g = NULL;
if (!(N = SSL_get_srp_N(s)) || !(g = SSL_get_srp_g(s)))
***
*** 451,465
if (srp_arg-amp == 1)
{
if (srp_arg-debug)
BIO_printf(bio_err, SRP param N and g are not known params, going to check deeper.\n);
! /* The srp_moregroups must be used with caution, testing primes costs time.
Implementors should rather add the value to the known ones.
The minimal size has already been tested.
*/
! if (BN_num_bits(g) = BN_BITS SRP_Verify_N_and_g(N,g))
return 1;
}
BIO_printf(bio_err, SRP param N and g rejected.\n);
return 0;
}
--- 466,480
if (srp_arg-amp == 1)
{
if (srp_arg-debug)
BIO_printf(bio_err, SRP param N and g are not known params, going to check deeper.\n);
! /* The srp_moregroups is a real debugging feature.
Implementors should rather add the value to the known ones.
The minimal size has already been tested.
*/
! if (BN_num_bits(g) = BN_BITS srp_Verify_N_and_g(N,g))
return 1;
}
BIO_printf(bio_err, SRP param N and g rejected.\n);
return 0;
}
***
*** 484,499
*(pass+l)= '\0';
return pass;
}
- static char * MS_CALLBACK missing_srp_username_callback(SSL *s, void *arg)
- {
- SRP_ARG *srp_arg = (SRP_ARG *)arg;
- return BUF_strdup(srp_arg-srplogin);
- }
-
#endif
char *srtp_profiles = NULL;
# ifndef OPENSSL_NO_NEXTPROTONEG
/* This the context that we pass to next_proto_cb */
--- 499,508
***
*** 1180,1192
SSL_CTX_set_tlsext_servername_arg(ctx, tlsextcbp);
}
#ifndef OPENSSL_NO_SRP
if (srp_arg.srplogin)
{
! if (srp_lateuser)
! SSL_CTX_set_srp_missing_srp_username_callback(ctx,missing_srp_username_callback);
! else if (!SSL_CTX_set_srp_username(ctx, srp_arg.srplogin))
{
BIO_printf(bio_err,Unable to set SRP username\n);
goto end;
}
srp_arg.msg = c_msg;
--- 1189,1199
SSL_CTX_set_tlsext_servername_arg(ctx, tlsextcbp);
}
#ifndef OPENSSL_NO_SRP
if (srp_arg.srplogin)
{
! if (!srp_lateuser !SSL_CTX_set_srp_username(ctx, srp_arg.srplogin))
{
BIO_printf(bio_err,Unable to set SRP username\n);
goto end;
}
srp_arg.msg = c_msg;
Only in openssl-1.0.1-stable-SNAP-20111211PS/apps: s_client.c.orig
Only in openssl-1.0.1-stable-SNAP-20111211PS/apps: s_client.c.rej
diff -r -c5 openssl-1.0.1-stable-SNAP-20111211/crypto/symhacks.h openssl-1.0.1-stable-SNAP-20111211PS/crypto/symhacks.h
*** openssl-1.0.1-stable-SNAP-20111211/crypto/symhacks.h 2011-03-19 13:00:18.0 +0100
--- openssl-1.0.1-stable-SNAP-20111211PS/crypto/symhacks.h 2011-12-11 11:14:08.688822302 +0100
***
*** 190,202
#define
Re: [openssl.org #2650] major ssl read/ write performance improvement - updated
I'm getting more SSL timeouts when running apachebench with this patch enabled, http://www.pastie.org/3002992 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
openssl-1.0.1-stable-SNAP-20111209 compile error on SunOS 5.10
[sent to rt before, but didn't see it back on the list, so here's an abbreviated version] OS: SunOS 5.10 Compiler: SunStudio As requested on the mailing lists I downloaded openssl-1.0.1-stable-SNAP-20111209 and tried to compile it on various OS. It failed on SunOS 5.10 when using Sun's compiler: $ CC=cc ./Configure solaris64-x86_64-cc --prefix=/home/user/SunOS5 $ make ... cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -xarch=amd64 -xstrconst -Xa -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o modexp512-x86_64.o modexp512-x86_64.s Assembler: modexp512-x86_64.s, line 433 : Syntax error modexp512-x86_64.s, line 450 : Syntax error modexp512-x86_64.s, line 475 : Syntax error modexp512-x86_64.s, line 1477 : Syntax error cc: assembler failed for modexp512-x86_64.s Previous versions, e.g., 1.0.0d, compile fine on the same machine using the same options. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2648] Bug report: error in openssl-1.0.0e/crypto/bn/asm/x86-mont.pl
Hello, Please verify http://cvs.openssl.org/chngview?cn=21811. Thanks for report. Thank you, version 1.13 works fine. Out of curiosity. The bug is in legacy integer-only code path, one that isn't normally chosen on contemporary CPUs. How did you run into it? I mean is it very old CPU? Embedded one without SSE2? Or do you consciously omit SSE2 support? You are right, the processor is rather old. Excuse me please,I probably should have mentioned this before. --- Sincerely yours, Victor Timakov 09.12.2011 18:35, Andy Polyakov via RT ?: It looks like a bug inopenssl-1.0.0e x86 (Windows, Linux, etc.): functions BN_mod_mul and BN_mod_mul_mongomery sometimes (very rarely) yield different results when squaring (multiplication at the same time works fine). Compile time options include -DOPENSSL_BN_ASM_MONT, ie the assembler code produced by crypto/bn/asm/x86-mont.pl is used. Please verify http://cvs.openssl.org/chngview?cn=21811. Thanks for report. Out of curiosity. The bug is in legacy integer-only code path, one that isn't normally chosen on contemporary CPUs. How did you run into it? I mean is it very old CPU? Embedded one without SSE2? Or do you consciously omit SSE2 support? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
