Re: ecash remailer
At 01:20 PM 11/1/95 -0500, Michael Froomkin <froomkin@law.miami.edu> wrote:
I thought a property of Chaumian DigiCash was that a coin *had* to go back to the bank before it could be spent again.
No. The basic Chaum Digicash method looks like this: 1) Alice creates a number of a recognizable form (Chaum's 1985 CACM paper uses n1n2n3...n64n1n2n3....n64, i.e. a 64-bit number concatenated with itself). 2) Alice blinds the number and sends it to the bank (along with some request for withdrawing money from her account or payment in other coin or whatever.) 3) The bank signs the number and sends it back. 4) Alice unblinds the coin; now it's good, recognizably signed, and untraceable. 5a) Alice gives the coin to Bob, who deposits it; the bank records the coin number, and in case of double-spending, the first person to the bank wins. This is useful for on-line transactions, or off-line where everyone trusts each other. OR 5b) Alice gives the coin to Bob using a complicated cut&choose protocol that doesn't give away her identity if it's only used once, but if she also gives the same coin to Carol with the same protocol, Bob and Carol can identify Alice with probability 1 - 1/2**n, for some adequately large n. This is more work, but you can use it for off-line transactions where you don't trust Alice not to double-spend. The protocol doesn't say what to do to Alice if you catch her cheating; depending on the environment you can debit her account or sue her etc. 6) Bob now has a number, signed by the Bank of Foo, which he can either give to them to deposit or get cash or use for highway toll (if Foo is really the highway company) or give to somebody else to spend (which is a little messy in the cut&choose method.)
Logically, I can see at least four possibilities: 1) payee data is encoded onto the coin at time of payment, making it impossible for Carol to bank the coin. I see no evidence of this in the docs at the Digicash site, but I just rechecked quickly and may have missed it.
The basic protocol doesn't say anything about what a valid coin looks like; you could use the example in Chaum's paper or a long string followed by a checksum or whatever. You _could_ put the payee's name account number in the string as the 64-bit "random" number, or even put both payer and payee. The bank could insist on that sort of thing if they wanted. If I remember right, the version in the Digicash trial left you the choice of filling in a specific payee or using "@" for bearer-payable coins.
2) No payee data as such is encoded on the coin but it is marked "spent" to prevent multiple uses by payee to the detriment of payor.
The bank marks the coin spent upon deposit.
3) the Digicash software only allows you to send a "spent" coin to the bank. You have to hack the software to send the coin to Carol (do you have to break your own key?).
I don't know if their merchant-client software lets you do this or not, but it's just a matter of implementation, not protocol.
4) nothing in the DigiCash software or protocol prevents you from sending a coin to Carol so long as you trust Carol not to get you in trouble by misusing the coin in some way. That's why Chaum is interested in hardware based agents that would keep you from respending coins you receive.
Your problem isn't trusting Carol not to get you in trouble, it's trusting Alice not to spend the coin again. Hardware-based agents are interesting because they make it easier to enforce double-spending prevention in off-line systems, and to offer better anonymity because you've got more trust that the person didn't double-spend. Stefan Brands has done a lot of work on this. In on-line systems you can check whether a coin's been spent already by depositing it - the problem is that on-line systems aren't always convenient for many applications (e.g. newspaper machines), and the costs of communication for an on-line system may be higher than the cost of a sufficiently smart smart-card. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---
On Nov 2, 7:23am, Hal wrote:
Subject: Re: ecash remailer It's very frustrating to have to speculate so much due to the lack of information. Imagine how we would react if Cybercash or Netscape had gone forward with what they claimed were secure protocols but had refused to publish them, referring simply to old papers on RSA and DES. Yet Digicash gets away with this.
So, refuse to buy their money. Demand open systems. If you feel like being more terroristic, get Markoff to write an article on how a cypherpunk expert feels that the Mark Twain Bankshares system 'may' be insecure. -r
So, refuse to buy their money. Demand open systems.
One problem a number of people have reported in DigiCash is disappearing money. Several people have reported that if a transfer is misconfigured the cash can flow out of the wallet, be rejected at the other end and disappear from the system - i.e. misprinted names on cheques mean lost cash! This is bad and they report that Digicash did not respond to their complaints. Phill
So, refuse to buy their money. Demand open systems. One problem a number of people have reported in DigiCash is disappearing money. Several people have reported that if a transfer is misconfigured the cash can flow out of the wallet, be rejected at the other end and disappear from the system - i.e. misprinted names on cheques mean lost cash! No. please get first hand facts. I have 'laundered' more than e$ 18000, by small amounts of a couple of e$, and *no* bucks were lost(1). I do have to manually cancel some and to refund ppl from time to time, and i must admit I'm a bit behind my mail answering about that... but
hallam@w3.org writes: the money is *not* lost [for everybody]
This is bad and they report that Digicash did not respond to their complaints.
They prolly addresses the complaints to the wrong ppl, money does not disapear as long as you keep the log files to be able to "cancel" 'lost' ebucks There are/were a couple of small problems with the ecash software, but no money is lost, as long as you have a consistent file system [and I think they are working on an "auto recovery/auto cancel" feature...] note that there are some problems, initially the proposed shop software sucked for instance... and writing a better one was a key to get the system better, maybe it is a bit too early for real bank also... I think some bugs are still hanging around... but the idea is great ! [i just wish to have sources/protocol fully disclosed before I put real money in it...] ps : I have no interest in digicash whatsoever except being partipant to the trial and having a small shop {and thus having an fairly large account ;-) I wish they give prices to 'good' shops ;-0)} note1: at least I think no bucks were lost... not a high percentage at least,... I did had some troubles with the first software version and managed to *almost* lost stuff, my mismanipulation... but hey... if your wallet has an hole, of if you throw away your money, you won't whine to the ATM, would you ? dl -- Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|... Freedom Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept cryptographic PLO Legion of Doom explosion Cocaine Castro Croatian
No. please get first hand facts. I have 'laundered' more than e$18000, by small amounts of a couple of e$, and *no* bucks were lost(1). I
I did, I got a direct report from a person who is extreemly well known in the field of computer networks and security. A second person who is well known in the UNIX and scurity areas reported the same problem. The fact that you can operate the system correctly does not mean that it does not have bugs. These people were looking to break the system.
but hey... if your wallet has an hole, of if you throw away your money, you won't whine to the ATM, would you ?
Yes, and I would win. Under regulation E of the Federal Reserve code my liability is limited to $50. The scenario you describe is analogous to my cash being stuck in the machine. This is the essential regulatory problem that e-cash faces. Regardless of the contract disclaimer it is by no means certain what liability Mark Twain have. The charges are significantly higher than those for credit cards, I see no validity in the argument that the small fees mean that a small liability should be incurred. Phill
It's very frustrating to have to speculate so much due to the lack of information. Imagine how we would react if Cybercash or Netscape had gone forward with what they claimed were secure protocols but had refused to publish them, referring simply to old papers on RSA and DES. Yet Digicash gets away with this. Bill Stewart <stewarts@ix.netcom.com> writes:
At 01:20 PM 11/1/95 -0500, Michael Froomkin <froomkin@law.miami.edu> wrote:
I thought a property of Chaumian DigiCash was that a coin *had* to go back to the bank before it could be spent again.
No. The basic Chaum Digicash method looks like this: 1) Alice creates a number of a recognizable form (Chaum's 1985 CACM paper uses n1n2n3...n64n1n2n3....n64, i.e. a 64-bit number concatenated with itself). 2) Alice blinds the number and sends it to the bank (along with some request for withdrawing money from her account or payment in other coin or whatever.) 3) The bank signs the number and sends it back. 4) Alice unblinds the coin; now it's good, recognizably signed, and untraceable.
We presume it works basically like this, but there could be elaborations. In particular, I have heard (from people who claim to know) that the payee is normally embedded into the coin at spending time.
Logically, I can see at least four possibilities: 1) payee data is encoded onto the coin at time of payment, making it impossible for Carol to bank the coin. I see no evidence of this in the docs at the Digicash site, but I just rechecked quickly and may have missed it.
The basic protocol doesn't say anything about what a valid coin looks like; you could use the example in Chaum's paper or a long string followed by a checksum or whatever. You _could_ put the payee's name account number in the string as the 64-bit "random" number, or even put both payer and payee. The bank could insist on that sort of thing if they wanted. If I remember right, the version in the Digicash trial left you the choice of filling in a specific payee or using "@" for bearer-payable coins.
Doing this would require the payee to be known at withdrawal time, which is not apparently how it works. I would speculate that actually what happens is that the "basic coin" as above is encrypted, along with the payee identity, all under the public key of the bank. This was the identity could not be stripped out by the payee or by a thief who snooped the transmission. Hal
participants (5)
-
Bill Stewart -
Hal -
hallam@w3.org -
Laurent Demailly -
rajaram@morgan.com