Forwarded message:

Subject: Re: how to release code if the programmer is a target for (fwd) From: Ryan Lackey <rdl@mit.edu> Date: 17 Jan 1998 19:07:10 -0500

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.

How are these fundamently different? Assume for a moment that as a user of an eternity server the source is the data I want.

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.

The point I am making is that whether the author is corrupt or not is irrelevant.

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

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. Where does this random user come from? What is '(thresh)'? What good would an anonymous key signature provide? You can't verify it within the web of trust model, that would imply the author wasn't anonymous which takes us back to the 'friends' attack. How do we know that some number of these cypherpunks aren't turned? Are you proposing that the user test all 100 of the signatures? Which realisticaly 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)

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

* 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?

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)

It isn't the key of the author or the eternity server that is under attack by Mallet. It is the security of the individual user who is under assault.

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.

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.

4) The user executes the compilation script.

[material describing script verification deleted] Mallet can re-write said script, especialy with the sorts of latency that the Eternity Server forces on the end user, such that it is consistent with the bogus keys the end-user gets. It is simply much easier to write scripts in a day than say 10 minutes.

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. 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. 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.

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. It is more expensive if Mallet can be forced to deal with two indipendenat operators then a single monolithic operator. [rest deleted] ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage@ssz.com | | 512-451-7087 | |____________________________________________________________________|