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

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

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

hallam@w3.org writes:

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