[openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
What is the appropriate size for 'buf' in DSA_size()? 4 bytes is certainly not correct. My guess is that we want to support at least 256 bits and so it needs to be at least 32 bytes. Does anyone have a better recommendation? Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #361] Re: OpenSSL and compression using ZLIB
http://www.ietf.org/internet-drafts/draft-ietf-tls-compression-03.txt
defines the compression numbers to be:
enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;
Therefore proposed numbers have been issued. I suggest that OpenSSL
define the CompressionMethod numbers to be:
enum { null(0), ZLIB(1), LZS(2), eayZLIB(224), eayRLE(225), (255) }
CompresssionMethod
as values in the range 193 to 255 are reserved for private use.
Where does the above draft state that the dictionary must be reset?
It states that the engine must be flushed but does not indicate that
the dictionary is to be reset. Resetting the dictionary would turn
ZLIB into a stateless compression algorithm and according to the draft
ZLIB is most certainly a stateful algorithm:
the compressor maintains it's state through all compressed records
I do not believe that compatibility will be an issue. It will simply
result in the possibility that the compressed data is distributed
differently among the TLS frames that make up the stream.
If compatibility is a issue we could implement a new variant of
COMP_zlib(); COMP_tls_zlib() that would be used with ZLIB(1).
Well, I've got a couple of issues with such a change:
1. Is OpenSSL really the only implementation that has ZLIB at all? I
believe there aren't any compression numbers defined for ZLIB yet
(are have they actually been defined by now?), so I guess it might
be tricky to implement in any case...
If OpenSSL isn't alone with ZLIB compression, perhaps we should
look at interoperability?
2. How does that affect communication with programs running older
versions of OpenSSL? I assume that a change in dictionary reseting
will also change the actual data that's resulting from compression.
Will that be a problem?
--
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]
Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!!
The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP
http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL.
__
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 #361] OpenSSL and compression using ZLIB
- Original Message -
From: Jeffrey Altman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, November 24, 2002 8:26 AM
Subject: Re: OpenSSL and compression using ZLIB
http://www.ietf.org/internet-drafts/draft-ietf-tls-compression-03.txt
defines the compression numbers to be:
enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;
Therefore proposed numbers have been issued. I suggest that OpenSSL
define the CompressionMethod numbers to be:
enum { null(0), ZLIB(1), LZS(2), eayZLIB(224), eayRLE(225), (255) }
CompresssionMethod
as values in the range 193 to 255 are reserved for private use.
Where does the above draft state that the dictionary must be reset?
It states that the engine must be flushed but does not indicate that
the dictionary is to be reset. Resetting the dictionary would turn
ZLIB into a stateless compression algorithm and according to the draft
ZLIB is most certainly a stateful algorithm:
the compressor maintains it's state through all compressed records
I do not believe that compatibility will be an issue. It will simply
result in the possibility that the compressed data is distributed
differently among the TLS frames that make up the stream.
The draft clearly implies that the dictionary need not be reset and probably
should not be reset, but it is not clear to me that it prohibits this.
However, the draft talks about ...
If TLS is not being used with a protocol that provides reliable, sequenced
packet delivery, the sender MUST flush the compressor completely ...
I find this confusing because I've always understood that TLS assumes it is
running over just such a protocol. If I read it correctly, even EAP-TLS (RFC
2716) will handle sequencing, duped, and dropped packets before TLS
processing is invoked. So what's this clause alluding to?
In any event, I think I agree that the compressor can compatibly behave in
different ways as long as the decompressor doesn't care. I'm just not sure I
understand RFC1950 and 1951 well enough to know what is possible. Is flush
the compressor completely (as in the TLS compression draft language)
equivalent to compressing all the current data and emitting an end-of-block
code (value=256 in the language of RFC1951)? I'm guessing it is. Is
resetting the dictionary equivalent to compressing all the current data
and sending the block with the BFINAL bit set? If so, then it seems like the
decompressor can always react correctly and therefore compatibly in any of
the three cases. If the dictionary is reset for every record (current
OpenSSL behavior), then the decompressor knows this because the BFINAL bit
is set for every record. If the dictionary is not reset but is flushed for
every record, then the decompressor knows this because every record ends
with and end-of-block code. If the most optimal case is in play, which
implies a single uncompressed plaintext byte might be split across multiple
records, the decompressor can recognize and react properly to this case. If
all this is correct, then the next question is ...
What will the current implementation of thedecompressor in OpenSSL do in
each of these cases?
--greg
[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.org #361] OpenSSL and compression using ZLIB
In message 001601c2940a$deed1b60$06a8a8c0@dell8200 on Sun, 24 Nov 2002 16:43:12 -0600, pobox [EMAIL PROTECTED] said: ghstark What will the current implementation of thedecompressor in ghstark OpenSSL do in each of these cases? Unless this can be determined, it can be tested by having several OpenSSLs with different behavior and test them against each other. In any case, now that I know the numbers (yeah, I know, draft numbers, but that's better than nothing), I can always put them in 0.9.8-dev and try several algorithms (as was suggested, there's a private range, and I see no harm in using them for tests, at least temporarly). -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #361] OpenSSL and compression using ZLIB
On Mon, Nov 25, 2002 at 09:54:13AM +0100, Richard Levitte - VMS Whacker via RT wrote: In message 001601c2940a$deed1b60$06a8a8c0@dell8200 on Sun, 24 Nov 2002 16:43:12 -0600, pobox [EMAIL PROTECTED] said: ghstark What will the current implementation of thedecompressor in ghstark OpenSSL do in each of these cases? Unless this can be determined, it can be tested by having several OpenSSLs with different behavior and test them against each other. In any case, now that I know the numbers (yeah, I know, draft numbers, but that's better than nothing), I can always put them in 0.9.8-dev and try several algorithms (as was suggested, there's a private range, and I see no harm in using them for tests, at least temporarly). Bounced this thread into RT. Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #362] [no subject]
OUTPUT OF ./config -t Operating system: 9000/785-hp-hpux11 Configuring for hpux11 /usr/contrib/bin/perl ./Configure hpux11 Following the error reported by the command make after running ./Configure hpux11-64bit-cc on a system HP-UX hpiv113 B.11.11 U 9000/785 2016775763 unlimited-user license Please let me know as soon as you can. Thanks id advance Romana Rubino Majner __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #362] AutoReply: [no subject]
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #362] [no subject]
On Mon, Nov 25, 2002 at 10:22:37AM +0100, Romana Rubino via RT wrote: OUTPUT OF ./config -t Operating system: 9000/785-hp-hpux11 Configuring for hpux11 /usr/contrib/bin/perl ./Configure hpux11 Following the error reported by the command make after running ./Configure hpux11-64bit-cc on a system HP-UX hpiv113 B.11.11 U 9000/785 2016775763 unlimited-user license I don't see any error message included. Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #362] [no subject]
Sorry (See attached file: err) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #362] [no subject]
I already have a gcc installed (that one GNU). Can you know it is ok? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #362] [no subject]
How can I force the use of gcc? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #363] another problem
I try what your technician suggested me. I use now gcc but my compilation failed because I don't have a file idea.h in my sources. See the message : making all in crypto... ( echo #ifndef MK1MF_BUILD; \ echo /* auto-generated by crypto/Makefile.ssl for crypto/cversion.c */; \ echo #define CFLAGS \/usr/swlocal/bin/gcc -DTHREADS \; \ echo #define PLATFORM \myhpux-gcc\; \ echo #define DATE \`date`\; \ echo #endif ) buildinf.h /usr/swlocal/bin/gcc -I. -I../include -DTHREADS -c cryptlib.c /usr/swlocal/bin/gcc -I. -I../include -DTHREADS -c mem.c /usr/swlocal/bin/gcc -I. -I../include -DTHREADS -c cversion.c /usr/swlocal/bin/gcc -I. -I../include -DTHREADS -c ex_data.c /usr/swlocal/bin/gcc -I. -I../include -DTHREADS -c tmdiff.c ar r ../libcrypto.a cryptlib.o mem.o cversion.o ex_data.o tmdiff.o cpt_err.o /usr/bin/ranlib ../libcrypto.a making all in crypto/md2... /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c md2_dgst.c /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c md2_one.c ar r ../../libcrypto.a md2_dgst.o md2_one.o /usr/bin/ranlib ../../libcrypto.a making all in crypto/md5... /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c md5_dgst.c ar r ../../libcrypto.a md5_dgst.o md5_one.o /usr/bin/ranlib ../../libcrypto.a making all in crypto/sha... /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c sha_dgst.c /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c sha1dgst.c ar r ../../libcrypto.a sha_dgst.o sha1dgst.o sha_one.o sha1_one.o /usr/bin/ranlib ../../libcrypto.a making all in crypto/mdc2... /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c mdc2dgst.c /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c mdc2_one.c ar r ../../libcrypto.a mdc2dgst.o mdc2_one.o /usr/bin/ranlib ../../libcrypto.a making all in crypto/hmac... Make: Don't know how to make ../../include/openssl/idea.h. Stop. *** Error exit code 1 Stop. *** Error exit code 1 Stop. Thanks id advance Romana Rubino Majner __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #363] another problem
[[EMAIL PROTECTED] - Mon Nov 25 12:02:08 2002]: I try what your technician suggested me. I use now gcc but my compilation failed because I don't have a file idea.h in my sources. See the message : making all in crypto... ( echo #ifndef MK1MF_BUILD; \ echo /* auto-generated by crypto/Makefile.ssl for crypto/cversion.c */; \ echo #define CFLAGS \/usr/swlocal/bin/gcc -DTHREADS \; \ echo #define PLATFORM \myhpux-gcc\; \ echo #define DATE \`date`\; \ echo #endif ) buildinf.h /usr/swlocal/bin/gcc -I. -I../include -DTHREADS -c cryptlib.c /usr/swlocal/bin/gcc -I. -I../include -DTHREADS -c mem.c /usr/swlocal/bin/gcc -I. -I../include -DTHREADS -c cversion.c /usr/swlocal/bin/gcc -I. -I../include -DTHREADS -c ex_data.c /usr/swlocal/bin/gcc -I. -I../include -DTHREADS -c tmdiff.c ar r ../libcrypto.a cryptlib.o mem.o cversion.o ex_data.o tmdiff.o cpt_err.o /usr/bin/ranlib ../libcrypto.a making all in crypto/md2... /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c md2_dgst.c /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c md2_one.c ar r ../../libcrypto.a md2_dgst.o md2_one.o /usr/bin/ranlib ../../libcrypto.a making all in crypto/md5... /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c md5_dgst.c ar r ../../libcrypto.a md5_dgst.o md5_one.o /usr/bin/ranlib ../../libcrypto.a making all in crypto/sha... /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c sha_dgst.c /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c sha1dgst.c ar r ../../libcrypto.a sha_dgst.o sha1dgst.o sha_one.o sha1_one.o /usr/bin/ranlib ../../libcrypto.a making all in crypto/mdc2... /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c mdc2dgst.c /usr/swlocal/bin/gcc -I.. -I../../include -I../../../bsafe/include -DTHREADS -c mdc2_one.c ar r ../../libcrypto.a mdc2dgst.o mdc2_one.o /usr/bin/ranlib ../../libcrypto.a making all in crypto/hmac... Make: Don't know how to make ../../include/openssl/idea.h. Stop. *** Error exit code 1 Stop. *** Error exit code 1 Stop. I don't know, what is going on in your case. My copies of OpenSSL include idea.h. Anyway: you are somehow intermixing bsafe components. You must not do this! Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #363] AutoReply: another problem
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #363] another problem
Lutz Jaenicke via RT [EMAIL PROTECTED]@serv01.aet.tu-cottbus.de on 25/11/2002 12.04.38 Please respond to [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: [openssl.org #363] another problem I don't know, what is going on in your case. My copies of OpenSSL include idea.h. Anyway: you are somehow intermixing bsafe components. You must not do this! What does it means you are somehow intermixing bsafe components ? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
Jeffrey Altman via RT wrote:
What is the appropriate size for 'buf' in DSA_size()?
4 bytes is certainly not correct.
Hi Jeffry,
I think it's correct :-)
int DSA_size(const DSA *r)
{
int ret,i;
ASN1_INTEGER bs;
unsigned char buf[4];
i=BN_num_bits(r-q);
bs.length=(i+7)/8;
OPENSSL_assert(bs.length = sizeof buf);
I think this assertion wrong. Normally we have 2^159 q 2^160
(see FIPS 186-2) = i == 160 = bs.length == 20 4
bs.data=buf;
bs.type=V_ASN1_INTEGER;
/* If the top bit is set the asn1 encoding is 1 larger. */
buf[0]=0xff;
i=i2d_ASN1_INTEGER(bs,NULL);
i+=i; /* r and s */
ret=ASN1_object_size(1,i,V_ASN1_SEQUENCE);
return(ret);
}
i2d_ASN1_INTEGER() calls i2c_ASN1_INTEGER() (a_int.c) and
in i2c_ASN1_INTEGER() we have:
int i2c_ASN1_INTEGER(ASN1_INTEGER *a, unsigned char **pp)
// NOTE: pp == NULL
{
int pad=0,ret,i,neg;
unsigned char *p,*n,pb=0;
if ((a == NULL) || (a-data == NULL)) return(0);
neg=a-type V_ASN1_NEG;
if (a-length == 0)
ret=1;
else
{
ret=a-length;
i=a-data[0];
// NOTE: a-data[0] == 0xff == 255
if (!neg (i 127)) {
pad=1;
pb=0;
} else if(neg) {
if(i128) {
pad=1;
pb=0xFF;
} else if(i == 128) {
...
}
}
ret+=pad;
}
if (pp == NULL) return(ret);
...
hence only the first byte of 'buf' is used.
Regards,
Nils
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RSync server down?
Trying to rsync the cvs repository results in Connection refused has been doing so for the last few days. -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | -- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
Thanks. That is very reassuring.
Jeffrey Altman via RT wrote:
What is the appropriate size for 'buf' in DSA_size()?
4 bytes is certainly not correct.
Hi Jeffry,
I think it's correct :-)
int DSA_size(const DSA *r)
{
int ret,i;
ASN1_INTEGER bs;
unsigned char buf[4];
i=BN_num_bits(r-q);
bs.length=(i+7)/8;
OPENSSL_assert(bs.length = sizeof buf);
I think this assertion wrong. Normally we have 2^159 q 2^160
(see FIPS 186-2) = i == 160 = bs.length == 20 4
bs.data=buf;
bs.type=V_ASN1_INTEGER;
/* If the top bit is set the asn1 encoding is 1 larger. */
buf[0]=0xff;
i=i2d_ASN1_INTEGER(bs,NULL);
i+=i; /* r and s */
ret=ASN1_object_size(1,i,V_ASN1_SEQUENCE);
return(ret);
}
i2d_ASN1_INTEGER() calls i2c_ASN1_INTEGER() (a_int.c) and
in i2c_ASN1_INTEGER() we have:
int i2c_ASN1_INTEGER(ASN1_INTEGER *a, unsigned char **pp)
// NOTE: pp == NULL
{
int pad=0,ret,i,neg;
unsigned char *p,*n,pb=0;
if ((a == NULL) || (a-data == NULL)) return(0);
neg=a-type V_ASN1_NEG;
if (a-length == 0)
ret=1;
else
{
ret=a-length;
i=a-data[0];
// NOTE: a-data[0] == 0xff == 255
if (!neg (i 127)) {
pad=1;
pb=0;
} else if(neg) {
if(i128) {
pad=1;
pb=0xFF;
} else if(i == 128) {
...
}
}
ret+=pad;
}
if (pp == NULL) return(ret);
...
hence only the first byte of 'buf' is used.
Regards,
Nils
__
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 #363] another problem
Could you please send me the inlcude idea.h file? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #363] another problem
On Mon, Nov 25, 2002 at 01:49:15PM +0100, Romana Rubino via RT wrote: Could you please send me the inlcude idea.h file? Please download a recent version of openssl (0.9.6g is the latest stable release) from www.openssl.org. All required components are included. Case closed, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #363] Ticket Resolved
As I've already asked, where can I find this idea.h file? This ssl part is inserted in a greather environmet, sure can be there a bsave component. Sure I cannot compile my libssl.a library caused I cannot find idea.h. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #363] Ticket Resolved
On Mon, Nov 25, 2002 at 02:06:13PM +0100, Romana Rubino via RT wrote: As I've already asked, where can I find this idea.h file? This ssl part is inserted in a greather environmet, sure can be there a bsave component. Sure I cannot compile my libssl.a library caused I cannot find idea.h. As I have already stated, idea.h is part of OpenSSL and has been part of all version of OpenSSL since OpenSSL was born from SSLeay. openssl-0.9.6g/crypto/idea/idea.h After successfull call to Configure, you will find a softlink to it from openssl-0.9.6g/include/openssl/idea.h. -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error
[[EMAIL PROTECTED] - Sun Nov 24 19:52:37 2002]:
Hi!
I have a small problem with SSL_get_error. This function starts like
this:
int SSL_get_error(SSL *s,int i)
{
int reason;
unsigned long l;
BIO *bio;
if (i 0) return(SSL_ERROR_NONE);
/* Make things return SSL_ERROR_SYSCALL when doing
SSL_do_handshake
* etc, where we do encode the error */
if ((l=ERR_peek_error()) != 0)
{
if (ERR_GET_LIB(l) == ERR_LIB_SYS)
return(SSL_ERROR_SYSCALL);
else
return(SSL_ERROR_SSL);
}
Now, if I have something in the error stack from previous operations
and I
call SSL_read or SSL_write on non-blocking socket and read or write
returns -1 and sets errno to EAGAIN, then SSL_get_error will return
SSL_ERROR_SSL which makes this error look like an error in SSL
statemachine but it is really not.
Since BIO_f_ssl does not set retry flag for SSL_ERROR_SSL connection
aborts.
Ooops.
One solution to this problem is to make sure that ERR_clear_errors
gets
called every time before you do SSL_read or SSL_write (or
BIO_read/BIO_write). But I think that this is not a very good
approach,
because it relies on the good habbits of the application programmer.
Calling ERR_clear_errors automatically at the start of SSL_read and
SSL_write might hurt the performance and is therefore probably not a
very
good solution.
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.
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.
I suggest that if the exact kind of the error is important we should
add
an explicit parameter to the lower level functions to return this
information. Or additional status fields to strucutres like SSL.
Even though this seems to be a reasonable proposal, I am afraid that it
would require significant changes to the error handling concept...
Best regards,
Lutz
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
In message [EMAIL PROTECTED] on Mon, 25 Nov 2002 09:32:30 +0100 (MET), Jeffrey Altman via RT [EMAIL PROTECTED] said: rt rt What is the appropriate size for 'buf' in DSA_size()? rt rt 4 bytes is certainly not correct. My guess is that we want to support at rt least 256 bits and so it needs to be at least 32 bytes. Does anyone rt have a better recommendation? Which version of OpenSSL? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
In message [EMAIL PROTECTED] on Mon, 25 Nov 2002 09:32:30 +0100 (MET), Jeffrey Altman via RT [EMAIL PROTECTED] said: rt rt What is the appropriate size for 'buf' in DSA_size()? rt rt 4 bytes is certainly not correct. My guess is that we want to support at rt least 256 bits and so it needs to be at least 32 bytes. Does anyone rt have a better recommendation? Which version of OpenSSL? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4 there is an assertion added that is being triggered because the buf size is considered too small. However, tracing through the calls shows that even with a 160bit input only the first byte is ever touched. That does not mean other bytes could not be touched in the future though. In message [EMAIL PROTECTED] on Mon, 25 Nov 2002 09:32:30 +0100 (MET), Jeffrey Altman via RT [EMAIL PROTECTED] said: rt rt What is the appropriate size for 'buf' in DSA_size()? rt rt 4 bytes is certainly not correct. My guess is that we want to support at rt least 256 bits and so it needs to be at least 32 bytes. Does anyone rt have a better recommendation? Which version of OpenSSL? -- 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. Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4 there is an assertion added that is being triggered because the buf size is considered too small. However, tracing through the calls shows that even with a 160bit input only the first byte is ever touched. That does not mean other bytes could not be touched in the future though. In message [EMAIL PROTECTED] on Mon, 25 Nov 2002 09:32:30 +0100 (MET), Jeffrey Altman via RT [EMAIL PROTECTED] said: rt rt What is the appropriate size for 'buf' in DSA_size()? rt rt 4 bytes is certainly not correct. My guess is that we want to support at rt least 256 bits and so it needs to be at least 32 bytes. Does anyone rt have a better recommendation? Which version of OpenSSL? -- 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. Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
Jeffrey Altman wrote: The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4 there is an assertion added that is being triggered because the buf size is considered too small. However, tracing through the calls shows that even with a 160bit input only the first byte is ever touched. That does not mean other bytes could not be touched in the future though. That depends on the OpenSSL ASN1 code. But as far as I understand the code I don't know a possible reason to use any other value of the 'buf' array. In DSA_size() i2d_ASN1_INTEGER() is only called to get the max. possible length of the DER encoded integer (r and s) = only the first byte (with data[0] == 0xff) is needed. Regards, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
Jeffrey Altman wrote: The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4 there is an assertion added that is being triggered because the buf size is considered too small. However, tracing through the calls shows that even with a 160bit input only the first byte is ever touched. That does not mean other bytes could not be touched in the future though. That depends on the OpenSSL ASN1 code. But as far as I understand the code I don't know a possible reason to use any other value of the 'buf' array. In DSA_size() i2d_ASN1_INTEGER() is only called to get the max. possible length of the DER encoded integer (r and s) = only the first byte (with data[0] == 0xff) is needed. Regards, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL and compression using ZLIB
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. The other way around could work,
though: a compressor that works per record, sending to a decompressor that
maintains state.
Personally I am adding a separate compression scheme that I called
COMP_streamzlib to the already existing COMP_zlib and COMP_rle methods
defined in OpenSSL. The only (but significant) difference is that it will
maintain the compression state across records. For the time being, I will
just use one of the private IDs mentionned in the previous emails (193 to
255), as it is not compatible with the current zlib/openssl compression.
Eric Le Saux
Electronic Arts
-Original Message-
From: pobox [mailto:[EMAIL PROTECTED]]
Sent: Sunday, November 24, 2002 2:43 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: OpenSSL and compression using ZLIB
- Original Message -
From: Jeffrey Altman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, November 24, 2002 8:26 AM
Subject: Re: OpenSSL and compression using ZLIB
http://www.ietf.org/internet-drafts/draft-ietf-tls-compression-03.txt
defines the compression numbers to be:
enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;
Therefore proposed numbers have been issued. I suggest that OpenSSL
define the CompressionMethod numbers to be:
enum { null(0), ZLIB(1), LZS(2), eayZLIB(224), eayRLE(225), (255) }
CompresssionMethod
as values in the range 193 to 255 are reserved for private use.
Where does the above draft state that the dictionary must be reset?
It states that the engine must be flushed but does not indicate that
the dictionary is to be reset. Resetting the dictionary would turn
ZLIB into a stateless compression algorithm and according to the draft
ZLIB is most certainly a stateful algorithm:
the compressor maintains it's state through all compressed records
I do not believe that compatibility will be an issue. It will simply
result in the possibility that the compressed data is distributed
differently among the TLS frames that make up the stream.
The draft clearly implies that the dictionary need not be reset and probably
should not be reset, but it is not clear to me that it prohibits this.
However, the draft talks about ...
If TLS is not being used with a protocol that provides reliable, sequenced
packet delivery, the sender MUST flush the compressor completely ...
I find this confusing because I've always understood that TLS assumes it is
running over just such a protocol. If I read it correctly, even EAP-TLS (RFC
2716) will handle sequencing, duped, and dropped packets before TLS
processing is invoked. So what's this clause alluding to?
In any event, I think I agree that the compressor can compatibly behave in
different ways as long as the decompressor doesn't care. I'm just not sure I
understand RFC1950 and 1951 well enough to know what is possible. Is flush
the compressor completely (as in the TLS compression draft language)
equivalent to compressing all the current data and emitting an end-of-block
code (value=256 in the language of RFC1951)? I'm guessing it is. Is
resetting the dictionary equivalent to compressing all the current data
and sending the block with the BFINAL bit set? If so, then it seems like the
decompressor can always react correctly and therefore compatibly in any of
the three cases. If the dictionary is reset for every record (current
OpenSSL behavior), then the decompressor knows this because the BFINAL bit
is set for every record. If the dictionary is not reset but is flushed for
every record, then the decompressor knows this because every record ends
with and end-of-block code. If the most optimal case is in play, which
implies a single uncompressed plaintext byte might be split across multiple
records, the decompressor can recognize and react properly to this case. If
all this is correct, then the next question is ...
What will the current implementation of thedecompressor in OpenSSL do in
each of these cases?
--greg
[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.org #360] crypto/dsa/dsa_lib.c DSA_size()
Then the assertion should be removed because as it is now it will always fail. Jeffrey Altman wrote: The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4 there is an assertion added that is being triggered because the buf size is considered too small. However, tracing through the calls shows that even with a 160bit input only the first byte is ever touched. That does not mean other bytes could not be touched in the future though. That depends on the OpenSSL ASN1 code. But as far as I understand the code I don't know a possible reason to use any other value of the 'buf' array. In DSA_size() i2d_ASN1_INTEGER() is only called to get the max. possible length of the DER encoded integer (r and s) = only the first byte (with data[0] == 0xff) is needed. Regards, Nils Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #360] crypto/dsa/dsa_lib.c DSA_size()
Then the assertion should be removed because as it is now it will always fail. Jeffrey Altman wrote: The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4 there is an assertion added that is being triggered because the buf size is considered too small. However, tracing through the calls shows that even with a 160bit input only the first byte is ever touched. That does not mean other bytes could not be touched in the future though. That depends on the OpenSSL ASN1 code. But as far as I understand the code I don't know a possible reason to use any other value of the 'buf' array. In DSA_size() i2d_ASN1_INTEGER() is only called to get the max. possible length of the DER encoded integer (r and s) = only the first byte (with data[0] == 0xff) is needed. Regards, Nils Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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]
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]
