Re: How to make a connection & win32 mingw32 port
>I've just succeded in compiling the libcrypto.a and libssl.a in >openssl-0.9.1c using the GNU egcs compiler on Windows NT (mingw32). I >want to use this to fetch https webpages. > >I looked through the demos to find one that could help me get started. >I found demos/ssl/cli.cpp, which seemed to do something like what I >want. The problem is that it isn't up to date. The first thing it does >is > > SSL_load_error_strings(); > ctx = SSL_CTX_new (); > CHK_NULL(ctx); > >which generates an error as SSL_CTX_new() wants a method argument. I >then changed the code into > > SSL_load_error_strings(); > meth = SSLv23_method(); > ctx = SSL_CTX_new (meth); > CHK_NULL(ctx); > >which compiles fine, but SSL_CTX_new() always returns null. The demos/ssl/cli.cpp can complies with ssleay_0.6.6 The reason is that the SSL_CTX_new() have changed in the new version of ssleay/openssl. You can say the cli.cpp is very old, maybe someone should write a new version of cli.cpp which can complies with the new version of ssleay/openssl(0.9.0 or above). And you should have a look at s_client.c in "apps" path. s_client.c can complie with new version of ssleay/openssl. Best wish, Wu Hui __ Get Your Private, Free Email at http://www.hotmail.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and Mac OS and export fun
Lutz Jaenicke wrote: > > On Fri, Nov 19, 1999 at 10:07:28AM +, Ben Laurie wrote: > > Depends what you want to do. If you only want to do SSL, then just strip > > out the ciphersuites you don't want to allow. Note that you'll have to > > enable the "new" ciphersuites to get 1024/56, and further note that they > > don't work properly coz they get ordered incorrectly in the negotiation > > - someone was working on that, but I've been megabusy lately and lost > > track of the status - where's that at? > > You should have it in your mailbox since Nov 11 :-) > I can send you another copy if you cannot find it. Oops. Was it sent to the list? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Question about Browser Authenticity
Sorry for continuing this thread, but I just came across: http://www.securityfocus.com/templates/forum_message.html?forum=2&head=32&id =32 which includes the following description of a Linux crackin: "Readers should also note how although a key binary in the cracked machine had been modified, tripwire and an assortment of other booby traps failed to detect this had happened. Even a close-up manual inspection (comparing file contents with a trusted backup, playing with it's name) could not detect any odd behavior. This trick, and others equally spooky were achieved by clever manipulation of the OS's kernel code (dynamicly, through a module). " __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL usage liability.
> > >US is far away from OpenSSL, and will probably remain that way for > >some time, unless the US export law changes radically. > > > You mean next month (Dec 15, 1999). > U.S. law is not going to change radically on Dec. 15. There will still be a one time review of exported binaries. Exported source code will still be banned. Technical assistance will still be restricted. Not that I know anything in particular about the new regulations. This statement is simply infered by the Executive Branch's continued appeals in the Bernstein case which if the last ruling was allowed to stand would remove the government's prior restraint authority from computer source code. And its continued fight to prevent Congress from voting on any of the bills which would allow mass market software to be shipped without review. I am encouraged by Germany's grant for development of GNU software for personal key management. This action which the U.S. strongly disagrees with is only more likely to put pressure on the U.S. to cave into the development of open source crypto. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
API to Generate X.509 Certificate ...
Hi, I'm a final year Computer Science student. I'm trying to use openssl to generate X.509 certificate in my program, but I couldn't found any API to do so. Does openssl have any API for me to generate X.509 certificate in my C program? Thanks. Angus Lee <[EMAIL PROTECTED]> -- _ Get Your FREE Email From : http://www.hkmail.com.hk Sign up and save your money NOW !! powered by OutBlaze __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Novice problem
Hi all, I'm very new of OpenSSL and also very new of everything concerning security and cryptography, so excuse me for everything (excuse also my English). I've installed OpenSSL 0.9.4 (Linux Slackware - kernel 2.2.12). I've created a new CA using the CA.sh shell provided in the misc dir. I've created a new request with the same shell (with -newreq option). I've signed it with -sign. Everything is okay till here. If I try to verify it I get: newcert.pem: /C=IT/ST=FI/L=FIRENZE/O=DADA [EMAIL PROTECTED] error 7 at 0 depth lookup:certificate signature failure The passphrase is (I'm sure) correct. I've tryed to cat newcert.pem after newreq.pem and viceversa. Is there someone who can address me to the right way? Thanks in advance, -- Cosimo Vagarini| CChheecckk yyoouurr dduupplleexx sswwiittcchh.. email: [EMAIL PROTECTED] | http://kyd.net/vaga| __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and Mac OS and export fun
Wilfredo Sanchez wrote: > > I need some help with making a US-export happy OpenSSL. > > So I had a phone call with the NSA here and asked them what I can > get away with. Note that the conversation was specific to Apple, and > not necessarily applicable to my fellow Americans, but I doubt that > we are suoer special. > > 56-bit DES is no problem. > 56-bit restricted RSA is no problem. 56-bit RSA? Surely not! Did you mean 1024 bit? > 3DES is not allowed. > In general, they seemed to imply 56 bits of anything is no > problem, but I'll have to double check that. Probably if there were > such as thing as 128-bit rot13 is would not be allowed. They seem > preoccupied with bits. I'm waiting on the actually approval to come > to my desk to be sure about this area; our lawyers have it. > > RSA patents aren't a problem for us. > > The plan is for OpenSSL to be a dynamic shared library. > Therefore, if you manage to get along of a stronger version and drop > it in, all binaries should be able to take advantage of the stronger > crypto. Yes, I brought this up in the phone call, and it's OK. It > must, however, be necessary to replace (or edit) the library binary > in order to enable stronger encryption. > > But I need to make OpenSSL comply with the above bit limits and > whatnot. Is this: > > a) Doable? Easy? How do I proceed? > b) Still going to give me a (moderately) useful SSL? Depends what you want to do. If you only want to do SSL, then just strip out the ciphersuites you don't want to allow. Note that you'll have to enable the "new" ciphersuites to get 1024/56, and further note that they don't work properly coz they get ordered incorrectly in the negotiation - someone was working on that, but I've been megabusy lately and lost track of the status - where's that at? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Certificate question
Paul Khavkine wrote: > > As far as i know RHat is still using SSLeay. > If it is it should work fine. Even if they weren't, a cert is a cert - the only thing that might give trouble is file formats. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL usage liability.
Nicolas Roumiantzeff wrote: > > >US is far away from OpenSSL, and will probably remain that way for > >some time, unless the US export law changes radically. > > You mean next month (Dec 15, 1999). No. The theory is that there will be no change for source export. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL usage liability.
>US is far away from OpenSSL, and will probably remain that way for >some time, unless the US export law changes radically. You mean next month (Dec 15, 1999). Nicolas Roumiantzeff. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and Mac OS and export fun
Fred wrote (talking about NSA): > 56-bit DES is no problem. > 56-bit restricted RSA is no problem. > 3DES is not allowed. > In general, they seemed to imply 56 bits of anything is no >problem, but I'll have to double check that. Probably if there were >such as thing as 128-bit rot13 is would not be allowed. They seem >preoccupied with bits. You seem to mean that 3DES is not harder to crack than any 56-bit encryption. I know that DES cipher texts have been been cracked but do you have example where 3DES was cracked? Nicolas Roumiantzeff. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
