Re: [openssl.org #86] Bug in RSA_check_key
Indeed it would be a good idea, especially for RSA_generate_key, since people have to generate their key thru an interface that is extern to OpenSSL, then sign their CSR with that key using OpenSSL, when everything could be implemented within OpenSSL. The major benefit would come for, a PKI architecture based on OpenSSL, imagine a CA tree, if I want the key of the ROOT CA, the SUB-CAs to be stocked in a hardware device, you can't make it thru OpenSSL, and it become a pain in the butt if your architecture is managed thru the network, you will have to physically go on the CA computer, to generate each of the SUB-CAs keys. --- Geoff Thorpe via RT [EMAIL PROTECTED] wrote: Just attaching a little more state to this ticket ... [[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]: The problem is that the use oF engines should be totaly transparent to the higher API, but apparently it's not. I don't call RSA_check_key for a hardware key, I call it for my CA private key, and I don't know if it's a hardware or software key since it's transparent. [snip] Richard just added a couple of notes to the documentation at the same time I was working on it. I may or may not put my changes over the top of his yet, but in the mean time ... I think the ultimate solution to this problem will be similar to the ultimate solution to the problem of generic key generation - ie. key generation that is independant of the ENGINE implementation being used. When you think about the underlying problem, the solution is rather obvious (but perhaps annoying to implement); the basic problem is that RSA_generate_key() and RSA_check_key() both directly deal with structure elements rather than using members of the RSA_METHOD vt. If RSA_public_decrypt() did the same thing, it would have the same problem of not working with replacement RSA implementations. I think the check_key functionality needs to go into a handler callback in the RSA_METHOD itself so that any implementation that alters the way key material is stored and managed can similarly implement a corresponding mechanism for verifying key integrity. In the mean time, the short-term solution (bear in mind this will break binary compatibility to some extent and will require all ENGINEs to be adapted) is to alter the documentation to describe the situation. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ Post your ad for free now! http://personals.yahoo.ca __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #141] Error while writing zero-length string
tor 2002-07-18 klockan 13.04 skrev Bodo Moeller via RT: SSL_read() and SSL_write() are not really meant to be called with zero length. The return value cannot be larger than zero when this is done, so SSL_get_error() will interpret the return value as an error indication. Then the documentation should say this in large friendly letters :) We could change SSL_read() and SSL_write() to return an actual error when they are called with length 0, but this might break programs that do such calls but don't rely on SSL_get_error() for them. I suppose it should be possible to change the implementations behind SSL_read() and SSL_write() (i.e. ssl3_read() etc.) to use an extra flag for the special case of zero length parameters so that SSL_get_error() will indicate success unless there really was some kind of error, but I'm not convinced this is worth the effort -- why call the functions with length 0 anyway? Why? Perhaps because of mistakes in the coding. Perhaps because the author didn't think it was invalid and didn't want to add to the complexity of his code with Yet Another if. This bug bit us because the protocol framework we are using did exactly this and it took us a long time tracking it down. Note that it's perfectly valid to call write(2) with an empty string and that a zero return doesn't mean the connection was closed. A warning in the man pages for SSL_write (and probably SSL_read too) would a good start for this. Regards, Martin -- Martin Sjögren [EMAIL PROTECTED] ICQ : 41245059 Phone: +46 (0)31 7710870 Cell: +46 (0)739 169191 GPG key: http://www.strakt.com/~martin/gpg.html __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: arbitrary DH keys for ADH-DES-CBC3-SHA
On Fri, Jul 19, 2002 at 09:37:22AM +0200, Michael Schmidt wrote: Hi, For a research project I'm working on, I want to use OpenSSL with ADH-DES-CBC3-SHA (TLSv1). This means I want to use neither a server-side nor a client-side certificate; and the pre-master secret shall be established via Diffie-Hellman key exchange. I understand that the current implementation of SSL_CTX_set_tmp_dh (SSL_CTX *ctx, DH *dhkey), which I'm using to set the DH private and public key, ignores any existing keys in dhkey-priv_key and dhkey-pub_key, and uses only the DH key generation parameters (prime and generator) from this structure. Looks like it generates random DH keys by its own. A callback is available, to set DH key. See ssl3_send_server_key_exchange() around s-cert-dh_tmp_cb() for details. That is, one can set this callback instead of SSL_CTX_set_tmp_dh() However, I would like to feed the TLS pre-master secret generation on both client and server side with arbitrary DH key pairs of my own. From my understanding of RFC 2246 (TLSv1), this is in conformance with the spec. Now I'm wondering whether this is possible using the regular OpenSSL API. If not, how else could I achieve this (I don't have major problems with modifying my version of the OpenSSL source code)? I just need to understand where to inject my keys. Thanks, Michael -- = Michael Schmidt - Institute for Data Communications Systems University of Siegen, Germany - http: www.nue.et-inf.uni-siegen.de/~schmidt/ e-mail: [EMAIL PROTECTED] phone: +49 271 740-2332 fax: +49 271 740-2536 mobile: +49 179 7810214 = __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Naina library: http://www.unity.net/~vf/naina_r1.tgz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #141] Error while writing zero-length string
On Fri, Jul 19, 2002 at 10:39:21AM +0200, Martin Sjögren via RT wrote: Note that it's perfectly valid to call write(2) with an empty string [...] This is true only for regular files. According to the The Single UNIX Specification, Version 2, and related write() manual pages on systems such as Solaris: If nbyte is 0, write() will return 0 and have no other results if the file is a regular file; otherwise, the results are unspecified. A warning in the man pages for SSL_write (and probably SSL_read too) would a good start for this. I agree. Actually it should be quite easy to change OpenSSL so that this problem is avoided (I just can't do this in the the 0.9.6 branch because I have to extend the SSL structure, which will destroy binary compatibility). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #141] Error while writing zero-length string
On Fri, Jul 19, 2002 at 10:39:21AM +0200, Martin Sjögren via RT wrote: tor 2002-07-18 klockan 13.04 skrev Bodo Moeller via RT: SSL_read() and SSL_write() are not really meant to be called with zero length. The return value cannot be larger than zero when this is done, so SSL_get_error() will interpret the return value as an error indication. Then the documentation should say this in large friendly letters :) We could change SSL_read() and SSL_write() to return an actual error when they are called with length 0, but this might break programs that do such calls but don't rely on SSL_get_error() for them. I suppose it should be possible to change the implementations behind SSL_read() and SSL_write() (i.e. ssl3_read() etc.) to use an extra flag for the special case of zero length parameters so that SSL_get_error() will indicate success unless there really was some kind of error, but I'm not convinced this is worth the effort -- why call the functions with length 0 anyway? Why? Perhaps because of mistakes in the coding. Perhaps because the author didn't think it was invalid and didn't want to add to the complexity of his code with Yet Another if. This bug bit us because the protocol framework we are using did exactly this and it took us a long time tracking it down. Note that it's perfectly valid to call write(2) with an empty string and that a zero return doesn't mean the connection was closed. Hmm. Manual pages between systems can be different. I cite from Linux now: read(2): ... On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. ... Therefore the case, that '0' bytes were read actually could not appear. Translated to the SSL_* case this means, that SSL_read() is behaving quite similar to that of read(2). With respect to write(2): ... On success, the number of bytes written are returned (zero indicates nothing was written). On error, -1 is returned, and errno is set appropriately. If count is zero and the file descriptor refers to a regular file, 0 will be returned without causing any other effect. For a special file, the results are not portable. ... Thus it seems, that writing an amount of 0 bytes is not that portable as it seems. What would be thinkable is that SSL_write() with a bytecount of 0 gets a shortcut returning 0 bytes written without actually doing anything. This however might conflict with SSL_get_error() and I do not think, that it would be a worthwhile addition. It seems that an appropriate addition to the SSL_write() manual page is the correct solution. Best regards, 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 #157] Contribution: zencod ENGINE
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: arbitrary DH keys for ADH-DES-CBC3-SHA
Hi Vadim, Vadim Fedukovich schrieb: For a research project I'm working on, I want to use OpenSSL with ADH-DES-CBC3-SHA (TLSv1). This means I want to use neither a server-side nor a client-side certificate; and the pre-master secret shall be established via Diffie-Hellman key exchange. I understand that the current implementation of SSL_CTX_set_tmp_dh (SSL_CTX *ctx, DH *dhkey), which I'm using to set the DH private and public key, ignores any existing keys in dhkey-priv_key and dhkey-pub_key, and uses only the DH key generation parameters (prime and generator) from this structure. Looks like it generates random DH keys by its own. A callback is available, to set DH key. See ssl3_send_server_key_exchange() around s-cert-dh_tmp_cb() for details. That is, one can set this callback instead of SSL_CTX_set_tmp_dh() Thanks for the info. However, the callback is called on the server side only. Any idea about the client side? If not, it's progress anyway. It's probably easier for me to activate the callback on the client side than to fiddle around with the implementation of SSL_CTX_set_tmp_dh. Michael __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: arbitrary DH keys for ADH-DES-CBC3-SHA
hi Michael, On Fri, Jul 19, 2002 at 12:17:23PM +0200, Michael Schmidt wrote: Hi Vadim, Vadim Fedukovich schrieb: For a research project I'm working on, I want to use OpenSSL with ADH-DES-CBC3-SHA (TLSv1). This means I want to use neither a server-side nor a client-side certificate; and the pre-master secret shall be established via Diffie-Hellman key exchange. I understand that the current implementation of SSL_CTX_set_tmp_dh (SSL_CTX *ctx, DH *dhkey), which I'm using to set the DH private and public key, ignores any existing keys in dhkey-priv_key and dhkey-pub_key, and uses only the DH key generation parameters (prime and generator) from this structure. Looks like it generates random DH keys by its own. A callback is available, to set DH key. See ssl3_send_server_key_exchange() around s-cert-dh_tmp_cb() for details. That is, one can set this callback instead of SSL_CTX_set_tmp_dh() Thanks for the info. However, the callback is called on the server side only. Any idea about the client side? maybe, it could be a good idea to introduce another one callback, for ssl3_send_client_key_exchange() to use some specific DH key, if you really want it. No way around DH_generate_key() for the moment good luck, Vadim If not, it's progress anyway. It's probably easier for me to activate the callback on the client side than to fiddle around with the implementation of SSL_CTX_set_tmp_dh. Michael -- Naina library: http://www.unity.net/~vf/naina_r1.tgz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #59] 0.9.7 EVP manual pages incomplete
Geoff Thorpe via RT wrote: G'day, [levitte - Thu Jul 18 20:55:58 2002]: I just did a tentative addition of history. Please check it and complete it if needed. Yup the history stuff looks great, thanks Richard. However I'm not sure who understands the EVP behavioural changes well enough to comment/document them definitively. I sure don't. I have a feeling the two most likely contenders are Ben and Steve, though both of them will probably redirect all mail from me to /dev/null for suggesting such a thing... I will confess that we are the most likely candidates, but I will also confess that they are no longer in my head. I also won't have time for at least a week to think about the issue. But I am happy to be nagged! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Undefined symbol in 0.9.7beta2 and 0.9.8-dev
Title: Undefined symbol in 0.9.7beta2 and 0.9.8-dev Hi all, I find an error using Konqueror Web Browser: undefined symbol: OpenSSL_add_all_algorithms I have a look at symbol using objdump -T, OPenSSL_add_all_algorithms was not present. It was in openssl-0.9.6x? Is this normal? or evolution due to evp? Regards Fred
Re: Undefined symbol in 0.9.7beta2 and 0.9.8-dev
In message [EMAIL PROTECTED] on Fri, 19 Jul 2002 14:24:13 +0200, Frederic DONNAT [EMAIL PROTECTED] said: frederic.donnat I find an error using Konqueror Web Browser: frederic.donnat undefined symbol: OpenSSL_add_all_algorithms frederic.donnat frederic.donnat I have a look at symbol using objdump -T, OPenSSL_add_all_algorithms was not present. frederic.donnat It was in openssl-0.9.6x? frederic.donnat Is this normal? or evolution due to evp? It became a macro. -- 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 #141] Error while writing zero-length string
tor 2002-07-18 klockan 13.04 skrev Bodo Moeller via RT: SSL_read() and SSL_write() are not really meant to be called with zero length. The return value cannot be larger than zero when this is done, so SSL_get_error() will interpret the return value as an error indication. Then the documentation should say this in large friendly letters :) We could change SSL_read() and SSL_write() to return an actual error when they are called with length 0, but this might break programs that do such calls but don't rely on SSL_get_error() for them. I suppose it should be possible to change the implementations behind SSL_read() and SSL_write() (i.e. ssl3_read() etc.) to use an extra flag for the special case of zero length parameters so that SSL_get_error() will indicate success unless there really was some kind of error, but I'm not convinced this is worth the effort -- why call the functions with length 0 anyway? Why? Perhaps because of mistakes in the coding. Perhaps because the author didn't think it was invalid and didn't want to add to the complexity of his code with Yet Another if. This bug bit us because the protocol framework we are using did exactly this and it took us a long time tracking it down. Note that it's perfectly valid to call write(2) with an empty string and that a zero return doesn't mean the connection was closed. A warning in the man pages for SSL_write (and probably SSL_read too) would a good start for this. Regards, Martin -- Martin Sjögren [EMAIL PROTECTED] ICQ : 41245059 Phone: +46 (0)31 7710870 Cell: +46 (0)739 169191 GPG key: http://www.strakt.com/~martin/gpg.html __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
