[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Sorry Ryan,

I'll need more context to answer this one. Would it be too much to ask for
more than a fragment of one sentence...:(

Forwarded message:

> Subject: Re: how to release code if the programmer is a target for coercion (fwd)
> From: Ryan Lackey <[email protected]>
> Date: 15 Jan 1998 01:41:01 -0500

> > man in the middle attack on people signing code
> How would you do this?  There is code.  You sign that code with your personal
> pgp key, which you are assumed to keep secure.  Cases:

I've probably sent out somewhere in the neighborhood of 40+ messages in the
last two days, several have related to signing documents in different
contexts. I don't recognize this particular fragment. Sorry, I don't
memorize my traffic nor do I keep archives of it and I'm way to lazy to
go searching the cypherpunks archives at 2am.

I'm assuming this has something to do with the eternity server/black_net
discussion that has been going on. So I'll take a stab at it, not that it
may make any sense in the actual context ...

 - You generate the code and sign it

 - You deliver the signed code to a data haven server of some architecture
   (note that you don't know where it is or who runs it, I'll assume you
    use some particular usenet newsgroup as your drop point)

 - Somebody else comes along and sees a list of available items and selects
   yours (again through a usenet based request mechanism).

 - They receive the code signed with 'your' key and decide they want to
   verify the signing (through yet another usenet channel).

The problem with this model is in the second step. What is to keep them
from removing your signatory, moding the code, and then resigning it. If the
recipient desides they want to check the sign they have two choices:

 - select an anonymous key that has been previously stored on some sort of
   key server.

   (if they are running a eternity server blind they could be running a
    key server blind as well, it follows that at least some of the
    users of your software wanting to verify the signing will go to this
    server and hence have corrupted code, if we're using the usenet model
    this is even more likely since they could be running a feed point for
    other usenet feeds downstream and hence capture many if not all requests
    for the product, especialy if they were the only server to actualy
    carry a copy.)

 - contact you the author directly (I'm assuming of course you were silly
   enough to put a publicly available key directly traceable to yourself
   on it in the first place) in which case they simply intercede from a
   upstream tap and verify their request in your behalf.

In either case there is no guarantee that what comes off the server is
what you the source put on there. Hence the long term security of the key
is compromised. In particular, in the second case, since they already know
who provided the illicit data to the server there motive is clearly to
track the users. This breaks the anonymity of the data haven.

Implicit in a workable data haven model is the goal of both source and sink
anonymity. This means that any signed data on the server must provide a
mechanism for the user to verify the sign by access to a suitable key to
generate the appropriate hash and compare it to the one that the server
delivered. If they match you should have the correct unadulterated document.

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