Re: Still more on the Digicash protocol

[Mark Twain Ecash Support <support@marktwain.com>]

At 06:01 PM 12/6/95 -0500, you wrote:

>Hal has pointed out that payments & deposits with a wildcard in the
>payment_hdr should NOT be sent in the clear, since they can be stolen
>by any passive eavesdropper.

Let us contemplate in which type of situation the payee will send such a
wildcard coin. To pay a shop via TCP? No. The payment request comes in with
the shop ID. The resulting payment won't be done with a wildcard coin.

So when will the user pay with a wildcard coin? To make a payment to a party
that is (pseudo-) anonymous to the payor. That is, if the payor sends the
payment via anonymous remailer, in which case the messages should be
encrypted anyway.

[Why a remailed message should be encrypted is left as an exercise to the
reader.]

>Ian has pointed out the same problem with cancellations: the payer_code
>should NOT be sent in the clear, since any passive eavesdropper can
>grab this info and steal the corresponding payment.

As mentioned before, this will be fixed.


>Anyhow, the obvious solution is encryption.  Our new observation is
>that encrypting deposits & cancellations with the mint's public key
>is not enough to solve the problem.

[Argument in support of claim elided... I am not conviced.]

>While I'm ranting, let me also remind you of a problem Ian discovered
>earlier through reverse-engineering: the payment & deposit messages aren't
>encrypted,
[...]
>With traffic analysis, if payers use the default TCP connection, all
>this information about them can be compiled.  If I target a payer, I'll
>probably be able to record all his transactions (unless he's using
>remailers or pipenet).  If I sit outside a small business, I can compile
>a dossier on its buying habits.

One more time: this is only an issue if the payor is using a secure http
connection. Otherwise, you can gather all that information with out without
Ecash. The next release will use an already established SSL connection to
transmit this information, should the payor request it.

>Worse still, anonymity for the shop is worse with Digicash than with real
>cash.  If I pay you real cash on a secluded street, you're fairly anonymous.
>If I pay you Digicash over the Internet, any passive eavesdropper could be
>recording your identy and the whole transaction.  Blech.

This is raising an issue that has nothing to do with Ecash. The complaint is
in fact about the lack of a gereral link encryption on the Internet. I agree
that this is needed, but providing it really isn't Ecash's job. I am eagerly
anticipating the general use of IPSEC.

>  (Yes, this means shops will need to have certificates if you want
>  to avoid a man-in-the-middle attack.  So be it.  Most online shops
>  will be using SSL, and thus have a certificate anyhow.  You can safely
>  punt on the authentication between customer <-> shop if you're not
>  worried about active attacks.)

That's why the next version will use existing SSL, should the user so desire.

>* add a big warning to the documentation: users should not use wildcards
>  in payments (unless they know the dangers & are encrypting with e.g. PGP).

Will do.

>* continue specifying the protocol at a deeper level, like you promised
>  (and throw in source for security-critical modules too, eh? :-)

Writing all this down takes time. DigiCash may hire a tech writer soon. That
should improve communications between all parties.

--Lucky Green


--Mark Twain Bank Ecash Support
  Ecash. The secure Internet payment system that protects your privacy.
  <http://www.marktwain.com/ecash.html>