Re: End of HIT MEN thread

[Jeff Barber <jeffb@sware.com>]

Patrick J. May writes:

>      (I just want to see how long a thread with the subject "End of ...
> thread" can keep going.)

I admit, not a very good title with which to continue the thread.


> Jeff Barber writes:
>  > After considerable struggle, I have finally succeeded in coming up with
>  > a mechanism through which the hiring party and the murderer-for-hire
>  > can make a contract through the escrow service in such a way that the
>  > escrow service doesn't know that the contract is for murder.
> 
>      I'm interested in your solution.  Mine is to set up the escrow
> payment seperately from the verification.  The escrow agent would
> release the funds when instructed to do so by a specified verification
> agent.  This eliminates the risk of the escrow agent keeping the money
> without losing reputation.

I simply took it one step farther and did away with the need for
verification of a "hit" (of course it's replaced by a step which 
verifies the "death" but does not require that it appear to be a hit).
I did this by assuming into existence an on-line coroner's "clearinghouse"
to which ALL the coroners belong and to which all death certificates
are filed.  This way, no one other than the killer and the hiring party
need ever know that a hit has taken place.

If the clearinghouse provides an automated e-mail server (or functional
equivalent) which will answer the question "Is <named individual>
dead?" with a response message in a standard format and encrypted
with a key provided in the request, then the killer and the employer
can cooperate in the creation of a request packet and an "expected
response" packet.  In my scheme, another trusted agent is required
during the setup phase -- his only function is to ensure that the
employer doesn't cheat in the preparation of these packets.

Then, the employer simply gives the encrypted expected response packet
to the escrow service with instructions to pay the killer when he
can produce a copy of the packet.  The killer will only be able
to obtain this when the coroner's clearinghouse responds to a query
with the "victim is dead" response encrypted in the key prepared by
the employer.  This key is known only by the employer but was also used
in the preparation of the expected response packet.

So, the steps are:

1	Employer creates a key P (which he does *NOT* disclose to Killer).

2	The two now cooperate in a set of transactions with Trent using
	P and C (where C is the public key of the clearinghouse).

3	First, Killer provides plaintext of the request, plaintext of
	the expected response and the public key of the clearinghouse
	to Trent.

4	Then, Employer provides P, the plaintext of the expected response
	and the public key of the clearinghouse to Trent.

5	Trent verifies that both copies of the plaintext of the expected
	response and both copies of the public key are the same (so that
	neither of the parties can cheat the other).

6	Now, Trent takes the plaintext of the request, appends P and
	encrypts the results with the public key of the clearinghouse.
	This he gives to Killer (doesn't matter if Employer sees it too).

7	And, Trent takes the plaintext of the expected response, encrypts
	it with P and gives the result to Employer (only).  (He also 
	gives a hash of it to Killer so that Killer can verify that
	Employer gives the same packet to the escrow service below.)

8	Employer gives the encrypted expected-results packet (along with
	the money, etc.) to the Escrow service with the instructions
	that Killer can have the money when he produces an exact copy of
	the packet.

9	After verifying that the escrow service has the money, and
	that the hash of the packet held by the escrow service matches
	what Trent gave him, Killer whacks the victim.

10	Within a few days, the victim's death is is duly filed in the
	clearinghouse.  Now, Killer can send the encrypted request packet
	produced by Trent to the clearinghouse.

11	The clearinghouse uses its private key to decrypt the request
	producing the plaintext request along with a key (P) in which to
	encrypt the response.

12	Since the victim really is dead, the clearinghouse produces a
	plaintext equivalent to the original expected-response plaintext,
	then encrypts it with P, producing the magic cookie Killer needs
	to get his money.
	
13	The clearinghouse returns the results to Killer who forwards a
	copy to the escrow service along with his demand for the money.

14	The escrow service pays off -- end of contract.


Probably, this could be modified so that Trent doesn't need to see
the plaintext request and response, but I'd have to get out Schneier
and spend all night thinking about that.  Also, it doesn't seem that
important since the request and response are small snippets of text
that Trent operates on a hundred thousand times every day.  Furthermore,
all Trent can do is refuse to perform the transaction -- neither of
the parties to the contract will be out a dime if he won't.

>      I agree (please punch holes in my proposed scenario).  I don't
> know how to provide such a proof.  The hit verification agent will
> have to attend a lot of autopsies and funerals.

Avoiding this is the primary reason I have the coroner's association.
In essence, all that is needed is a trusted source of information about
the real world.  It could just be an ordinary general purpose information
retrieval service, except that it has to know about deaths of particular
individuals and I don't see any route other than the on-line coroner
for the information to make it into "cyberspace".

OK, now that that's done with...

Unless goaded into another response, I too will shut up about this thread.


-- Jeff