Reply From: William T Wilson <fluffy@dunadan.com>
> > in any significant way. If your are doing bank to bank transfers, you
> > simply move the digital coins to the other end, making sure you delete
> > them out of your vault. Otherwise you could have 2 different
...
> There's a problem with this, though. Electronic coinage can be copied
> directly as a series of bytes. Physical coinage includes the defense
This, to put it bluntly, doesn't work. :) You can copy the coinage as a
series of bytes, but you still can't spend it. It is similar to signing
an email with a PGP signature. You can copy my PGP signature but that
doesn't allow you to forge email from me, because the signature is
dependent both on the content of the message and my private key. You can
copy the signature, but it's valid only for that particular message.
For a real world analogy, I can take a picture of your money, but I can't
spend the picture. :)
There are a number of issues involved with the use of electronic "coins."
However, here is a brief (and imperfect, but illustrative) example:
I have money in a bank. Suppose I want to spend some. I construct a
message telling the bank how much money I want to spend and where I want
to spend it. I stamp this message with my digital signature, then encrypt
it with the bank's public key. I send it to the bank, who decrypts it,
verifies my signature, and deducts the money from my account.
The bank issues me a digital coin, encrypted with their own public key,
then they add information to tell the merchant how much the coin is worth,
and they encrypt it again with the merchant's public key. I spend this
digital coin, which is unique, at some merchant, by simply giving it to
him. The merchant decrypts it with his private key and verifies it is the
right amount, then he "stamps" the coin with his digital signature and
sends it to the bank. Then the bank validates the stamp and credits the
merchant's account. You can't duplicate the coin as it goes over the
network because it's encrypted with the merchant's public key; no one but
the merchant I'm paying would be able to make sense of it. Similarly, I
can't try to spend this coin somewhere else, again because the second
merchant would not be able to decrypt it. You could copy the encrypted
coin and try to spend it again at this merchant, but this merchant will
know that he's seen this coin before, and he better not accept it.
There are two problems with this system. First, it is bad for privacy;
unlike regular cash, it's traceable. If you give me physical cash, I
don't need to know who you are, and the bank doesn't need to know you
spent this money. There are ways around this, but my example doesn't
cover them. Second, it does require the consumer to contact the bank
before spending the money. However, I'm not aware of any system which
allows for 1) no need to contact the bank, 2) is immediately verifiable
and 3) is immune to duplication. You get to pick two. :) As an
advantage, however, the merchant doesn't need to contact the bank when he
accepts the money; the consumer needs to contact the bank, but only when
he spends it. He can cash in his coins whenever he wants to.
-o-
Subscribe: mail majordomo@sekurity.org with "subscribe isn".
Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]
Received on Mon Jul 6 08:16:40 1998