From: “Attila T. Hun” <attila@hun.org>
To: Adam Back <cypherpunks@cyberpass.net
Message Hash: cb9aad570a766b0d4ce7e5c1ec0a561149186d318121db01f877555e5abff169
Message ID: <19971016.032545.attila@hun.org>
Reply To: N/A
UTC Datetime: 1997-10-16 09:14:36 UTC
Raw Date: Thu, 16 Oct 1997 17:14:36 +0800
From: "Attila T. Hun" <attila@hun.org>
Date: Thu, 16 Oct 1997 17:14:36 +0800
To: Adam Back <cypherpunks@cyberpass.net
Subject: consensus on pgp? can we consolidate for action?
Message-ID: <19971016.032545.attila@hun.org>
MIME-Version: 1.0
Content-Type: text/plain
-----BEGIN PGP SIGNED MESSAGE-----
two of the things I was trying to do in my rant "GET WITH
IT" on the issues may not have been clear:
1. as Tim says, let's make sure the OpenPGP standard (which
in itself I did not address) is for PGP by itself, none
of the peripheral issues or means of implementing
GAK/CAK/CMR or the rest of the faloderol. now, if PGP,
under market pressure wishes to allow hooks for each of
the sins from the necessary to the unpardonable GAK
--that is a business decision.
2. as far as the proposed SNMP "enforcer" --that is also a
business consideration. however, the more PGP is
willing to listen to some of our voices of reason[1],
the more likely PGP is going to be in the rather
enviable position which at least permits companies to
make a choice.
[1] by and large, despite the polarity of the
arguments, this issue with PGP has been one of our
memorably sane and polite debates with so many
threads I may need to establish a separate text
retrievable database! and it involves one of our
most emotional issues: privacy.
the second point is critical to our interests as well as for
PGP's stand in the industry as a whole. if the SNMP enforcer
product is carefully designed, it can not only provide
warnings for each level of security but even more
importantly, it does not necessarily need to provide GAK
functionally in the standard product:
browsers use plugins --so why not security level
plugins for the "Bad Daddy" SNMP enforcer?
essentially, the SNMP is a network connected, ie-
communication system, supervisor to one or more "clients"
scattered anywhere in the network which recognizes Bad
Daddy. some of the PGP control functions are basic, but the
rest should go on plugin, each relating to a different level
of sin, forgivable to abominable.
likewise, the local PGP crypto engine should be built around
plugins. in this manner, anyone concerned with privacy can
easily check for the presence of the dirty little black
boxes, or hopefully PGP will display a panel of "features"
(if you can ever call invasion of absolute privacy that).
plugins today are a nobrainer.
personally, I would not be willing to endorse a system which
gives the SNMP Bad Daddy the ability to retrieve my secret
keys and PGP should permit holding my secret keys on a flop
of some type -in other words specify a separate location
for the secring which we can not do now unless we move the
rest of PGP environment (at least as far as I have read).
however, if I am stupid enough to put them in a network
accessible position for the superuser to scarf -- that's my
problem. for use on network machines, I have a c program
which is effectively a one time pad to make the ring
accessible for as short a time as possible. I was writing
a c code supervisor which took care of this task rather
neatly with an out of place checksum passwd for the pad
keys but have been sidetracked.
I think we have all pretty much agreed on the necessity of
separate signature, communication, and storage keys; Adam
Back convinced me rather quickly (I was using only a
separate storage key). there is less agreement on the
effectiveness of GAKing the communications key since some
form of DH session keys could be deployed and mail is
transient; eg: GAK only serves the Fed in this case, which,
of course, is what they want.
I have not seen any further discussion on my suggestion to
create a sendmail type daemon which implements DH between
mail clients. this, of course, is on the presumption that DH
is a wrapper for an already encrypted packet,
I also agree with Adam's design on isolating the recovery
aspect from possible GAK outreach. although I will cop a
plea to sometimes in the back and forth Adam was grasping
for something which was never going to be there <g>
bottom line: I think the consensus has already formed that
PGP is not going to be the pristine voice crying in the
wilderness we all hoped to hear; now the issue is, how can
we shape the product to have a) the most flexibility,
realizing full well there will be brain dead organizations
who will insist on ordering GAK; and b) have the fewest
potholes unknowingly enabling some level of pseudoGAK, etc.]
again, that means focusing the pressure on PGP to keep the
basic crypto engine pristine, and do the dirty work in Bad
Daddy --and use "visible" plugins.
I can only presume PGP 5.5 is a fair ways down the pipe to
delivery, complete with its Big Daddy SNMP enforcer; this
will make it all the harder to influence changes as PGP, Inc.
appears to have grown enough in size to contain too many
non-caring v/v real privacy (I have nothing to hide type
ignorance), and even more disappointing, not only technically
ignorant, but distrustful of technology bureaucrats that
arrive with corporate growth -focused on
a) closing off the design cycle;
b) stifling the debate over methods;
c) shipping product (oh, hell, we can listen to their
complaints and make changes later...); and,
d) recover the vulture capital investors money.
if the foregoing is true, I hope PRZ has the good sense to
take a walk, selling his stock (to do otherwise would be
complicit in the deception of PGP's reputation capital).
regardless of the above, if we as a group, with reasonable
consensus, are willing to make an assault on the powers that
be at PGP, Inc. including whatever relevant public publicity
to heat the fire, there may be action. hell, if we could
afford it (or Tim feels _real_ generous <g>), buy a NYTimes
page and all of us sign the "selling out our the constitution"
with cute little graphics of children being tortured for
their keys.
another point to consider: if a majority of cypherpunks as
a group are willing to "endorse" the pgp product, that may
be an issue worth discussing with pgp. the only problem
may be the level of the outside managers and bean counters
which hold down the front offices, totally ignorant of
anything but feeelthy money; or, more probable, some cp
subset who have been the primary contributors historically
on these issues, and I think most of us know who the primary
thinkers are on this issue are. obviously we must be fully
informed and our opinions assessed --even with divergences.
in the end, I would like to think decisions could be settled
by consensus, rather than Supreme Court style. <g>
if we (and I say this as: "who's this we...")....
despite the cynical contempt with which the mass media often
displays to our attitudes, even resorting to name calling,
reputation capital is not necessarily gained from main line
press popularity, and certainly not from government
"popularity" in this issue [particularly cogent to those of
us "fortunate" to have received the IRS spam]. FWIW
of course, I may be presumptuous PGP would even want to hear
from us, let alone have any form of "Cypherpunks Inside"
(yuk) label on the box! particularly with the round robin
multi-teaming of the sleepless Jon Callas.
this has been an attila rant...
attila, out, one more time....
and: it aint over 'til the fat lady sings, vahalla burning!
"attila" sig: 1024/C20B6905/23D0 FA7F 6A8F 6066 BCAF AE56 98C0 D7B0
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
Comment: No safety this side of the grave. Never was; never will be
iQCVAwUBNEXXkb04kQrCC2kFAQHD1wQAiAMt4qP+GX0SXpF9XSuWbJc38tBWFD+U
ErAn5iAhrWkzl1/HpkmxDb8qUS9fh1fTsUjTihTOCSU8RwvtkBuzkhMm02MXxxyK
eJndaYgdpt+pluGYfrDIj9Vd3QDQVlJ0gf+o+CQ+pwQUJxYjmI/oELb0jBDnOwek
EUl1MAszW90=
=EulT
-----END PGP SIGNATURE-----
Return to October 1997
Return to “Lucky Green <shamrock@cypherpunks.to>”