Slashdot Mirror

With X.509 it is allways crucial to have the root keys installed. And the Verisign ones are in the programs mentioned above. This minimizes the effort for the uninitiated.

It should not be so difficult to includet the PSE from Mozilla in s/w like Balsa, if they offer a generic way to manipulate the network connection before it is made.

But I allways had the impression that most coders in the free software arena prefer PGP, thus never took the time to write the code to support S/MIME and SSL.

The neccesary backend libraries are there (here for instance), but the integration and the GUI needed to make it happen in end-user software where never done. The good thing about the mozilla PSE is the fact that it has some concept of doing the GUI itself, only the integration has still to be done. If I only had more hours to the day B-)

Leknor

So encrypt it all. Everything. ALL traffic in and out of everywhere. What is really needed is a free public CA, who can sign ssl certs for people. Or, better yet, come up with a "web of trust" system and build support for it into the web browsers...then into everything else.

Anyone can sign their own certs, and be a CA. If you're using a Unix system (or similar) then you can build openssl without any commercial software without any trouble. If you're using Windows, then you might get GNU C to work, with or without cygwin. There are documents on how to get it working (If you build under Cygwin, for example, you must turn off threading.)

I personally sign my own certs. Sure, I'm not a trusted authority, but people who trust me, well, trust me. When my website comes up again, you will be able to access any page via either HTTP or HTTPS. I'll probably only do 56-bit to save me a little CPU time on my server, but it's still encrypted traffic.

I can't get there right now, so perhaps they're being hax0r3d even as we speak, but check out OpenSSL.org for more information. If you really and truly cannot get OpenSSL built on Windows NT, contact me for binaries. I *will not* provide you with source, so don't ask; I didn't modify their source in any way to produce my binaries, and you can download it from any OpenSSL mirror. If you don't like that, don't ask me for the binaries. And I will NOT be a source mirror.

Sorry for that little rant, but hey, you have to lay down the law or people walk all over you. And before you get all snitty about the law of the license, I'm not modifying source.

Is NSS based on OpenSSL? I read the web page and it isn't clear. Does the open source world really need yet another crypto library? OpenSSL has been around for several years now (although it was originally known as SSLeay, the eay for Eric A. Young, it's first and primary author). It's reasonably stable and secure. I believe that stronghold was originally based on a combination of Apache and SSLeay, although I can't offer any references to back that up. If the dependencies in debian can be trusted, then OpenSSH (in the form of libssl0.9) is used by OpenSSH, the ssl enabled telnet stuff, some apache stuff, and other stuff.

Is this another example of reinventing the wheel? I hope that "a new implementation of the RSA algorithm" is just another way of saying that they're not using the libraries from RSADSA as opposed to saying that they've written another (mozilla-free) version of something that already exists (apache-free) as open source. What would a new implementation provide that wasn't there before?

Can anyone think of a good reason not to use the OpenSSL libraries? I sure would like to avoid code duplication, especially when it's going to suck up RAM on my computer. Even more especially when it's something as tricky and specialized as crypto code. And what's the point of having shared, dynamically linked libraries when everyone goes and writes their own version.

Developers mailing list archive - http://www.mail-archive.com/openssl-dev@openssl.or g/
SSLeay doco - http://www.columbia.edu/~ariel/ssleay/
SSLeay FAQ - http://www2.psy.uq.edu.au/~ftp/Crypto/
Dr Stephen Henson's home page - http://www.drh-consultancy.demon.co.uk/ Agreed, some of it's pretty sparse. Join the developer mailing list and ask a few questions - www.openssl.org

Is ssh or apache ssl based on the RSA algorithm or the BSAFE software?

Well, OpenSSL and ModSSL are both based on SSLeay & both contain RSA algorithms. That's why it's recommended that if you're in the US and using OpenSSL, you disable RSA (and IDEA) ciphers during config. It's in the FAQ.

Is ssh or apache ssl based on the RSA algorithm or the BSAFE software?

Well, OpenSSL and ModSSL are both based on SSLeay & both contain RSA algorithms. That's why it's recommended that if you're in the US and using OpenSSL, you disable RSA (and IDEA) ciphers during config. It's in the FAQ.

It means we can all use OpenSSL without the rsaref library. The code is already out there.

