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