[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: how to release code if the programmer is a target for (fwd)
Forwarded message:
> Subject: Re: how to release code if the programmer is a target for (fwd)
> From: Ryan Lackey <[email protected]>
> 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 |
| [email protected] |
| 512-451-7087 |
|____________________________________________________________________|