ya need two things: openssl, and the Lynx SSL Patch.

XML is a bad choice for protocol messages. The use of XML carries far too much baggage for a lightweight/automated implementation.

Not necessarily. XML parsers have now been implemented that are as small as 1.5K of code. And Jabber doesn't use full-blown XML with DTDs, automatic validation, and all that; it uses it for the sole purpose of creating a structured data stream.

I've been thinking for some time about how a good Internet-wide IM system could be used not just to send silly chat messages back and forth, but also to be a method for client-server interaction.

The Jabber protocol would be excellent for this purpose. We are exploring such possibilities as embedding XML-RPC or SOAP messages in Jabber to promote client-server interaction over the same stream you might use for two-way human-to-human communication. The existing Info/Query mechanism in Jabber already does this, to a certain extent.

The XML message format requires each piece of software to contain an XML parser and also (from what I've seen) limits the kinds of data you can send back and forth. Why not do what HTTP does -- not care about the content, just specify a header format and let arbitrarily formatted data be attached?

XML parsers are readily available, and, as I mentioned above, can be quite small. As for percveived "limitations" on data types, any text-format data can be expressed as XML and sent through a message extension. For binary data, we use the jabber:x:oob (out-of-band data) extension to pass HTTP URIs for data retrieval, which keeps the data from having to be sent if the receiving client does not support binary attachments.

In addition, Jabber makes the unfortunate choice of not wanting anything to do with crypto on the protocol level; instead, it wants client folk to slap OpenPGP on top of it.

First of all, Jabber already supports SSL connections (via the OpenSSL library) for transparent transport-layer encryption. The only drawback here is that not many Jabber clients support SSL.

That being said, I would like to see Jabber support crypto at a level in between the transport layer (SSL) and the end-user level (OpenPGP). But it's not going to be supported until it can be done right, as it's my belief that poorly-done crypto support is worse than no crypto at all. And I might also point out that competing protocols either use no encryption, or use something that's a total joke in terms of real security (e.g., ICQ). Then, too, there are US export regulations to consider (and we have very few non-US developers at this point that could mount any sort of Jabber crypto effort).

Eric

The preceding was my opinion only, and not the official opinions of Jabber.com Inc. or The Jabber Project.
--

"Recently, VeriSign, the Apache Server Project, and SSLeay have collaborated to allow anyone running an Apache server to secure their site with the strongest encryption available"

There are two big libraries out and they are related: SSLeay and OpenSSL. OpenSSL is based on the SSLeay libraies, both are open source. SSLeay has been around for a number of years and I have heard glowing reviews. This was also the first Open Source encryption library ever to obtain Verisign certificates.

The fellow who made SSLeay (Eric Young) also has some stand-along libraries for encrypting buffers. I saw a Blowfish one for example.

One note: encryption is easy to do, hard to do right. For example, Word Perfect had an encryption feature broken awhile back. It was broken because a section of the data was always the same. To crack the file all the person had to do was do the math:

encrypted data - known data = key.

This is a number of years ago but that will happen over and over again if the programmer doesn't understand the concepts behind data encryption.

Just a plug: you might find Blowfish to be considerably faster than other algorithms. This is not because of simplicity but because the algorithm can take advantage of 32bit processors. It also does not have known weaknesses like DES nor patent restrictions like IDEA. Elliptical Curve is another worth looking into if you can't wait for the RSA patent to expire.

Ozwald

Oh, like OpenSSL? (-:

There are several issues here: peer review, architecture, algorithm and implementation.

Peer Review: At each step in the process (architecture, algorithm, and implementation), you should publish your ideas for criticism by experts. slashdot, Advogato, the Cypherpunks mailing list, sci.crypt, and the Crypto++ mailing list might (or might not) be good places to find such people.

Architecture: You should do a public key architecture where every participant has a public/private key pair and the public keys are used to sign and encrypt symmetric keys that are then used for encryption and authentication of messages. There are three feasible architectures for public key distribution. You have to choose one based upon your threat model. Almost all realistic threat models should be handled using the first option: "opportunistic public key distribution". If you don't have a threat model in mind at all then you might as well use the first option. If you do have a threat model which precludes using the first option then I'd like to hear about it -- you must be doing something very interesting indeed.

• Option one: "opportunistic public key distribution". The first time any pair of people talk to one another, they exchange public keys in an un-authenticated exchange. (Also: you could just do Diffie-Hellman key generation here.) After that, they remember each other's public keys for future use. This is susceptible to an active attack (a "Man In The Middle Attack"), during the first step (though not afterwards). However the cost to the attacker of executing a MITM attack is probably far more than the payoff. This depends on your threat model.
• Option two: make it the user's problem; Each user decides whether to use a given key to talk to another user or not. This is the user interface nightmare that single-handedly prevented strong crypto from becoming standard in e-mail, but for a few applications it might be the right thing.
• Option three: hardcoded; Generate key pairs yourself and include them in the application. For example if you are going to have a single central server in your system which you operate then you can generate a key pair for it, put the secret key on the server, and put a copy of the public key into each copy of the client (e.g. include the public key hardcoded into the client source code). This doesn't work as well if you want to distribute copies of your server for other people to operate, but refer to "Option one"...

Algorithm: You probably just want Triple-DES and RSA (after September of this year, when RSA becomes free of patents) or else Triple-DES and Diffie-Hellman. It should be easy to switch to a different symmetric cipher later after the new ones have been peer-reviewed and tried by fire, but for starters you want the old standbys that have already withstood the test of time. They will be fast enough for you at first and if you need more speed later you can switch.

Implementation: Your first choice should be to use an extant implementation. Don't try to implement it yourself no matter how simple it looks. Satan's Computer is deceptively subtle to people who are used to hacking Murphy's Computer.

I prefer Wei Dai's Crypto++ library, but that is because I'm doing complex non-standard crypto tricks. If you just want simple "encrypt/authenticate a stream" functionality then use a TLS implementation like OpenSSL. By the way, if anyone wants to make Python wrappers for Crypto++ (possibly with the aid of Swig) then I would love to hear about it!

Okay that's my advice. Specific pitfalls to avoid are: skipping peer-review, trying to design a generalized perfect public key architecture to handle all possible threat models, using a newfangled or non-standard algorithm ("In open source hackery, newfangled is good. In crypto, not."), and implementing it yourself instead of using a library.

Please direct all flames and accolades to: zooko@schowto.mad-scientist.com

www.openssl.org has an Open Source implementation of SSL. I think their latest version is 0.95.

Try Open SSL. The web site doesn't seem to be accessible at the moment, but the FTP site is. Good luck integrating it into Mozilla. :)

Try Open SSL. The web site doesn't seem to be accessible at the moment, but the FTP site is. Good luck integrating it into Mozilla. :)

First, Slashdotters should realize that key management is basically a harder, and more important, problem than the cryptography itself. More "secure systems" get broken because of bad key management than because the ciphers get cracked. A PKI module that can do good key management, and can get a decent user interface so that users don't screw it up, is worth more in the long term than access to the RSA algorithm.

That said, it sure sounds like this PKI is focussed on the nasty X.509 style PKI that's basically a support infrastructure for old style centralized security systems. Verisign, DoD, and so on. I'll be glad when PGP/GPG style web of trust gets direct support.

Second, there was some gnashing of teeth here that SSL won't be in Mozilla. Justly so. But hey, there's really no problem ... just don't confuse "SSL" with "RSA Encryption and Signatures". They really aren't the same ... even though with Verisign buying out Thawte (maybe), it looks like the main signer of non-RSA certs may have been co-opted. (Sigh; I really want freedom of choice for public key algorithms, particularly now that TWINKLE makes RSA look weaker and weaker.)

With the new US regulations, folk could incorporate a version of the OpenSSL toolkit, sans RSA support. (And at about 12:01am on September 20, check the RSA support into CVS.)

The patent-free flavors of SSL use algorithms much like those used by GPG. There is a public key signature algorithm (DSS/DSA), a key exchange algorithm (Diffie-Hellman), and various flavors of DES (and Triple-DES) for bulk data encryption. OpenSSL includes support for Blowfish (way faster) and other patent-free ciphers, as well as TLS (a somewhat more secure SSL that mandates patent-free encryption options; it's the IETF standard). There's a recent IETF draft showing how to incorporate OpenPGP keys and ciphers (such as CAST128) into TLS.

Third, please don't get hung up on RSA. Everyone's security will be better when there's a choice of public key algorithms for use in authentication and encryption. OpenPGP (such as GPG), SSL, and TLS can all be used just fine without anyone having to get a wedgie about RSA (or deal with their nasty lawyers -- give me a normal lawyer any day).

In short: there's a lot of good news here, and if you want it, this is sufficient to move a good SSL into Mozilla right away. Whatever you do, don't let the licensing agreements that Sun, Netscape, and so on have with RSA force you to hold off till you can use that particular public key algorithm.

Subject: Re: Security Advisory: Buffer overflow in RSAREF2
From: Niels Provos
Date: 1999-12-04 22:45:20

In message , Gerardo Richarte writes:

To make this clear: in combination with the buffer overflow in rsaglue.c this makes possible to get a remote shell on a machine running sshd AND it also makes possible to use a reverse exploit to gain access on clients' machines, using malicious sshd.

I fear that this posting should have been even clearer. To sum the problem up more clearly:

ssh-1.2.27 (if compiled with RSAREF2) is vulnerable. Attackers can obtain a shell on the machine running sshd. The exploit uses buffer overflows in the RSAREF2 implementation AND in the rsaglue.c file in ssh-1.2.27. I am surprised that there wasnt a bigger outrage on the mailing list about this, it is quite serious!!!

On the other hand, OpenSSH is not vulnerable to this remote exploit. Since rsaglue.c was rewritten, OpenSSH does stricter parameter checking than ssh-1.2.27 and these recent problems in ssh-1.2.27 did NOT affect OpenSSH.

Nonetheless, OpenSSH users in the USA that use OpenSSL compiled with RSAREF2 should update their ssl library (since isakmpd or httpd may be affected), see previous postings on Bugtraq, and http://www.openbsd.org/errata.html#sslUSA

Another thing is worth mentioning, RSA could use the buffer overflow in RSAREF2 to scan machines in the USA for RSA license violation. For example, sshds that do not use RSAREF2 do will behave differently than those that do.

Information on OpenSSH can be found at http://www.openssh.com/
Information on OpenSSL can be found at http://www.openssl.org/

This is actually not the case. SSL supports Diffie-Hellman key exchange as an alternative to RSA. Unfortunately, none of the major browsers implement DH, making this not very useful for web servers. OpenSSL does, however, support DH out of the box.

Sure there is. OpenSSL. It's just not usable in the US (at least for commercial use, and only if you use RSAREF), because of stupid software patents.

But next year, the patent *finally* goes away, and we should be able to use OpenSSL at long last.

Argh. Software patents suck!

--
Interested in XFMail? New XFMail home page

You can use an industry standard encryption and authentication protocol with FTP supported by various clients.

First, go to http://www.openssl.org/. OpenSSL is based on SSLeay and is the basis for open source SSL communications in unix. You'll want to grab openssl and compile it and install it. It provides a number of useful programs including md5 & sha for generating checksums on files and a whole suite of other cipher routines.

Next visit http://www.psy.uq.oz.au/~ftp/Crypto/ and go find an FTP server and client pair which have SSL support. There are also a few general proxy deals which can handle it with any standard FTP server.

Now there are a few ways to do authentication, you can do normal authentication or authentication based on certificate which requires a CA server (things like verisign will work if you want to shell out some cash, but you can also build your own CA).

The great thing about SSL is it can autodetect encryption support. So you can take a standard telnet server, make a few minor modifications to get it SSL capable and connect to it using SSL capable telnet client or a vanilla telnet client and it'll use the strongest security possible.

No need for silly third party daemons or special ports. Although the official TLS service ports are different from their unencrypted couterparts.

This is good if you are behind a corporate lan which doesn't like allowing anything besides telnet, ftp, and web traffic through their proxy.

--

I believe that IBM has released an opensource x.509v3 toolkit
(libraries and tools + some oscp stuff if I remember right) for unconditional use.
There was the usual export crapola so I have not been able to look at it myself.
I agree that this needs to be done!

It might be a good idea to do it in close cooperation (if not within) the
openssl project who have to deal with certificates anyway
and probably already have much of the code needed. Perhaps someone
from openssl reads slashdot and can say something about their
plans in the pki area.