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

[Jim Choate <ravage@ssz.com>]

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