Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
Andrew Cooke <[EMAIL PROTECTED]> writes: > > 1. The server's generation of its ephemeral DH key. > > 2. The server's DSA signature. > > 3. The client's generation of its ephemeral DH key. [snip] > I've dug out the nearest I can get to what made me think random numbers > were critical for DH key exchange and it's here: > http://remus.prakinf.tu-ilmenau.de/ssl-users/archive9809/0124.html - the > last quoted section (the main post is from me - I can't find the post I > was replying to). It's talking about two things (afaik) - is the first > (2) above? Yes, this is a serious worry. OTOH, if you managed to securely generate a private key, you must have had plenty of entropy around at the time. You can store this entropy (using OpenSSL's random seed file) and use it at signing time. Moroever, the random number for DSA signing (k) only has to be 20 bytes long. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
Nicolas Roumiantzeff wrote: > > Does anybody know why both IE and Netscape browser implement exclusively RSA > certificates? > My feeling is that Microsoft and Netscape both made a deal with RSA Security > to get a "low" price RSA license at the condition of not implementing DSA. As a matter of fact, Netscape does support DSA certs, but I never had a chance to implement DH key exchanges. The only reason I didn't implement it was lack of time. Every time we did schedules, I'd put it on the list; every time, it would get knocked off the bottom by something else. The bottom line is that there were no customers busting down our doors screaming that they needed DH, so we didn't do it. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming | __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
EKR wrote: > Andrew Cooke <[EMAIL PROTECTED]> writes: > > EKR wrote: > > > Andrew Cooke <[EMAIL PROTECTED]> writes: > > > > Nicolas Roumiantzeff wrote: > > > > > Does anybody know why both IE and Netscape browser implement exclusively RSA > > > > > certificates? > > > > I have no idea, but one reason might be the need for good random number > > > > seeds when doing DH key exchange. It is difficult to get 1K of random > > > > bytes without trusting your user to follow instructions (and presumably > > > > they want "idiot proof" software). > > > I don't think so. > > [...] > > > 2. 1024 bits of random data are more than enough to generate a strong > > > DH key. > > > > I seem to be having a hard time typing the right thing on this list. > > Yes, I meant bits - but I don't really see how this changes my argument. > > 1024 bits is a lot of bits. > Yes, it is, but as I said in the section of my message you > deleted, you need an equivalent number of random bits in order > to perform the RSA key exchange, so DH is no worse from this > perspective. I didn't mean to selectively edit anything - I thought there was a quantitative difference in the quality of random number needed for the two cases. > > On the other hand, I am involved in writing software for servers as well > > as clients and I *think* that it is the server side that is critical for > > random numbers with DH exchange (so this is not so serious for browsers > > acting as clients). If I recall correctly, you can expose the server's > > private key by simply using the same random number twice... > When you're doing DSS/DHE, there are three places where you > need random numbers (ignoring ServerRandom and ClientRandom): > 1. The server's generation of its ephemeral DH key. > 2. The server's DSA signature. > 3. The client's generation of its ephemeral DH key. > > If the server botches (2) then it can reveal its DSA private key. > Botching the random number generation for (1) and (2) simply > allows compromise of per-connection keys. I've dug out the nearest I can get to what made me think random numbers were critical for DH key exchange and it's here: http://remus.prakinf.tu-ilmenau.de/ssl-users/archive9809/0124.html - the last quoted section (the main post is from me - I can't find the post I was replying to). It's talking about two things (afaik) - is the first (2) above? Cheers, Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: RSA Security and Red Hat, Inc. Sign Licensing Agreement
>What does it take to make OpenSSL use a Chrysalis card? It took us a few weeks. :) But then, we don't use the PKCS#11 API directly, but instead go through our own C++ classes. US export regulations prevent me from offering any technical assistance on what would be an export-controlled product. :( Ask again in January, after the new US export regs have been issued, and the initial flurry of confusion has died down. /r$ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
Andrew Cooke <[EMAIL PROTECTED]> writes: > EKR wrote: > > Andrew Cooke <[EMAIL PROTECTED]> writes: > > > Nicolas Roumiantzeff wrote: > > > > Does anybody know why both IE and Netscape browser implement exclusively RSA > > > > certificates? > > > I have no idea, but one reason might be the need for good random number > > > seeds when doing DH key exchange. It is difficult to get 1K of random > > > bytes without trusting your user to follow instructions (and presumably > > > they want "idiot proof" software). > > I don't think so. > [...] > > 2. 1024 bits of random data are more than enough to generate a strong > > DH key. > > I seem to be having a hard time typing the right thing on this list. > Yes, I meant bits - but I don't really see how this changes my argument. > 1024 bits is a lot of bits. Yes, it is, but as I said in the section of my message you deleted, you need an equivalent number of random bits in order to perform the RSA key exchange, so DH is no worse from this perspective. > On the other hand, I am involved in writing software for servers as well > as clients and I *think* that it is the server side that is critical for > random numbers with DH exchange (so this is not so serious for browsers > acting as clients). If I recall correctly, you can expose the server's > private key by simply using the same random number twice... When you're doing DSS/DHE, there are three places where you need random numbers (ignoring ServerRandom and ClientRandom): 1. The server's generation of its ephemeral DH key. 2. The server's DSA signature. 3. The client's generation of its ephemeral DH key. If the server botches (2) then it can reveal its DSA private key. Botching the random number generation for (1) and (2) simply allows compromise of per-connection keys. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
Rich Salz wrote: > There is another option: use additional technology that has the proper > licenses, such as hardware crypto devices.For example, we use OpenSSL > but do all the RSA operations on a Chrysalis card. What does it take to make OpenSSL use a Chrysalis card? P.S. Found it at http://www.chrysalis-its.com/ -- Karsten Spang Senior Software Developer, Ph.D. Belle Systems A/S Tel.: +45 59 44 25 00 Fax.: +45 59 44 25 88 E-mail: [EMAIL PROTECTED] Web:http://www.bellesystems.com/ ..Defining the Future of IP Services... __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
Andrew Cooke <[EMAIL PROTECTED]> writes: > This isn't quite true - you can compile OpenSSL to be copyright free. You mean without the patented algrorithms, presumably? (i.e., "patent free" not "copyright free".) The code is still copyright, but the copyright looks pretty liberal (and wouldn't cover mere use of the software anyway). > However, as far as I know (and my knowledge is a bit out-of-date, so > this may have changed), this then leaves SSL with cipher suites > which are not supported by the common browsers. Yes, I think that's still true. DSA and things are mandatory for TLS-1.0, but browsers don't support them (or not very well, anyway) yet. (It'll probably be a while until the browsers support these things properly---probably after next September when it won't matter anyway.) -- Bruce Stephens [EMAIL PROTECTED] MessagingDirect(UK) Ltd http://www.MessagingDirect.com/> __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
Does anybody know why both IE and Netscape browser implement exclusively RSA certificates? My feeling is that Microsoft and Netscape both made a deal with RSA Security to get a "low" price RSA license at the condition of not implementing DSA. Nicolas Roumiantzeff. -Message d'origine- De : Andrew Cooke <[EMAIL PROTECTED]> À : [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date : mardi 30 novembre 1999 17:21 Objet : Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement >This isn't quite true - you can compile OpenSSL to be copyright free. >However, as far as I know (and my knowledge is a bit out-of-date, so >this may have changed), this then leaves SSL with cipher suites which >are not supported by the common browsers. So you can only write secure >applications that do not talk to browsers. But you can still use SSL, >if both ends of the connection have a comprehensive (ie OpenSSL) >implementation. > >Sorry if this repeats stuff - I've just re-subscribed to the list after >having not read it for a long time (since SSLeay, I guess). > >Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
This isn't quite true - you can compile OpenSSL to be copyright free.
However, as far as I know (and my knowledge is a bit out-of-date, so
this may have changed), this then leaves SSL with cipher suites which
are not supported by the common browsers. So you can only write secure
applications that do not talk to browsers. But you can still use SSL,
if both ends of the connection have a comprehensive (ie OpenSSL)
implementation.
Sorry if this repeats stuff - I've just re-subscribed to the list after
having not read it for a long time (since SSLeay, I guess).
Andrew
"Aaron D. Turner" wrote:
> After about 2 weeks worth of research (talking to this list, RSA,
> our lawyers, etc) I found that if your a company in the US, and you
> want SSL to talk to IE or Netscape, you have to either:
>
> - Break the law
>
> or
>
> - Buy a license from RSA (very expensive)
>
> or
>
> - Buy a commercial SSL implimentation (not cheap, but about 100 times
> cheaper than getting a license from RSA)
>
> Using only des/des3 won't work because you need a PK algorithm to
> exchange the des/des3 keys.
>
> --
> Aaron Turner[EMAIL PROTECTED] 650.237.0300 x252
> Security Engineer Vicinity Corp.
> Cell: 408-314-9874 Pager: 650-317-1821 http://www.vicinity.com
>
> On Wed, 24 Nov 1999, Tim Riker wrote:
>
> > OK, so what is a distributor to do? ;-)
> >
> > In short: Is it possible to build OpenSSL without and code that is
> > patent infringed, and still have it talk to Netscape and M$IE? What if I
> > did:
> >
> > ./Configure --prefix=/usr --openssldir=%{openssldir} linux-elf \
> > no-bf no-idea no-rc2 no-rc4 no-rc5 no-rsa no-sha
> >
> > to get just des/des3, is that enough? (the astute will notice that this
> > will not build, but hey) It should be ok to leave in blowfish, but
> > M$IE/Netscape do not have blowfish anyway right?
>
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing List[EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
After about 2 weeks worth of research (talking to this list, RSA,
our lawyers, etc) I found that if your a company in the US, and you
want SSL to talk to IE or Netscape, you have to either:
- Break the law
or
- Buy a license from RSA (very expensive)
or
- Buy a commercial SSL implimentation (not cheap, but about 100 times
cheaper than getting a license from RSA)
Using only des/des3 won't work because you need a PK algorithm to
exchange the des/des3 keys.
--
Aaron Turner[EMAIL PROTECTED] 650.237.0300 x252
Security Engineer Vicinity Corp.
Cell: 408-314-9874 Pager: 650-317-1821 http://www.vicinity.com
On Wed, 24 Nov 1999, Tim Riker wrote:
> OK, so what is a distributor to do? ;-)
>
> In short: Is it possible to build OpenSSL without and code that is
> patent infringed, and still have it talk to Netscape and M$IE? What if I
> did:
>
> ./Configure --prefix=/usr --openssldir=%{openssldir} linux-elf \
> no-bf no-idea no-rc2 no-rc4 no-rc5 no-rsa no-sha
>
> to get just des/des3, is that enough? (the astute will notice that this
> will not build, but hey) It should be ok to leave in blowfish, but
> M$IE/Netscape do not have blowfish anyway right?
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
OK, so what is a distributor to do? ;-)
In short: Is it possible to build OpenSSL without and code that is
patent infringed, and still have it talk to Netscape and M$IE? What if I
did:
./Configure --prefix=/usr --openssldir=%{openssldir} linux-elf \
no-bf no-idea no-rc2 no-rc4 no-rc5 no-rsa no-sha
to get just des/des3, is that enough? (the astute will notice that this
will not build, but hey) It should be ok to leave in blowfish, but
M$IE/Netscape do not have blowfish anyway right?
[EMAIL PROTECTED] wrote:
>
> Because if they used OpenSSL, they could be sued for huge tracts of cash by
> RSA for violating their patent. They _must_ license the patent from
> somebody.
>
> --
> Carson Gaspar -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
> http://www.cs.columbia.edu/~carson/home.html
> Queen Trapped in a Butch Body
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing List[EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
--
Tim Riker - http://rikers.org/ - short SIGs!
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
> "William" == William H Geiger <[EMAIL PROTECTED]> writes: William> I am rather confused as to why Red Hat would go with a closed, proprietary William> crypto library instead of going with OpenSSL, doesn't seem to be the Linux William> way. Because if they used OpenSSL, they could be sued for huge tracts of cash by RSA for violating their patent. They _must_ license the patent from somebody. -- Carson Gaspar -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cs.columbia.edu/~carson/home.html Queen Trapped in a Butch Body __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: RSA Security and Red Hat, Inc. Sign Licensing Agreement
Short answer no. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Ben Laurie > Sent: Saturday, November 13, 1999 8:29 AM > To: [EMAIL PROTECTED] > Subject: Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement > > > "William H. Geiger III" wrote: > > I am rather confused as to why Red Hat would go with a > closed, proprietary > > crypto library instead of going with OpenSSL, doesn't seem > to be the Linux > > way. > > Ah, but is Red Hat the Linux way? > > 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] > __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
If RedHat does this - well - there is Suse, Debian, etc. Also we can go with Apache/modssl and this is my prefered way anyway... either that or twaite. On Sat, 13 Nov 1999 15:32:18 -0600, William H. Geiger III wrote: >In <[EMAIL PROTECTED]>, on 11/13/99 > > at 10:47 AM, "Erik M. A. Kline" <[EMAIL PROTECTED]> said: > > >>> I am rather confused as to why Red Hat would go with a closed, proprietary >>> crypto library instead of going with OpenSSL, doesn't seem to be the Linux >>> way. > >> I think there are stringent, or at least greatly feared, legal issues >>surrounding the RSA patents here in the U.S. And since no browser >>actually uses the patent- or royalty- free crypto-suites in TLS, American >>companies are forced to deal with RSA. I don't think that RedHat should >>get the blame. They're probably just covering their butts. IMHO. > >Yes but those patents expire next year. It would be a shame if Red Hat >entered into some type of contract that extended their obligations to >RSADSI beyond this time. > > >-- >--- >William H. Geiger IIIhttp://www.openpgp.net >Geiger Consulting > >Data Security & Cryptology Consulting >Programming, Networking, Analysis > >PGP for OS/2: http://www.openpgp.net/pgp.html >--- > >__ >OpenSSL Project http://www.openssl.org >User Support Mailing List[EMAIL PROTECTED] >Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 13 Nov 1999, Ben Laurie wrote: > "William H. Geiger III" wrote: > > I am rather confused as to why Red Hat would go with a closed, > > proprietary crypto library instead of going with OpenSSL, doesn't > > seem to be the Linux way. > > Ah, but is Red Hat the Linux way? Very much so, they have released everything they have written under the GPL. Only the Debian people have a better record. There may be an exception in the case of their "Secure Web Server" product, but I believe that is to comply with the export laws and RSA licensing. Regards, Damien Miller - -- | "Bombay is 250ms from New York in the new world order" - Alan Cox | Damien Miller - http://www.mindrot.org/ | Email: [EMAIL PROTECTED] (home) -or- [EMAIL PROTECTED] (work) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4LexeormJ9RG1dI8RAhCnAKC90rf4ItHHP71UFqxaitLnRpczsgCg3Gfd H+iRe5k9DUlNIu7e+PY6QD4= =tw6m -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
In <[EMAIL PROTECTED]>, on 11/13/99 at 10:47 AM, "Erik M. A. Kline" <[EMAIL PROTECTED]> said: >> I am rather confused as to why Red Hat would go with a closed, proprietary >> crypto library instead of going with OpenSSL, doesn't seem to be the Linux >> way. > I think there are stringent, or at least greatly feared, legal issues >surrounding the RSA patents here in the U.S. And since no browser >actually uses the patent- or royalty- free crypto-suites in TLS, American >companies are forced to deal with RSA. I don't think that RedHat should >get the blame. They're probably just covering their butts. IMHO. Yes but those patents expire next year. It would be a shame if Red Hat entered into some type of contract that extended their obligations to RSADSI beyond this time. -- --- William H. Geiger IIIhttp://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html --- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
On Sat, Nov 13, 1999 at 08:45:07AM -0600, William H. Geiger III wrote: > Real-To: "William H. Geiger III" <[EMAIL PROTECTED]> > > In <[EMAIL PROTECTED]>, on 11/13/99 >at 12:19 PM, Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> > said: > > >gbroiles> It was my understanding that RHSS is BSAFE-based, which > >gbroiles> means the crypto libraries are likely slower than an gbroiles> > >SSLeay-derived implementation. > > >Uhmm... BSAFE SSL-C is, as far as I understand, SSLeay with a few > >changes... BSAFE and BSAFE SSL-C are not the same product; or at least they haven't been historically, though I've lost track of product renaming. Perhaps the old BSAFE libraries are being phased out in favor of the newer SSLeay-like code. In any event, when RHSS was released, and when Red Hat negotiated their first RSA license, BSAFE and SSLeay weren't at all the same, and OpenSSL didn't exist yet. > I am rather confused as to why Red Hat would go with a closed, proprietary > crypto library instead of going with OpenSSL, doesn't seem to be the Linux > way. Perhaps because they don't want to be sued for patent infringement? If Red Hat and RSAS want to work together, this allows Red Hat to outsource crypto (and crypto export law) expertise to RSAS, which is good business for both sides. If Red Hat doesn't want to work with RSAS in the future, this allows them to migrate their (Red Hat) code to an API that's (almost?) identical to OpenSSL, which should facilitate an easy replacement of the RSAS code with the open source alternative once the RSA patent expires, and thereby avoid paying royalties on the copyrighted code (which will continue to belong to RSA after the patent expiration). I haven't looked at RHSS in a long time (and no longer have access to a copy) but BSAFE libraries were generally distributed to RSA licensees in object-only format, so it's likely that RHSS is already using (and has been) a closed, proprietary crypto library; so a move to a non-open-source library with an open API is still a step in the right direction. -- Greg Broiles [EMAIL PROTECTED] PO Box 897 Oakland CA 94604 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Security and Red Hat, Inc. Sign Licensing Agreement
William H. Geiger III wrote: > > > I am rather confused as to why Red Hat would go with a closed, proprietary > crypto library instead of going with OpenSSL, doesn't seem to be the Linux > way. > Probably because in the US if you want to use RSA then you don't have any choice. Well at least until the patent expires... 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 User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
