From: Mark Twain Ecash Support <support@marktwain.com>
To: daw@delhi.CS.Berkeley.EDU (David A Wagner)
Message Hash: b3fad1dbf137d844fae70701e0a21daffde90345dbee6db85961b7a01abadc27
Message ID: <199512081825.MAA22557@admin.starnet.net>
Reply To: N/A
UTC Datetime: 1995-12-08 18:24:10 UTC
Raw Date: Fri, 8 Dec 95 10:24:10 PST
From: Mark Twain Ecash Support <support@marktwain.com>
Date: Fri, 8 Dec 95 10:24:10 PST
To: daw@delhi.CS.Berkeley.EDU (David A Wagner)
Subject: Re: Still more on the Digicash protocol
Message-ID: <199512081825.MAA22557@admin.starnet.net>
MIME-Version: 1.0
Content-Type: text/plain
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>
Return to December 1995
Return to “Mark Twain Ecash Support <support@marktwain.com>”
1995-12-08 (Fri, 8 Dec 95 10:24:10 PST) - Re: Still more on the Digicash protocol - Mark Twain Ecash Support <support@marktwain.com>