Hi Ryan, Thanks for the clarification. I've added a few issues that have occured to myself and Doug Floyd (operator of the dh-l mailing list) during several short discussions we've had over the last year. Forwarded message:

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

The problem reduces to one of distribution of public keys.

Agreed.

In my model (er, actually Lenny Foner's model, in this case), you distribute something that has intrinsic verifiability -- the eternity source.

If I understand this you mean to use the code itself as the key? So you require all the eternity servers to use the same source? Doesn't this imply at some point a single point of distribution and hence another point of attack?

So whether or not rdl's eternity-dds signing key is compromised is irrelevant to the users -- in fact, the assumption is that since I am a known target, I've been killed or compromised. So, there's this potentially untrusted code out there.

I am unclear as to what you mean by 'known target', are you refering to a particular eternity server, the eternity server code itself, the document the user is looking for, or the provider of the document? I suspect the provider of the document. Doesn't the fact that you can't address issues of key validity become an issue? How does this model handle key aging or do you propose to leave the same keys out there for extended periods of time (ie decades after your death)? Doesn't this extended lifetime represent a threat to the validity of the keys since it provides mallet an exceptional period of time in which to mount the attack? Especialy since nobody is checking the keys? It further seems to me that the main motive of most law enforcement is going to be going after the user of the data the majority of the time since this is much more time critical than knowing who provided the data. After all simply knowing who did the original sourcing is not enough to remove the problem after the fact. Eternity servers are after intended to be long lived mechanism, this provides the authorities much time to follow the data and analyze the network traffic. Wouldn't it be important to provide some sort of delivery mechanism that provides a full encryption envelope around the data until it is delivered to alice? I recognize this exacerbates instead of alleviates the key server security issues.

People who have known public keys then inspect and sign the code. It is assumed these people have distributed their public keys far and wide, signed by lots of people, etc. As long as you can assume the "PGP web of trust", the distributed software signing thing works.

Ah, ok. So we again are assuming everyone is using the same particular piece of technology. In this model, would it not add security to the mechanism to have the eternity server deliver the encryption software (ie PGP)? How does this model handle the physical contact that is required in the PGP web of trust? In particular how does it verify that the actual physical contact occured? Can you address the key distribution mechanism and how it addresses the issue of a mallet producing their own key server with their own keys signed sureptitiously by their own multiplicity of 'nyms? Do you see a group of 'Johny Appleseeds' roaming the country in person dropping little dolops of signed keys off? Or, do you believe some sort of key verification service will need to be generated that compares keys for individual 'nyms on the various servers and publishes a list of keys that don't match (something that would to my thinking be prime data for a data haven server). Doesn't such a 'trusted' service have the same sort of 'user end' threats as the eternity servers themselves? Assume for a moment that mallet wants to monitor a particular alice. Alice makes her request which goes through mallets tap. Outbound traffic is uneffected so that the actual keys sent to the server are good. However, no the return stroke mallet intercept the traffic, provides their own bogus keys and signed document. How do you see alice finding a way to recognize this? The threat with this model is that alice might be turned and therefore condemn any co-participants in whatever activity alice is supposed to be involved in (eg ingesting lettuce or leading a freedom cell in Burma)?

I agree that the current state of PGP use is probably not enough for the "PGP web of trust" -- I've *never* used a key and found it signed by anyone I know. However, I think even the current system puts a pretty high barrier to fraud, and if there started to be fraud, people would start signing each other's keys.

I agree with all the points but the last. When the cost becomes too high (ie inconvenient) they simply won't use it. I just can't seem to grasp why people would spend even more money (which would provide a flag via monitoring of funds) to physicaly meet a group of others who they probably don't know and therefore probably shouldn't trust at such a fundamental level.

A keyserver serving keys like "rdl's eternity-dds release signing key" might be subject to traffic analysis, true. However, as you suggest, you could put the keyserver inside Eternity. Then, the problem just gets shifted -- now you need (a) pgp signing key(s) which has/have signed all of those keys.

I believe it is a fundamental mistake to have the key server inside the eternity server, just as I object to anonymous remailers that provide such service. The key servers should be on different machines to provide physical independance & legal indipendance - these are long lived keys after all and there is no reason architecturaly to put the keys at threat if the data haven is at threat, and finaly technological indipendance - it should not require a upgrade of the eternity software (and visa versa) to upgrade the key server software. Another issue that was raised previously, neither I nor anyone else addressed it at the time, is this acceptance of latency of distribution. Since we are talking about providing potentialy damaging documents (to who is intentionaly left vague) doesn't this latency provide opportunities for attack? Unlike a remailer network where it defeats traffic analysis in the data haven model it seems like a perfect means to get the processing window to actualy mount a trace. Anyway, since I am still about 3-6 months from actualy implimenting any of my own Plan 9 based (network level anonymity) model this is all conjecture. Hope it provides at least a seed for something useful. Ta ta. ____________________________________________________________________ | | | 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 | |____________________________________________________________________|