RE: X9.42 DH test vectors.
Hi Peter I'm also very interested in these data. Are you providing all the stuff over the mailing list? Otherwise please CC me too =) Thanks in advance Rene -- Rene G. Eberhard [EMAIL PROTECTED] keyon Herrenberg 35, CH-8640 Rapperswil, Switzerland Phone +41 (0)55 220 71 63, Fax +41 (0)55 220 71 61 www.keyon.ch - applying security to your e-business -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Gutmann Sent: Sunday, January 23, 2000 10:52 AM To: [EMAIL PROTECTED] Subject: Re: X9.42 DH test vectors. Dr Stephen Henson [EMAIL PROTECTED] writes: One problem with X9.42 DH. I haven't seen any examples of the domain parameter generation (the one based on DSA) that have m 160 (Other then the S/MIME examples stuff which so far I can't reproduce and which no one says they've independently verified). They all have m = 160. Certain parts of the algorithm aren't used unless m 160. So has anyone got any examples or can generate some I can independently verify? Its just the domain parameter stuff I'm after, I've lots of test data for the other parts of the algorithm. Sure, what form do you want it in? DSA-signed DH cert? Peter. __ 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: Problems compiling OpenSSL
jorcasga I'm trying to install OpenSSL 0.9.4 on a Sun Netra computer with Solaris jorcasga 2.6, and I get the following error message wen running 'make': jorcasga jorcasga ar r ../libcrypto.a cryptlib.o mem.o cversion.o ex_data.o tmdiff.o jorcasga cpt_err.o jorcasga make[1]: ar: Command not found Either install GNU binutils or check if you need to haev /usr/ucb or /usr/ccs/bin in your $PATH. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-161 43 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED] 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: [Fwd: OCSP and CSL]
Massimiliano Pala wrote: I am forwarding this message to the openssl-dev list so as to ask for support in generating such CSLs (read on). Some chance in getting help to write the code ??? Actually the CRLs do not support extentions in OpenSSL, isn't it ?? Well it does support extensions but not IDP or deltaCRL. Rhe standard CRL generation utility 'ca' can't handle CRL entry extensions either. 'ca' probably isn't suited to the task and something like an option to the 'crl' program to allow a CRL to be generated from a config file would IMHO be the best way. This probably wont make it into 0.9.5 but maybe the next release... Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problems compiling OpenSSL
Jorge Castello wrote: Helo: I'm trying to install OpenSSL 0.9.4 on a Sun Netra computer with Solaris 2.6, and I get the following error message wen running 'make': ar r ../libcrypto.a cryptlib.o mem.o cversion.o ex_data.o tmdiff.o cpt_err.o make[1]: ar: Command not found try putting /usr/xpg4/bin or /usr/ccs/bin in yer path... Start here: `man ar` __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect() fails on non-blocking sockets.
Matti Aarnio [EMAIL PROTECTED]: It turned out that while the socket the SMTP client code creates is running in non-blocking mode, I must temporarily turn the blocking mode on while the SSL setup negotiations are under way. I don't know if creating some wrapper to retry calls to SSL_connect() would have helped, but such would have been rather massively kludgy thing.. SSL_connect needs multiple I/O operations in both directions, so you cannot expect it to finish at once for non-blocking I/O. SSL_connect returning -1 does not always indicate an error. Use SSL_get_error to find out if the application should select() for readable bytes or for a possibility to write more data. NAME SSL_get_error - obtain result code for SSL I/O operation SYNOPSIS #include openssl/ssl.h int SSL_get_error(SSL *ssl, int ret); DESCRIPTION SSL_get_error() returns a result code (suitable for the C "switch" statement) for a preceding call to SSL_connect(), SSL_accept(), SSL_read(), or SSL_write() on ssl. The value returned by that SSL I/O function must be passed to SSL_get_error() in parameter ret. In addition to ssl and ret, SSL_get_error() inspects the current thread's OpenSSL error queue. Thus, SSL_get_error() must be used in the same thread that performed the SSL I/O operation, and no other OpenSSL function calls should appear inbetween. The current thread's error queue must be empty before the SSL I/O operation is attempted, or SSL_get_error() will not work reliably. RETURN VALUES The following return values can currently occur: SSL_ERROR_NONE The SSL I/O operation completed. This result code is returned if and only if ret 0. SSL_ERROR_ZERO_RETURN The SSL connection has been closed. If the protocol version is SSL 3.0 or TLS 1.0, this result code is returned only if a closure alerts has occured in the protocol, i.e. if the connection has been closed cleanly. SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE The operation did not complete; the same SSL I/O function should be called again later. There will be protocol progress if, by then, the underlying BIO has data available for reading (if the result code is SSL_ERROR_WANT_READ) or allows writing data (SSL_ERROR_WANT_WRITE). For socket BIOs (e.g. when SSL_set_fd() was used) this means that select() or poll() on the underlying socket can be used to find out when the SSL I/O function should be retried. Caveat: Any SSL I/O function can lead to either of SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE, i.e. SSL_read() may want to write data and SSL_write() may want to read data. SSL_ERROR_WANT_X509_LOOKUP The operation did not complete because an application callback set by SSL_CTX_set_client_cert_cb() has asked to be called again. The SSL I/O function should be called again later. Details depend on the application. SSL_ERROR_SYSCALL Some I/O error occurred. The OpenSSL error queue may contain more information on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error: If ret == 0, an EOF was observed that violates the protocol. If ret == -1, the underlying BIO reported an I/O error. (For socket I/O on Unix systems, consult errno.) SSL_ERROR_SSL A failure in the SSL library occured, usually a protocol error. The OpenSSL error queue contains more information on the error. SEE ALSO ssl(3), err(3) HISTORY SSL_get_error() was added in SSLeay 0.8. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [Fwd: OCSP and CSL]
Dr Stephen Henson wrote: Massimiliano Pala wrote: I am forwarding this message to the openssl-dev list so as to ask for support in generating such CSLs (read on). Some chance in getting help to write the code ??? Actually the CRLs do not support extentions in OpenSSL, isn't it ?? Well it does support extensions but not IDP or deltaCRL. Rhe standard CRL generation utility 'ca' can't handle CRL entry extensions either. 'ca' probably isn't suited to the task and something like an option to the 'crl' program to allow a CRL to be generated from a config file would IMHO be the best way. This probably wont make it into 0.9.5 but maybe the next release... What I was thinking was about the signatures of the CRLs with that kind of extentions... can CRLs be signed by a certificate that is not the CA certificate (for their usage them can not be signed by the ca because it is not connected to the net...) ??? It could be useful to add this kind of CSLs to the Apache server to allow for suspension of certificates before issuing a new CRL is possible... What do you think ??? C'you, Massimiliano Pala ([EMAIL PROTECTED]) P.S.: Another question, probably OT (sorry), someone of you is going to the IETF 47th meeting ??? I've been asked to go there to partecipate to the workshops, although a decision is not taken yet, probably there are no funds :-( What's the story for the OpenSSL people (hope better than mine... ) ??? S/MIME Cryptographic Signature
