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>