Re: OpenSSL and compression using ZLIB
I have used ZLIB in several projects, but my knowledge of it it´s not as deep as yours, but...aren't you talking about a simple BIO for compressing data?.(Or,probably, I missed something in this discussion thread?) I think the BIO would mantain the context (as z_stream struct of ZLIB do) among several calls to BIO_write/read, so if you want to compress communication data you have to chain this zBIO with a socket BIO. Some disccusion and solution on this can be found here http://marc.theaimsgroup.com/?l=openssl-devm=99927148415628w=2 I have used that to compress/cipher/base64 big files with chained BIOs (and a similar implementation of zBIO showed there) and it works, so may be it would work one step more with sockets BIOs. - Original Message - From: Le Saux, Eric [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 7:24 PM Subject: RE: OpenSSL and compression using ZLIB 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] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED]
Re: [openssl.org #257] openssl-0.9.7-beta3 on Irix
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. MIPSpro Compilers: Version 7.3.1.3m No luck with 7.3.1.3m either. I mean I *failed* to reproduce it even with 7.3.1.3m. Can you post output from 'apps/openssl version -a'. CC=cc CFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include ^ Well, this is just not fair! ./INSTALL file explicitely advises to *lower* the optimization level before submitting a bug report to openssl. Idea is that if test passes at lower optimization level, then it's most likely between you and your compiler vendor. Do note that ./Configure does suggest -O2. And what does this output mean anyway? Is it your environment variables? Is it something you've planted directly into OpenSSL Makefile? Do post output from 'apps/openssl version -a'. 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
On Wed, 27 Nov 2002, Martin MOKREJ wrote: Yes, those were my environment variables, but as I see some of the setting were overriden by configure. Do post output from 'apps/openssl version -a'. OpenSSL 0.9.6h-dev xx XXX built on: Wed Nov 6 16:09:53 CET 2002 platform: irix-mips3-cc options: bn(64,64) md2(int) rc4(ptr,char) des(ptr,risc2,16,long) idea(int) blowfish(ptr) compiler: cc -DDSO_DLFCN -DHAVE_DLFCN_H -n32 -O2 -use_readonly_const -DTERMIOS -DB_ENDIAN -DBN_DIV3W Ooops, I've pasted the output from my last working version (openssl-0.9.6-stable-SNAP-20021102). I'm now compiling openssl-0.9.7-beta4 from scratch and will post the proper 'apps/openssl version -a' output. Sorry for confusion. :( -- 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]
[openssl.org #367] s3_clnt.c ssl3_get_server_hello and SSL_SESSION cipher_id 0.9.7-b4
Sometime in the last couple of weeks the following change was made to s3_clnt.c 698,699c699 if (s-hit (s-session-cipher != c)) --- if (s-hit (s-session-cipher_id != c-id)) The only problem is that at this point in time the cipher_id field of the SSL_SESSION has not been set. Therefore, this test fails. If you do not trust the pointer comparison (and I wouldn't) the following change does work if (s-hit (s-session-cipher-id != c-id)) It is interesting to note that in i2d_SSL_SESSION() the following code is used to determine the cipher id: if (in-cipher == NULL) l=in-cipher_id; else l=in-cipher-id; This leads me to believe the proper change should look like: if (s-session-cipher == NULL) id=s-session-cipher_id; else id=s-session-cipher-id; if (s-hit (id != c-id)) I do wonder why the SSL_SESSION cipher_id field is not consistently set when the cipher itself is set. 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 #367] s3_clnt.c ssl3_get_server_hello and SSL_SESSION cipher_id 0.9.7-b4
[[EMAIL PROTECTED] - Wed Nov 27 14:49:04 2002]: Sometime in the last couple of weeks the following change was made to s3_clnt.c 698,699c699 if (s-hit (s-session-cipher != c)) --- if (s-hit (s-session-cipher_id != c-id)) ... This problem was already reported as #351 and has been fixed in the meantime. The problem was introduced when working on #288. Ticket merged into 288, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/asn1 x_x509a.c
Dear Openssl Developer,
Is there any command that generates a cross certificate pair, or
only the ASN.1 data structure?
With Best Regards,
-Kiyoshi
Kiyoshi Watanabe
levitte 27-Nov-2002 14:40:12
Modified:crypto/asn1 x_x509a.c
Log:
Extra ; removed.
Revision ChangesPath
1.16 +1 -1 openssl/crypto/asn1/x_x509a.c
Index: x_x509a.c
===
RCS file: /e/openssl/cvs/openssl/crypto/asn1/x_x509a.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- x_x509a.c 2002/11/18 23:54:22 1.15
+++ x_x509a.c 2002/11/27 13:40:11 1.16
@@ -175,6 +175,6 @@
ASN1_SEQUENCE(X509_CERT_PAIR) = {
ASN1_EXP_OPT(X509_CERT_PAIR, forward, X509, 0),
ASN1_EXP_OPT(X509_CERT_PAIR, reverse, X509, 1)
-} ASN1_SEQUENCE_END(X509_CERT_PAIR);
+} ASN1_SEQUENCE_END(X509_CERT_PAIR)
IMPLEMENT_ASN1_FUNCTIONS(X509_CERT_PAIR)
__
OpenSSL Project http://www.openssl.org
CVS Repository Commit 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 #257] openssl-0.9.7-beta3 on Irix
so, once more. I've tested now openssl-0.9.7-beta4: ./Configure irix-mips3-cc --prefix=/usr/local/openssl --openssldir=/usr/local/openssl no-threads Configuring for irix-mips3-cc IsWindows=0 CC=cc CFLAG =-DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -n32 -O2 -use_readonly_const -DTERMIOS -DB_ENDIAN -DBN_DIV3W The test went all fine with this version. It's not this version, it was *your* optimization level. Recommended -O2 works, -O3 does not. It's therefore not an OpenSSL issue. Case is/should be/will be dismissed. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL and compression using ZLIB
Yes, very interesting. This is another way of adding compression to the data pipe. I have not looked at the code, but I assume that the compression state is maintained for the whole life of the communication channel, which is what gives the best results. Have you tried to use SSL_COMP_add_compression_method() also? Cheers, Eric Le Saux Electronic Arts -Original Message- From: Pablo J Royo [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 12:27 AM To: [EMAIL PROTECTED] Subject: Re: OpenSSL and compression using ZLIB I have used ZLIB in several projects, but my knowledge of it it´s not as deep as yours, but...aren't you talking about a simple BIO for compressing data?.(Or,probably, I missed something in this discussion thread?) I think the BIO would mantain the context (as z_stream struct of ZLIB do) among several calls to BIO_write/read, so if you want to compress communication data you have to chain this zBIO with a socket BIO. Some disccusion and solution on this can be found here http://marc.theaimsgroup.com/?l=openssl-devm=99927148415628w=2 I have used that to compress/cipher/base64 big files with chained BIOs (and a similar implementation of zBIO showed there) and it works, so may be it would work one step more with sockets BIOs. - Original Message - From: Le Saux, Eric [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 7:24 PM Subject: RE: OpenSSL and compression using ZLIB 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]
Re: [openssl.org #343] Fw: When scrubbing secrets in memory doesn't work
Hi, Thanks for the update. Do you have an email address for the OpenSSH developers? On 14th November I sent a similar email to [EMAIL PROTECTED] [EMAIL PROTECTED] but haven't recieved a reply. Thanks, Adrian - Original Message - From: Richard Levitte via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 4:05 PM Subject: [openssl.org #343] Fw: When scrubbing secrets in memory doesn't work [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]
RE: [openssl.org #353] 0.9.7 B4 testssl with no-dh fails
Whoops! I sent a bad suggested fix for this. This should be better. Chris Brook ### 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 if ../apps/openssl no-dh; then echo skipping RSA 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 fi ## __ 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
Whoops! I sent a bad suggested fix for this. This should be better. Chris Brook ### 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 if ../apps/openssl no-dh; then echo skipping RSA 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 fi ## __ 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]
engine vs non egine
Hi there Can anybody tell what is the difference between openssl-engine-0.9.6a.tar.gzand openssl-0.9.6a.tar.gz thanks Zvi IBM __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
How to port for Palm
Dear Sir, Iam trying to port OpenSSL to Palm. Iam trying to develop a client side application that would use SSL. Could someone please guide me as what are the common files that I would need to take as-is and what are the files that need to be ported for a particular OS(Palm OS). Thanks in advance. Venkatesh _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: engine vs non egine
openssl-engine-0.9.6a.tar.gz supports several cryptographic accelerator cards which openssl-0.9.6a does not support. Otherwise the two distributions are the same. Also, it would be better to use OpenSSL 0.9.6g than OpenSSL 0.9.6a, since there are some security holes that have been fixed since 0.9.6a. And [EMAIL PROTECTED] is a better list for asking these kinds of questions, [EMAIL PROTECTED] is really for discussing the development of OpenSSL itself, rather than development of other applications which use OpenSSL. Lynn Gazis Rainbow Technologies -Original Message- From: Zvi Dubitzky [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 8:42 AM To: [EMAIL PROTECTED] Subject: engine vs non egine Hi there Can anybody tell what is the difference between openssl-engine-0.9.6a.tar.gzand openssl-0.9.6a.tar.gz thanks Zvi IBM __ 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
On November 27, 2002 12:33 pm, Le Saux, Eric wrote: Yes, very interesting. This is another way of adding compression to the data pipe. I have not looked at the code, but I assume that the compression state is maintained for the whole life of the communication channel, which is what gives the best results. Um, out of curiosity ... wouldn't this be the easiest way to implement a custom compression method anyhow? Ie. define the compression method so that the SSL/TLS handshake can take care of agreeing (or not) about compression at each end, but do not implement the method inside SSL/TLS processing - ie. if that compression method is agreed, cause a zlib BIO to be inserted (or removed, in the case of a renegotiation perhaps) onto the application side of the SSL object's BIO chain (um, actually chains, one each for read and write I suppose) ... this essentially does what Pablo was referring to but lets the SSL/TLS handshake take care of negotiating compression with the peer. The latter is the problem with just putting the compression layer inside the SSL/TLS layer, you need an out-of-band (read: application) mechanism to decide when to use it or not. It sounds a bit magic(k) though ... hmm ... perhaps buffering/flushes would be the problem when applications use non-blocking sockets? If not, this sounds easier than putting the zlib manipulation inside the SSL/TLS layer and would probably give faster and better compression too. oh yes: Pablo J Royo wrote; I think the BIO would mantain the context (as z_stream struct of ZLIB do) among several calls to BIO_write/read, so if you want to compress communication data you have to chain this zBIO with a socket BIO. almost - presumably the socket BIO you refer to is on the SSL/TLS data side rather than the application data side, in which case your compression won't do much. Compression is only useful on the assumption that the application data itself is compressible, and by the time you get SSL/TLS data - it's (hopefully) too well encrypted for compression to have much effect. :-) I assume you ment to chain it with a memory/buffer BIO? Ie. going from; -- write_BIO -- -- \ [app] [SSL] socket_BIO -- read_BIO -- -- / to; -- write_BIO -- zlib_BIO -- --\ [app][SSL] socket_BIO -- read_BIO -- zlib_BIO -- --/ ? 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]
Re: OpenSSL and compression using ZLIB
Date sent: Wed, 27 Nov 2002 14:58:24 -0500 From: Geoff Thorpe [EMAIL PROTECTED] Subject:Re: OpenSSL and compression using ZLIB To: [EMAIL PROTECTED] Copies to: Le Saux, Eric [EMAIL PROTECTED], royop@tb- solutions.com Send reply to: [EMAIL PROTECTED] Um, well that's one approach. But its a little like saying Lets let SSL/TLS take care of agreeing on a cipher type, and then leave it up to the user application to take care of the actual encryption/decrytion. I would rather see the most commonly used methods inplemented within SSL/TLS itself. Ken On November 27, 2002 12:33 pm, Le Saux, Eric wrote: Yes, very interesting. This is another way of adding compression to the data pipe. I have not looked at the code, but I assume that the compression state is maintained for the whole life of the communication channel, which is what gives the best results. Um, out of curiosity ... wouldn't this be the easiest way to implement a custom compression method anyhow? Ie. define the compression method so that the SSL/TLS handshake can take care of agreeing (or not) about compression at each end, but do not implement the method inside SSL/TLS processing - ie. if that compression method is agreed, cause a zlib BIO to be inserted (or removed, in the case of a renegotiation perhaps) onto the application side of the SSL object's BIO chain (um, actually chains, one each for read and write I suppose) ... this essentially does what Pablo was referring to but lets the SSL/TLS handshake take care of negotiating compression with the peer. The latter is the problem with just putting the compression layer inside the SSL/TLS layer, you need an out-of-band (read: application) mechanism to decide when to use it or not. It sounds a bit magic(k) though ... hmm ... perhaps buffering/flushes would be the problem when applications use non-blocking sockets? If not, this sounds easier than putting the zlib manipulation inside the SSL/TLS layer and would probably give faster and better compression too. oh yes: Pablo J Royo wrote; I think the BIO would mantain the context (as z_stream struct of ZLIB do) among several calls to BIO_write/read, so if you want to compress communication data you have to chain this zBIO with a socket BIO. almost - presumably the socket BIO you refer to is on the SSL/TLS data side rather than the application data side, in which case your compression won't do much. Compression is only useful on the assumption that the application data itself is compressible, and by the time you get SSL/TLS data - it's (hopefully) too well encrypted for compression to have much effect. :-) I assume you ment to chain it with a memory/buffer BIO? Ie. going from; -- write_BIO -- -- \ [app] [SSL] socket_BIO -- read_BIO -- -- / to; -- write_BIO -- zlib_BIO -- --\ [app][SSL] socket_BIO -- read_BIO -- zlib_BIO -- --/ ? 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] ___ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-398-0221 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and compression using ZLIB
On November 27, 2002 03:24 pm, Kenneth R. Robinette wrote: Um, well that's one approach. But its a little like saying Lets let SSL/TLS take care of agreeing on a cipher type, and then leave it up to the user application to take care of the actual encryption/decrytion. I would rather see the most commonly used methods inplemented within SSL/TLS itself. If the SSL/TLS implementation is doing the (de)compression I don't see what your point is. Ie. with this compression method negotiated by the client and server, the SSL/TLS would still be responsible for handling compression - it would just handle it on the application data before applying the SSL/TLS framing rather than compressing data inside it. From the application point of view, there's no need to implement anything. Did you misunderstand me or vice versa? 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]
Re: How to port for Palm
Ian Goldberg did some work as part of TopGun (this is a rather outdated port though): http://www.isaac.cs.berkeley.edu/pilot/ Also, Palm OS 5.0 is supposed to ship with an SSL library. nagendra * mohanraj venkatesh kumar [EMAIL PROTECTED] [2002-11-27 16:27:54 +]: Dear Sir, Iam trying to port OpenSSL to Palm. Iam trying to develop a client side application that would use SSL. Could someone please guide me as what are the common files that I would need to take as-is and what are the files that need to be ported for a particular OS(Palm OS). Thanks in advance. Venkatesh _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail __ 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]
