Re: pgp, edi, s/mime

-----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...?




___________________________________________________________________
GarGoyle Securities
- -Intrusion Assessment Systems
- -Security Consultation/Education/Curriculum Development
- -Project Management/Research/Analysis World Wide...
- -Member of CITDC (Canadian International Trade Development Council)
- -Email: ratak@GargSec.mb.ca (Jason E.J. Manaigre)
- -Web:   www.GargSec.mb.ca
- -Email for PGP key with phrase 'Get Public Key' as Subject
- -2048 PGPKey iD E2 FA 30 E5 F5 AD EC F3  00 9A 9D 33 59 FC DF AD
___________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBMlvCj/qtmO8M92GRAQFNBAf8CVzTxtle7jvTQFq6UM9MpEGjvrnoSHoO
NMidciwyht0AqyGNPqNxczU/arpCAQwluwkhtTRor8lYsUWLLLyZB8d2DGs1i/En
3dE4WIXnNSR/G4YjHf8ln/DwE+YbHHFwEve5zSJAf4Gnvt7+LRo+VJPq34MaJgyc
5888BrSMHKTo5pyISAz+LQhDJptWMZwPsldrZctWI0QW/xgFMCmZr8qt2VYWdlZw
XO+Px+QadwvNJlL8pR2ZT3l458rzU5B7kS3CKVJDl0iUlVWK2/xHiuRUHfo1Yu1Z
VB6jFEw6IsQI8ukrANu90qgDcab3YQpe99BQCd/imZfKWSzO3vsieQ==
=Ew/I
-----END PGP SIGNATURE-----

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?

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.


andrew

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

> 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).

	An RC2-compatible cipher ships with SSLeay these days. Not a
problem.

-- 
Sameer Parekh					Voice:   510-986-8770
C2Net						FAX:     510-986-8777
The Internet Privacy Provider
http://www.c2.net/				sameer@c2.net

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.

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