1997-10-08 - Re: What’s really in PGP 5.5?

Header Data

From: “Jim Russell” <jrussell@syncrypt.com>
To: <cypherpunks@cyberpass.net>
Message Hash: 661ed921832240e28e94992c3cd23c5bd99c4f942848631c64713da2563cbb0f
Message ID: <01bcd407$02595600$2901320a@Polaris.domain>
Reply To: N/A
UTC Datetime: 1997-10-08 16:54:31 UTC
Raw Date: Thu, 9 Oct 1997 00:54:31 +0800

Raw message

From: "Jim Russell" <jrussell@syncrypt.com>
Date: Thu, 9 Oct 1997 00:54:31 +0800
To: <cypherpunks@cyberpass.net>
Subject: Re: What's really in PGP 5.5?
Message-ID: <01bcd407$02595600$2901320a@Polaris.domain>
MIME-Version: 1.0
Content-Type: text/plain



The swirl of controversy that has arisen since the 2 Oct announcement of the
PGP Business Security Suite has been quite amazing.  Yet, all of the focus
has been on what's been *added* to PGP v5.5.  Jon Callas said it explicitly:

>>Corporate Message Recovery is included *only* in PGP for Business
Security.

What sense, then, can I make of the following?

I have been examining the published source code for PGP v5.0 for Personal
Privacy (note that this is *not* a corporate version), and have discovered
that this recovery scheme already appears to be in place, in some form at
least, in that version.

The following code appears in the published pgp.c, lines 518-537:

   /*
    * This is our version of "Commercial Key Escrow".
    *
    * A company can set the CompanyKey in the site-wide
    * configuration file and it will be added to the
    * recipient list for all encrypted messages.  Then
    * again, the user can override the setting in their
    * own pgp.cfg or on the command line.
    */
   companyKey = pgpenvGetString (env, PGPENV_COMPANYKEY,
            NULL, NULL);
   if (companyKey && *companyKey) {
    /* Add the company key to the recipient list */
    e = ringSetFilterSpec (ui_arg->arg.ringset,
             ringset,
             companyKey,
             PGP_PKUSE_ENCRYPT);
    if (e <= 0)
     exitUsage(e);
   }

This certainly *looks* like the implementation that is being discussed in
the press release, although I did not find it mentioned in any documentation
for PGP for Personal Privacy v5.0. The questions this code brings to my mind
are:

1.  Does this mean that even the Personal Privacy versions of PGP have a
message recovery scheme available?  The 2 Oct press release from PGP states
that the corporate message recovery "transparently integrates with *any*
version of PGP client software".  (Emphasis mine).

2.  If this is implemented via a configuration setting, does it provide an
opportunity for an attacker to reset the "CompanyKey" to their own key?  In
the Windows environment, it appears that PGP uses the System Registry to
hold configuration settings.  Is it possible for me to trick someone into
running a .REG script that will set the CompanyKey to a key to which I hold
the private component?

3.  This appears to me to be quite contradictory to the descriptions posted
by Jon Callas on 7 Oct.  The procedure that Jon describes, using an
attribute in the self-signature, would tell an encryptor external to The
Corporation to use the "skeleton key" on INCOMING mail.  The 5.0 code seems
to imply an automatic extra recipient on OUTGOING mail, and this impression
is reinforced by the description of the SMTP server policy enforcement in
the 2 Oct product description on PGP's web site.  (Let's not forget that
SMTP is a protocol for OUTGOING mail.) Which is it, or is it actually both?

Now, I realize that the long-time PGP users, the computer experts who can
take the source code and recompile the application, could simply remove any
sections they don't like, or go into the configuration settings and change
everything to their liking.  However, isn't encryption supposed to be moving
to a new target audience, the people who use a computer as a tool, and don't
necessarily know the internals? These are the people who need to feel secure
using encryption, and magic, invisible encryption to a third-party is
probably not going to give them warm fuzzy feelings.

Jim Russell <jrussell@syndata.com>
 Senior Engineer
 SynData Technologies, Inc.
 http://www.syndata.com







Thread