Re: how to release code if the programmer is a target for (fwd)

[Ryan Lackey <rdl@mit.edu>]

<daemon@ATHENA.MIT.EDU> (Jim Choate) writes:

> 
> That's all fine and dandy, however, we *are* talking about an eternity server
> architecture that delivers documents to an end user in a secure manner on
> demand with no mechanism, by design, to determine the original source. In
> this case there would by definition be *no* history to verify against.
> 
> It is in fact this lack of history from the users perspective that causes
> the authenticity problem in the first place. Further, a point that seems
> to have been forgotten, we are talking about signed and not encrypted
> documents. Of course there are some similar problems if we do include the
> encryption of the data itself into the protocol.

Eternity delivers data.  It's up to the user to verify that the data is
what they want, be it PGP signed by the pope, a working cryptosystem, or
whatever.  In this sense, it's no different than random email or whatever
as an untrusted transport medium.

The original question was how to verify the eternity server source code.

I assume the following:
* a potentially corrupted author (give rdl $100 000 and he'll probably
make a minor modification which has no apparent mal effects, give him
$100 000 000 and he'll be a hired gun).  The author is optionally 
anonymous.

* A community of publically-known cypherpunks and code-verifiers,
not all of which are corrupted, but some of which may be.

* A random user who has the public keys of at least (thresh) number of the
cypherpunks, optionally the key of the author of the document/product before
the system becomes questionable, perhaps by looking in the NY Times
for 1 Jan 1999 which has a full page ad taken out by Cypherpunks Anonymous
with the PGP public keys for the 100 leading cypherpunks.

* The piece of code to be verified is bloody long, that is, longer than
any one cypherpunk can afford to verify alone (shooting practice,
installing the minefields and poison gas sprinkler system, etc. take
lots of time)

* The user can tell by visual inspection that a small compilation
system does what they want it to do, and can understand basic logic
enough to tell what signatures imply.

Then:
1) The author releases the code into the network in an optionally 
anonymous way.  There is no reason to trust the code -- even if it
is signed with rdl's eternity dds signing key, no one has any reason
to believe that it isn't an NSA front, since rdl is assumed to be
corrupt, signing anything put in front of him (as long as sufficient
money is put there too)

2) The user wants to run the code, because it's Just That Cool.

3) No one can verify the entire code.  So, Cypherpunks begin signing
small sections of the code with their own previously-established key.
Their keys are established as their reputation is established on
the list, or perhaps by personally meeting these people, in the
traditional PGP web of trust scheme.  There is no central Cypherpunks
Registry, just a decentralized mesh.

4) The user executes the compilation script.  This script looks at the
pgp signatures, sees which ones it can verify from keys it already has
accepted as valid by (3), and, if there are verified good keys from
at least the minimum number of people in every critical section of the
code, it is added to the compile-me-source-tree.  If there are enough
people for every critical section (the user defines all aspects of
this), the source tree is set up for compilation, and compilation can
proceed.  The user knows that every piece of the code in the system
has been verified to their standards -- even if the author of the code
is an evil NSA sleeper agent, it has gotten by independent review by
at least a user-defined-number of people per section.


I fail to see how the specifics of Eternity are relevant -- it's
just basically a PGP web of trust issue.  The transport is irrelevant --
it's untrusted code until it's been verified by people the user
trusts.

Implementing a keyserver in Eternity has the same issues -- you still
need to deal with the PGP web of trust issues.  Signing my secret
alias key with my own key as the only signature and uploading it to
eternity would fail to provide privacy, just as it would if I posted
it anonymously to the mailing list.

One working system is the buildup of "reputation capital" by an identity
using the key.  Again, this is entirely irrelevant to the Eternity
server -- verifying document authenticity is better handled at the
client side.  Eternity should be set up so as long as your ecash is good,
your document is stored -- if I want to store my document under the
name "disney's greatest hits" when it really contains necrophilic
kiddie-porn and microsoft warez, that's my business.

The client software for interacting with Eternity, however, might do
well to have a good document authentication interface.  And perhaps
third-party authentication services could pop up, willing to sign
documents that just meet gross criteria for valid indexing.  You could
then download the key for that service somehow, then use the service
happily.

The abstract issue has been beaten to death on cypherpunks many times.
I just assert that Eternity is no different from "the Net", "the Web",
"remailer networks", "Blacknet", etc. in issues of document verification
and anonymous reputation capital.

-- 
Ryan Lackey
rdl@mit.edu
http://mit.edu/rdl/