ratak (Jason E.J. Manaigre) wrote:

-----BEGIN PGP SIGNED MESSAGE-----

Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit

To: jubois@netcom.com, cypherpunks@toad.com Date: Wed Oct 09 10:19:39 1996 t:

...

- S/MIME and PGP are the two leading candidates for encrypting EDI messages, S/MIME inside the US, and PGP outside the US where S/MIME is unavailable.

How far along has S/Mime come now, can they offer the same key sizes as PGP...?

S/MIME has come a _long_ way. An earlier version (now called S/MIME 1.0, although I'm not sure this is going to make it into any marketing materials) had a couple of cryptographic problems compared with PGP. Those problems have been fixed in version 2.0, which is expected shortly (as an internet draft). S/MIME 2.0 _defaults_ to 168-bit triple-DES, unless you're stupid enough to use the export version. RSA key sizes up to 2048 bits are supported, as are a number of alternate symmetric algorithms. In addition, digital signatures are based on 160-biy SHA1, rather than 128-bit MD5, which is half broken anyway. In the meantime, Deming software is shipping a slick Windows implementation of S/MIME, which integrates nicely with Eudora. Netscape is expected to ship cross-platform S/MIME capability in version 4.0 of Navigator (their original publicity materials were only off by a factor of two ;-), and that will make a huge dent in the market. In sum, S/MIME leaves PGP in the dust, both techically and as a market force. There's still a lot of sentiment that PGP is one of "ours" and S/MIME is one of theirs, but at this point it's the latter that has the most promise of bringing encrypted e-mail to the masses. If only X.509 weren't so darned ugly :-) Raph

Andrew Loewenstern wrote:

Raph Levien writes:

...

In sum, S/MIME leaves PGP in the dust, both techically and as a market force.

But does S/MIME still leave important sender and recipient information in the clear?

No. That's fixed.

True, PGP is four years old and isn't as up-to-date anymore, but PGP 3.0 is supposed to have an important feature (although we will have to wait a year for it): it is unencumbered by patents.

I'll believe in PGP 3.0 when I see it. Last time I checked in with the development process, it was in pretty bad shape. Hopefully, the roughly $5M of capitalization for PGP Inc. will help, but then again, when's the last time an infusion of funds fixed a troubled software project? In their present forms, PGP and S/MIME don't differ much in terms of patents. At the _protocol_ level, both PGP and S/MIME require the use of RSA cryptography, which is patented in the US. Similarly, at the implementation level, both PGP 2.6.2 and RIPEM 3.0 (now in beta) have a license to use RSAREF for noncommercial applications. If you want to use RSA for commercial use in the US, you either have to buy ViaCrypt PGP (whatever that's called now), or one of the commercial S/MIME implementations. In either case, you're still paying for an RSA license. Actually, the situation with PGP is even worse, as it includes the IDEA cipher, which is patented by Ascom Tech. Ascom holds patents outside the US, which means that commercial users of PGP outside the US must pay an additional patent royalty to use PGP (US$15 per user for single copies -- see Stale Schumacher's PGP FAQ for more details). By contrast, the only patented algorithm required by the S/MIME protocol spec is RSA, which is patent-free outside the US. On 20 Sep 2000, S/MIME will become completely patent-free all over the world. S/MIME also requires the use of RC2, which is not patented, although RSA may assert rights under trade secret law. This is still a bit controversial, and the issue of inclusion of RC2 in RIPEM has not been fully resolved yet. However, RSA has indicated a willingness to allow at least object code for RC2 to be released as part of the RIPEM distribution. The RC2 algorithm is only for compatibility with crippled "export" implemenations of S/MIME, and can be omitted if you're only ocmmunicating with non-crippled clients. (It should be noted that such a version would not be in compliance with the S/MIME implementation guide). I think you're referring to the possibility that PGP 3.0 may use a public key algorithm other than RSA. However, if this is the case, it won't be compatible with PGP's installed base. In addition, I don't believe that there has been a public key encryption algorithm proposed which is free of patent controversy. Raph

On Thu, 10 Oct 1996, Raph Levien wrote:

I think you're referring to the possibility that PGP 3.0 may use a public key algorithm other than RSA. However, if this is the case, it won't be compatible with PGP's installed base. In addition, I don't believe that there has been a public key encryption algorithm proposed which is free of patent controversy.

In about a year, ElGamal will be free from any patent burden. I have talked with leading users of RSA who believe that the savings by switching from RSA to ElGamal may be a powerful incentive for doing so. However, the general feeling is that somebody, not said corporations, would have to first set up an infrastructure that uses ElGamal. A chicken and egg problem? Or another Cypherpunks project? --Lucky, who'd really would like to see ElGamal in wider use.