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

["Uhh...this is Joe [Randall Farmer]" <rfarmer@HiWAAY.net>]

[Choate said he wouldn't "address" my message if I didn't post it to the list,
so...]

> > Eternity delivers data.  It's up to the user to verify that the data is
> > what they want
> 
> > The original question was how to verify the eternity server source code.
> 
> Assume for a moment that as a user of an eternity server the source is the
> data I want.

Ok...

[...]
> > * 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.
> 
> Pretty expensive and rather unrealistic I suspect. 

The NYT ad? I think that was at least partly a joke (besides, if some
cypherpunks did take out an ad, I'd predict propaganda in 2/3 of the page and
fine-print PGP-key fingerprints in the rest :).

> Where does this random user come from? 

Why does it matter? As long as she's competent enough to choose good verifiers
and verify that those verifiers verified the code in question, it all works out
in the end. 

> What is '(thresh)'? What good would an anonymous key signature provide? 

Thresh is the number of signatures from trusted people/keys required to trust a
section of code, a value set by the user. An anonymous sig would be very little
good but I think he was talking about including the author's sig if he's not
anonymous. 

> [...] How do we know that some number of these cypherpunks aren't turned? 

We don't. There is no way to operate without *some* trust; this reduces it from
the code being shown to be secure if the author is not spookized AND The author
is capable to check his/her code AND the key he signed it with is good to the
code being good if those conditions are true for one (or a few) of the many
cypherpunks on the user's trusted list who signed the code. 
	
> Are you proposing that the user test all 100 of the signatures? 

Well, I think he's proposing to have a script check them and the user
personally make sure the script is doing what it should.

> Which realistica[l]ly is the only way to verify any given one of them. Not
> very many people will go to that extreme simply for grins and giggles.
> 
> > * 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)

Not to mention churning out that propaganda for the NYT ad, becoming tolerant
to pepper spray, preparing various fake identities for use, proving Blowfish
secure and then breaking it, constructing a doomsday weapon using only a
straightedge and compass, etc.

> 
> The standard is programs over ~10k lines is not comprehensible by a single
> individual on a line by line basis.

Might be, but this code has to be more than just understood -- it must be
painstakingly checked for subtle flaws and bugs. Welcome to the world of
adversarial quality control.

> 
> > * 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.
> 
> 'small compilation system' of what? What who wants it to do? The author?
> Mallet? The end user?

The C/Java/whatever compiler, I suppose, and also the signature checker, and
she's checking that they carry out their stated purposes.

...
> > 2) The user wants to run the code, because it's Just That Cool.
> 
> We're talking here about users who want to get data that is illegal or
> otherwise incriminating or dangerous to one group or another. In particular
> let's consider the situation of a Lebanese freedom fighter in Isreal or
> perhaps a 'Free Burma' revolutionary in China.

I think the issue was one of users who want to get eternity server source they
can trust -- not necessarily getting it *from* Eternity. 

> 
> > 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.
> 
> Which doesn't effect the ability of Mallet to resign that code at the users
> end in order to break the users local security.

Unless you're exposing a new weakness in the trust model PGP uses, Mallet can't
do that, providing the user has done good key authentication and hasn't listed
one of Mallet's goons as a trusted code-verifier.

> 
> > 4) The user executes the compilation script.
> 
> [material describing script verification deleted]
> 
> Mallet can re-write said script [...]

Yup, that's why the user has to check it by hand. Lots easier to check a script
and a compiler for doing their functions than to check an eternity server for
subtle bugs. 

> 
> > 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.
> 
> The end user may not have people available to trust is the point.

Well, if you can't verify it yourself and you can't trust other people to
verify it, my advice is to give up; you cannot be sure of *any* public keys in
that case, so any message you encrypt might be encrypted to one of Mallet's
keys; any sig you check might be signed by one of Mallet's keys.

> The reason the transport mechanism is relevant is that it is much easier to
> spoof a verification script if the user is not going to be surprised with 24
> hour turn around on requests, whereas a responce time measured in minutes
> lessens the window of opportunity to Mallet significantly. 

If Mallet is a NSA spook who's half as good as my hacker buddy Phat Atta and
knew about the script ahead of time, the user can't trust the script without
verifying it herself, whether it takes milliseconds or millenia to get the
response. 

> 
> It may come as a surprise to you and others but not everyone in the world
> can pick up a phone and call a 100 people all over the world and not raise
> some suspicion.

Ah, but either I am more mistaken than usual or you only need a few of the
signers to be trusted, not all of them. 

> 
> > Implementing a keyserver in Eternity has the same issues
> 
> While it is perfectly permissible to design Eternity or any data haven with
> inherent key servers, I believe it is a bad idea from a design perspective
> because it makes the code even larger, decreases the potential for monetary
> motives for indipendant key servers to appear, and if the server is
> compromised then the key server is also. 

Not sure, but I think he's talking about putting up a key server in Eternity
(i.e., the rolling hills where data can roam without fear, as opposed to
putting it in the Eternity). 

> It is more expensive if Mallet can be forced to deal with two [independent]
> operators then a single monolithic operator. 
> 
> [rest deleted]

---------------------------------------------------------------------------
Randall Farmer
    rfarmer@hiwaay.net
    http://hiwaay.net/~rfarmer