At 07:17 PM 12/7/95 -0500, you wrote:
Assume the attacker is not doing any traffic analysis. The problem is that even then, the shop's identity (and product info, and payment amount, and bank ID, etc.) are still sent *in the clear* in the Digicash payment protocol. Thus all those items can be correlated to the payee's identity: a complete loss of privacy for the shop.
There's no need to send that payment info in the clear -- why not encrypt?
DigiCash agrees that it is desirable to encrypt the payment request. The problem is how? You can't use the payor's public key, since the payor is anonymous to the payee. There are other, high overhead, protocols that might be used, but after taking MIM into account, securing the payment request from within Ecash while retaining acceptable latency is much harder to acomplish than one might think. The best solution at this time seems to be to use the already existing https connection to transmit the payment request. The next version of Ecash will offer this feature as an option to the user. --Mark Twain Bank Ecash Support Ecash. The secure Internet payment system that protects your privacy. <http://www.marktwain.com/ecash.html>