From: Dale Thorn <dthorn@gte.net>
Date: Sun, 10 Nov 1996 09:49:31 -0800 (PST)
To: "William H. Geiger III" <whgiii@amaranth.com>
Subject: Re: Apology to Dale Thorn
In-Reply-To: <199611101830.MAA28727@mailhub.amaranth.com>
Message-ID: <32861563.994@gte.net>
MIME-Version: 1.0
Content-Type: text/plain


William H. Geiger III wrote:
> In <328523F4.3BC@gte.net>, on 11/09/96 at 04:38 PM,
>    Dale Thorn <dthorn@gte.net> said:

[snip]

> I am confused by Dale's repeated attacks on PGP without offering viable
> alternatives for a public-key encryption system.
> Sorry, I'll try to rember ot count to 10 before I post replies to the list. :)

I've made errors attributing stuff to wrong parties (oops, cringe).

And I apologize for not offering a viable alternative to PGP.

In another posting, I made a suggestion for making the source code to
PGP *really* public, i.e., in a form that the average programmer can
verify and edit (for personal use only, of course).

I'm tending to think that, instead of using PGP for all encoding (even
though it may have multiple facilities for all situations), a message
could be encrypted with a good trusted private-key system or whatever,
then the private key encrypted with the Public Key software and sent
either separately or with the message.

The above might be more cumbersome, but it could be automated with
messaging automation techniques. At least it would reduce the dependence
on PGP to encrypting only the private key(s), which would encourage using
PGP at its most secure (slowest) level of encryption for the entire process
of encrypting the private key data.  As an aside to OTP's, this would not
apply for obvious reasons, i.e., the length of the key.

Of course, this still requires validation of PGP in whatever portion of
the code would be required to encode the private key.  My recommendation
for really serious users would be to separate out that code and recompile
it separately from the remainder of PGP (for personal use only, of course).

And in case it got lost in my rhetoric, I do appreciate that there's no
substitute for the Public Key process.