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