Re: Query
On 03/12/14 05:01, Dominyk Tiller wrote: Hey guys, I wanted to query something I saw pop up on the Git earlier: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=961d2ddb4b48e0e857a704b0cc6b475d63372419 Does that change imply that right now, without that commit, building without SSLv2 and SSLv3 would remove SSL/TLS support for a connection entirely? Or am I completely misinterpreting that? It's about 5 in the morning here, so forgive me if I'm being a little slow here, heh. No. This is *only* about the ocsp and s_time command line applications. They were incorrectly handling the scenario where SSLv2 or SSLv3 has been disabled. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Memory Leak when Using Openssl
Hai All, We are using Openssl for DTLS Negotiations. When we run the Valgrind with this setup. We are finding some major loss of memory at one place. ==23871== 4,224 (1,056 direct, 3,168 indirect) bytes in 3 blocks are definitely lost in loss record 1,332 of 1,482 ==23871==at 0x4C26BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23871==by 0x514C7F2: CRYPTO_malloc (in /usr/lib/libcrypto.so.1.0.0) ==23871==by 0x4E711E8: SSL_SESSION_new (in /usr/lib/libssl.so.1.0.0) ==23871==by 0x4E712FC: ssl_get_new_session (in /usr/lib/libssl.so.1.0.0) ==23871==by 0x4E4CCFC: ssl3_get_client_hello (in /usr/lib/libssl.so.1.0.0) ==23871==by 0x4E6444A: dtls1_accept (in /usr/lib/libssl.so.1.0.0) ==23871==by 0x4E688C5: dtls1_read_bytes (in /usr/lib/libssl.so.1.0.0) ==23871==by 0x4E550A9: ssl3_read (in /usr/lib/libssl.so.1.0.0) ==23871==by 0xB0CD1E: dtlsSrtpOpenSSLRead(dtls_srtp_ccb_str*, ssl_st*, unsigned int, sockaddr_str*, sockaddr_str*, bool) (dtlsSrtpOpenssl.c:776) ==23871==by 0xB14FD8: dtlsSrtpProcessRecvPkt(dtls_srtp_pkt_rcv_ind_msg_str*) (dtlsSrtpMsgProc.c:945) ==23871==by 0xB12C41: dtlsSrtpActiveMsgProc(icm_msg_str*) (dtlsSrtpMsgProc.c:284) ==23871==by 0xB12A82: dtlsSrtpActiveMsgProc(icm_msg_str*, IcmMsgBase*) (dtlsSrtpMsgProc.c:231) Can anyone throw some light on it ? Regards Satya
Re: Memory Leak when Using Openssl
On Wed, Dec 03, 2014 at 04:04:16PM +0530, T@Run..! Polisetty wrote: Hai All, We are using Openssl for DTLS Negotiations. When we run the Valgrind with this setup. We are finding some major loss of memory at one place. Can you check with a current git version? There have been fixes related to DTLS. I know of at least commit 2e84084fbcbbf032a0021a73ef56711966b28159. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3616] [Patch] Implement option to disable sending TLS extensions
Actually it does not introduce it as OpenSSL does send the notification as TLS_EMPTY_RENEGOTIATION_INFO_SCSV, not the extension. The skip is also placed in t1_lib.c after the handle for RI (Renegotiation Info), so renegotiation is performed using the secure protocol. And while it would be nice to be able to just bin those broken servers, this could actually be viewed as a regression from 0.9.8 - it was possible to configure it to send no extensions... On Sunday 30 November 2014 20:36:20 Richard Moore wrote: That would introduce security issues such as the TLS renegotiation flaw. Surely a better solution is to make servers that pretend to support TLS but actually only support SSL3 die a horrible death? Rich. On 30 November 2014 at 20:18, Hubert Kario via RT r...@openssl.org wrote: since some TLS1.0 servers are extension intolerant, it is necessary to not advertise any extensions to be able to connect to them. This patch implements command line options as well as SSL_CONF_cmd() options to disable sending TLS extensions completely https://github.com/openssl/openssl/pull/198 -- Regards, Hubert Kario __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3607] nistz256 is broken.
thanks! Was away last week and so didn't have a chance to try fixing this. I'll patch that it and run the tests against it. I've run out of time tracking this down for today, but I got to the point where setting the Jacobian coordinates: X: C4EB2994C09557B400FF6A543CFB257F945E86FE3DF1D32A8128F32927666A8F Y: 3D5283F8F10F559AE5310005005F321B28D2D699F3E01F179F91AC6660013328 Z: F97FD7E6757991A2C7E0C2488FF3C54E58030BCACF3FB95954FD3EF211C24631 and multiplying that point by 2269520AFB46450398DE95AE59DDBDC1D42B8B7030F81BCFEF12D819C1D678DD results in the affine point: x: 4BBC2813F69EF6A4D3E69E2832E9A9E97FF59F8C136DCDBD9509BC685FF337FD y: BDCB623715CE2D983CFC2776C6EED4375454BE2C88932D43856906C1DC7A0BD7 However, I believe that the result should be: x: C2910AA0216D12DE30C5573CCFC4116546E3091DC1E9EC8604F634185CE40863 y: C9071E13D688C305CE179C6168DD9066657BC6CDC1639A44B68DF7F1E0A40EDF I do get the latter... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3607] nistz256 is broken.
thanks! Was away last week and so didn't have a chance to try fixing this. I'll patch that it and run the tests against it. I've run out of time tracking this down for today, but I got to the point where setting the Jacobian coordinates: X: C4EB2994C09557B400FF6A543CFB257F945E86FE3DF1D32A8128F32927666A8F Y: 3D5283F8F10F559AE5310005005F321B28D2D699F3E01F179F91AC6660013328 Z: F97FD7E6757991A2C7E0C2488FF3C54E58030BCACF3FB95954FD3EF211C24631 and multiplying that point by 2269520AFB46450398DE95AE59DDBDC1D42B8B7030F81BCFEF12D819C1D678DD results in the affine point: x: 4BBC2813F69EF6A4D3E69E2832E9A9E97FF59F8C136DCDBD9509BC685FF337FD y: BDCB623715CE2D983CFC2776C6EED4375454BE2C88932D43856906C1DC7A0BD7 However, I believe that the result should be: x: C2910AA0216D12DE30C5573CCFC4116546E3091DC1E9EC8604F634185CE40863 y: C9071E13D688C305CE179C6168DD9066657BC6CDC1639A44B68DF7F1E0A40EDF I do get the latter... ... in master, and I get the former in 1.0.2. Looking into it... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3607] nistz256 is broken.
thanks! Was away last week and so didn't have a chance to try fixing this. I'll patch that it and run the tests against it. I've run out of time tracking this down for today, but I got to the point where setting the Jacobian coordinates: X: C4EB2994C09557B400FF6A543CFB257F945E86FE3DF1D32A8128F32927666A8F Y: 3D5283F8F10F559AE5310005005F321B28D2D699F3E01F179F91AC6660013328 Z: F97FD7E6757991A2C7E0C2488FF3C54E58030BCACF3FB95954FD3EF211C24631 and multiplying that point by 2269520AFB46450398DE95AE59DDBDC1D42B8B7030F81BCFEF12D819C1D678DD results in the affine point: x: 4BBC2813F69EF6A4D3E69E2832E9A9E97FF59F8C136DCDBD9509BC685FF337FD y: BDCB623715CE2D983CFC2776C6EED4375454BE2C88932D43856906C1DC7A0BD7 However, I believe that the result should be: x: C2910AA0216D12DE30C5573CCFC4116546E3091DC1E9EC8604F634185CE40863 y: C9071E13D688C305CE179C6168DD9066657BC6CDC1639A44B68DF7F1E0A40EDF I do get the latter... ... in master, and I get the former in 1.0.2. Looking into it... Attached patch produces correct result in 1.0.2. Looking further for explanation... commit 9ca10dca3ca6bc5ea739a998258351dbfd261b42 Author: Andy Polyakov ap...@openssl.org Date: Sun Oct 26 12:45:47 2014 +0100 Add ARMv4 ECP_NISTZ256 implementation. diff --git a/Configure b/Configure index 2eda5e6..777e8cf 100755 --- a/Configure +++ b/Configure @@ -138,7 +138,7 @@ my $alpha_asm=alphacpuid.o:bn_asm.o alpha-mont.o::sha1-alpha.o:::ghash- my $mips64_asm=:bn-mips.o mips-mont.o:::aes_cbc.o aes-mips.o:::sha1-mips.o sha256-mips.o sha512-mips.o; my $mips32_asm=$mips64_asm; $mips32_asm =~ s/\s*sha512\-mips\.o//; my $s390x_asm=s390xcap.o s390xcpuid.o:bn-s390x.o s390x-mont.o s390x-gf2m.o:::aes-s390x.o aes-ctr.o aes-xts.o:::sha1-s390x.o sha256-s390x.o sha512-s390x.o::rc4-s390x.o:ghash-s390x.o:; -my $armv4_asm=armcap.o armv4cpuid.o:bn_asm.o armv4-mont.o armv4-gf2m.o:::aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o:::sha1-armv4-large.o sha256-armv4.o sha512-armv4.o:::ghash-armv4.o ghashv8-armx.o::void; +my $armv4_asm=armcap.o armv4cpuid.o:bn_asm.o armv4-mont.o armv4-gf2m.o:ecp_nistz256.o ecp_nistz256-armv4.o::aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o:::sha1-armv4-large.o sha256-armv4.o sha512-armv4.o:::ghash-armv4.o ghashv8-armx.o::void; my $aarch64_asm=armcap.o arm64cpuid.o mem_clr.oaes_core.o aes_cbc.o aesv8-armx.o:::sha1-armv8.o sha256-armv8.o sha512-armv8.o:::ghashv8-armx.o:; my $parisc11_asm=pariscid.o:bn_asm.o parisc-mont.o:::aes_core.o aes_cbc.o aes-parisc.o:::sha1-parisc.o sha256-parisc.o sha512-parisc.o::rc4-parisc.o:ghash-parisc.o::32; my $parisc20_asm=pariscid.o:pa-risc2W.o parisc-mont.o:::aes_core.o aes_cbc.o aes-parisc.o:::sha1-parisc.o sha256-parisc.o sha512-parisc.o::rc4-parisc.o:ghash-parisc.o::64; diff --git a/TABLE b/TABLE index d778dac..b1d4543 100644 --- a/TABLE +++ b/TABLE @@ -1132,7 +1132,7 @@ $lflags = -ldl $bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR $cpuid_obj= armcap.o armv4cpuid.o $bn_obj = bn_asm.o armv4-mont.o armv4-gf2m.o -$ec_obj = +$ec_obj = ecp_nistz256.o ecp_nistz256-armv4.o $des_obj = $aes_obj = aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o $bf_obj = @@ -4362,7 +4362,7 @@ $lflags = -ldl $bn_ops = BN_LLONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR $cpuid_obj= armcap.o armv4cpuid.o $bn_obj = bn_asm.o armv4-mont.o armv4-gf2m.o -$ec_obj = +$ec_obj = ecp_nistz256.o ecp_nistz256-armv4.o $des_obj = $aes_obj = aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o $bf_obj = diff --git a/crypto/ec/Makefile b/crypto/ec/Makefile index 898e43d..e020c93 100644 --- a/crypto/ec/Makefile +++ b/crypto/ec/Makefile @@ -54,6 +54,9 @@ ecp_nistz256-x86_64.s: asm/ecp_nistz256-x86_64.pl ecp_nistz256-avx2.s: asm/ecp_nistz256-avx2.pl $(PERL) asm/ecp_nistz256-avx2.pl $(PERLASM_SCHEME) $@ +ecp_nistz256-%.S: asm/ecp_nistz256-%.pl; $(PERL) $ $(PERLASM_SCHEME) $@ +ecp_nistz256-armv4.o: ecp_nistz256-armv4.S + files: $(PERL) $(TOP)/util/files.pl Makefile $(TOP)/MINFO diff --git a/crypto/ec/asm/ecp_nistz256-armv4.pl b/crypto/ec/asm/ecp_nistz256-armv4.pl new file mode 100755 index 000..ad29948 --- /dev/null +++ b/crypto/ec/asm/ecp_nistz256-armv4.pl @@ -0,0 +1,1720 @@ +#!/usr/bin/env perl + +# +# Written by Andy Polyakov ap...@openssl.org for the OpenSSL +# project. The module is, however, dual licensed under OpenSSL and +# CRYPTOGAMS licenses depending on where you obtain it. For further +# details see http://www.openssl.org/~appro/cryptogams/. +# +# +# ECP_NISTZ256 module for ARMv4. +# +# October 2014. +# +# Original ECP_NISTZ256 submission targeting x86_64 is detailed in +# http://eprint.iacr.org/2013/816. In the process of adaptation +# original .c module was made 32-bit savvy in
Re: [openssl.org #3607] nistz256 is broken.
thanks! Was away last week and so didn't have a chance to try fixing this. I'll patch that it and run the tests against it. I've run out of time tracking this down for today, but I got to the point where setting the Jacobian coordinates: X: C4EB2994C09557B400FF6A543CFB257F945E86FE3DF1D32A8128F32927666A8F Y: 3D5283F8F10F559AE5310005005F321B28D2D699F3E01F179F91AC6660013328 Z: F97FD7E6757991A2C7E0C2488FF3C54E58030BCACF3FB95954FD3EF211C24631 and multiplying that point by 2269520AFB46450398DE95AE59DDBDC1D42B8B7030F81BCFEF12D819C1D678DD results in the affine point: x: 4BBC2813F69EF6A4D3E69E2832E9A9E97FF59F8C136DCDBD9509BC685FF337FD y: BDCB623715CE2D983CFC2776C6EED4375454BE2C88932D43856906C1DC7A0BD7 However, I believe that the result should be: x: C2910AA0216D12DE30C5573CCFC4116546E3091DC1E9EC8604F634185CE40863 y: C9071E13D688C305CE179C6168DD9066657BC6CDC1639A44B68DF7F1E0A40EDF I do get the latter... ... in master, and I get the former in 1.0.2. Looking into it... Attached patch produces correct result in 1.0.2. Looking further for explanation... Oops! Wrong patch! Correct one attached. If you feel like testing the wrong one, go ahead, but there are some later non-essential adjustments. diff --git a/crypto/ec/ecp_nistz256.c b/crypto/ec/ecp_nistz256.c index bf3fcc6..33b07ce 100644 --- a/crypto/ec/ecp_nistz256.c +++ b/crypto/ec/ecp_nistz256.c @@ -637,7 +637,7 @@ static void ecp_nistz256_windowed_mul(const EC_GROUP * group, ecp_nistz256_point_double(row[10 - 1], row[ 5 - 1]); ecp_nistz256_point_add (row[15 - 1], row[14 - 1], row[1 - 1]); ecp_nistz256_point_add (row[11 - 1], row[10 - 1], row[1 - 1]); -ecp_nistz256_point_add (row[16 - 1], row[15 - 1], row[1 - 1]); +ecp_nistz256_point_double(row[16 - 1], row[ 8 - 1]); } index = 255;
misapplied/mismerged chunk in 59669b6abf620d1ed2ef4d1e2df25c998b89b64d (master)
... and same in cherry-picked variants in other branches: 05e769f269f28b649d8300a1fc3aaef19901a173 (OpenSSL_1_0_2-stable) 4c21e004a3738b70c7d21d6e86ca68b21577d4d0 (OpenSSL_1_0_1-stable) Appears harmless, though. Look for Just one protocol version: diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c index 09268b8..5b3de08 100644 --- a/ssl/d1_lib.c +++ b/ssl/d1_lib.c ... @@ -312,6 +318,25 @@ long dtls1_ctrl(SSL *s, int cmd, long larg, void *parg) } return 0; /* Unexpected state; fail closed. */ + /* Just one protocol version is supported so far; +* fail closed if the version is not as expected. */ + return s-version == DTLS_MAX_VERSION; + case DTLS_CTRL_SET_LINK_MTU: + if (larg (long)dtls1_link_min_mtu()) + return 0; + s-d1-link_mtu = larg; + return 1; ... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3607] nistz256 is broken.
2. When will RT2574 be integrated to protect our ECC keys in the inevitable presence of software defects like this? http://rt.openssl.org/Ticket/Display.html?id=2574user=guestpass=guest Reportedly, Cryptography Research (i.e., Rambus) alleges to have broad patents on techniques like this (and they might not be the only ones). I'm not going to look for specific patents and can't assess the validity of that rumor, the only thing I know for certain is that Cryptography Research and Rambus are famous, above all else, for starting patent lawsuits (see, e.g., http://www.sec.gov/Archives/edgar/data/1403161/000119312507270394/d10k.htm). Unfortunately, this means that the OpenSSL project may not be willing to incorporate coordinate-blinding techniques at this time. Bodo
[PATCH] Add API to set minimum and maximum protocol version.
This is an initial patch to support being able to set the minimum
and maximum protocol version. The patch is currently untested,
that will happen as I rewrite other things. But I'm looking for
feedback.
Kurt
diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index ab8730c..6a016f0 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -294,12 +294,23 @@ long dtls1_ctrl(SSL *s, int cmd, long larg, void *parg)
break;
case SSL_CTRL_CHECK_PROTO_VERSION:
/* For library-internal use; checks that the current protocol
-* is the highest enabled version (according to s-ctx-method,
-* as version negotiation may have changed s-method). */
+* is the highest enabled version. */
+ if (s-max_proto_version == 0 s-version == DTLS_MAX_VERSION)
+ return 1;
+ if (s-max_proto_version != 0
+s-version == s-max_proto_version)
+ return 1;
+ /* We're not limited by the max_proto_version but might still
+* have other reasons why we use an older version like not using
+* a version-flexible SSL_METHOD. Check s-ctx-method as
+* version negotiation may have changed s-method.
+* This check can be removed when we only have version-flexible
+* SSL_METHODs */
if (s-version == s-ctx-method-version)
return 1;
/* Apparently we're using a version-flexible SSL_METHOD
-* (not at its highest protocol version). */
+* (not at its highest protocol version, not limited by
+* max_proto_version). */
if (s-ctx-method-version == DTLS_method()-version)
{
#if DTLS_MAX_VERSION != DTLS1_2_VERSION
diff --git a/ssl/s23_clnt.c b/ssl/s23_clnt.c
index 42c3d68..9b9ee00 100644
--- a/ssl/s23_clnt.c
+++ b/ssl/s23_clnt.c
@@ -375,6 +375,14 @@ static int ssl23_client_hello(SSL *s)
}
#endif
+ if (s-max_proto_version != 0 SSL_VERSION_GT(version,
s-max_proto_version))
+ version = s-max_proto_version;
+ if (SSL_VERSION_LT(version, s-min_proto_version))
+ {
+ SSLerr(SSL_F_SSL23_CLIENT_HELLO,SSL_R_NO_PROTOCOLS_AVAILABLE);
+ return -1;
+ }
+
buf=(unsigned char *)s-init_buf-data;
if (s-state == SSL23_ST_CW_CLNT_HELLO_A)
{
@@ -760,7 +768,8 @@ static int ssl23_get_server_hello(SSL *s)
/* ensure that TLS_MAX_VERSION is up-to-date */
OPENSSL_assert(s-version = TLS_MAX_VERSION);
- if (!ssl_security(s, SSL_SECOP_VERSION, 0, s-version, NULL))
+ if (SSL_VERSION_LT(s-version, s-min_proto_version) ||
+ !ssl_security(s, SSL_SECOP_VERSION, 0, s-version,
NULL))
{
SSLerr(SSL_F_SSL23_GET_SERVER_HELLO,SSL_R_VERSION_TOO_LOW);
goto err;
diff --git a/ssl/s23_srvr.c b/ssl/s23_srvr.c
index 858420d..4bc16cc 100644
--- a/ssl/s23_srvr.c
+++ b/ssl/s23_srvr.c
@@ -259,6 +259,10 @@ int ssl23_get_client_hello(SSL *s)
int n=0,j;
int type=0;
int v[2];
+ int max_version = TLS_MAX_VERSION;
+
+ if (s-max_proto_version != 0)
+ max_version = s-max_proto_version;
if (s-state == SSL23_ST_SR_CLNT_HELLO_A)
{
@@ -293,25 +297,29 @@ int ssl23_get_client_hello(SSL *s)
if (p[4] = TLS1_VERSION_MINOR)
{
if (p[4] = TLS1_2_VERSION_MINOR
+ max_version = TLS1_2_VERSION
!(s-options SSL_OP_NO_TLSv1_2))
{
s-version=TLS1_2_VERSION;
s-state=SSL23_ST_SR_CLNT_HELLO_B;
}
else if (p[4] = TLS1_1_VERSION_MINOR
+ max_version = TLS1_1_VERSION
!(s-options SSL_OP_NO_TLSv1_1))
{
s-version=TLS1_1_VERSION;
/* type=2; */ /* done later to
survive restarts */
s-state=SSL23_ST_SR_CLNT_HELLO_B;
}
- else if (!(s-options
SSL_OP_NO_TLSv1))
+ else if (!(s-options
SSL_OP_NO_TLSv1)
+ max_version = TLS1_VERSION)
Re: misapplied/mismerged chunk in 59669b6abf620d1ed2ef4d1e2df25c998b89b64d (master)
On 03/12/14 20:36, Yuriy Kaminskiy wrote: ... and same in cherry-picked variants in other branches: 05e769f269f28b649d8300a1fc3aaef19901a173 (OpenSSL_1_0_2-stable) 4c21e004a3738b70c7d21d6e86ca68b21577d4d0 (OpenSSL_1_0_1-stable) Appears harmless, though. Thanks. I'll get this fixed. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3607] nistz256 is broken.
On Wed, Dec 3, 2014 at 10:12 AM, Andy Polyakov via RT r...@openssl.org wrote: Oops! Wrong patch! Correct one attached. If you feel like testing the wrong one, go ahead, but there are some later non-essential adjustments. diff --git a/crypto/ec/ecp_nistz256.c b/crypto/ec/ecp_nistz256.c index bf3fcc6..33b07ce 100644 --- a/crypto/ec/ecp_nistz256.c +++ b/crypto/ec/ecp_nistz256.c @@ -637,7 +637,7 @@ static void ecp_nistz256_windowed_mul(const EC_GROUP * group, ecp_nistz256_point_double(row[10 - 1], row[ 5 - 1]); ecp_nistz256_point_add (row[15 - 1], row[14 - 1], row[1 - 1]); ecp_nistz256_point_add (row[11 - 1], row[10 - 1], row[1 - 1]); -ecp_nistz256_point_add (row[16 - 1], row[15 - 1], row[1 - 1]); +ecp_nistz256_point_double(row[16 - 1], row[ 8 - 1]); } index = 255; I can believe that this fixes the issue, but it's just masking it, no? I'll see if I can track it down more precisely tomorrow. Cheers AGL __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
