Re: PGP, Inc.

[Raph Levien <raph@cs.berkeley.edu>]

Timothy C. May wrote:
> 
> (I've been missing some e-mail, for various reasons, including a 20 MB
> mailbomb from some German critic of my views, but I think I would've seen
> this discussed more than I have.)
> 
> Phil Zimmermann is apparently forming a Bay Area company, to be known as
> PGP Inc., with venture funding from one of the Seybold clan, according to
> an article by Simson Garfinkel in today's SJMN. (Which says the
> announcement was actually made last Tuesday....)
> 
> Jonathan Seybold, Dan Lynch (a founder of Cybercash), Tom Steding
> (ex-Novell) are some of the names involved. Initial products will include
> PGP and PGPfone.
> 
> No mention of programmers, jobs available, etc., except that they "will
> begin hiring shortly."
> 
> And the connection with ViaCrypt and RSADSI seems unclear to me.

   I doubt that the new company will have any connection with ViaCrypt.
It's been well known for quite some time that relations between Phil
Zimmermann and ViaCrypt have been, well, strained. I have no idea about
RSADSI.

> Anybody else have any more information?
> 
> If this whole thing is a spoof, it made it into the SJMN.

   Word of this has been buzzing for a few months. I first heard about
it at Sandy's party, for instance, and then there was that (somewhat
distorted) Usenet post by Vesselin Bontchev.

   Having a PGP Inc. could be either fantastic or a disaster. Phil has
shown remarkably bad business judgement in the past, so hopefully they
have installed real managers and will allow Phil to take a figurehead
role, which is one thing he's fairly good at.

   The main problem with PGP has been that there just haven't been
enough people working on it. The PGP development process isn't very
conducive to volunteers, either. I know I'm not the only one who joined
the team, enthusiastic to get 3.0 off the ground, only to leave shortly
thereafter, frustrated by lack of progress, lack of clear direction, and
a design that was growing increasingly more complex without solving some
of the most basic problems for users.
   Since Derek has joined the team, things are a little better, although
I still feel that there just isn't enough humanpower on the team. An
influx of money may very well change that. Let's hope so.

   Meanwhile, the biggest threat against PGP is S/MIME. In the time that
the PGP team farted around trying to define an API for 3.0, the S/MIME
people (starting more or less from scratch), came up with a new message
format, significant improvements to the X.509 certification hierarchy,
got major support from many, many vendors, and got the damn thing
implemented. S/MIME products will begin shipping early this summer.

   Recently, I've been spending more or less equal amounts of time in
the PGP and S/MIME worlds. The difference is startling. S/MIME gives the
impression that it's _happening._ From PGP, I mostly get the message,
"wait for 3.0, when that comes out it will solve your problems."
   The corporate world must feel this just as intensely as I do. For a
typical example of PR journalism that nonetheless captures the feelings
of the people in corporations who are actually deploying crypto, see:

      http://www.deming.com/press/cw040896.htm

   The final paragraph reads:

   "Observers say SMIME's capabilities will let it replace software
   based on the PGP code, which is widely used. Unlike SMIME, which uses
   a structured certificate heirarchy, PGP relies on pre-certification
   of clients and servers for authentication, a limitation SMIME doesn't
   face."

   The gravest weakness of S/MIME, on the other hand, is the fact that
it defaults to 40-bit encryption, without any way of automatically
upgrading the quality. I estimate that this will result in a few percent
of all S/MIME messages being encyrpted with anything better. This
estimate is based on deployment figures from SSL. For example, Sameer
Parekh determined that 94.5% percent of the accesses to his SSL-enabled
Web server used 40-bit encryption. There are two reasons to believe that
S/MIME will do even worse. First, SSL _does_ have an automatic
negotiation mechanism to select the best cipher, which S/MIME lacks.
Second, most SSL servers deployed are configured for 128-bit ciphers,
thus it is only necessary that one client has 128-bit encryption for
that to be selected. However, for S/MIME, both the sender's and the
receiver's clients must have 128-bit encryption. If _either_ one is
"export grade", then 40-bits must be used.
   Thus, it's a reasonable guess that almost all S/MIME messages that
pass through the wires will offer "virtually no protection," to quote a
phrase from a paper co-authored by the principal designer of S/MIME's
encryption algorithms
(http://www.bsa.org/policy/encryption/cryptographers.html).

   Best of luck for PGP Inc.

Raph