1996-01-22 - Re: DigiCash Ecash - 2 security topics

Header Data

From: shamrock@netcom.com (Lucky Green)
To: bryce@colorado.edu
Message Hash: 45b0992777eef068afb94d850759b7bf2c2f6feb11442654ff9bd7ebb464f04c
Message ID: <v02120d05ad29aca26002@[192.0.2.1]>
Reply To: N/A
UTC Datetime: 1996-01-22 21:18:39 UTC
Raw Date: Mon, 22 Jan 96 13:18:39 PST

Raw message

From: shamrock@netcom.com (Lucky Green)
Date: Mon, 22 Jan 96 13:18:39 PST
To: bryce@colorado.edu
Subject: Re: DigiCash Ecash - 2 security topics
Message-ID: <v02120d05ad29aca26002@[192.0.2.1]>
MIME-Version: 1.0
Content-Type: text/plain


At 11:26 1/22/96, Bryce wrote:

>What kind of performance hit does this new encryption entail?
>(No additional performance hit if SSL does it, I know.)

Very little.

>Are you considering having different protocols for SSL-protected
>transactions versus unprotected ones?

It isn't just an issue of SSL vs. unprotected. The new Ecash API that
DigiCash is jointly designing with developers, will support two basic
levels of operation. The first is similar to today's Ecash software. The
client handles the transport. The second just generates the messages. Your
application is responsible for getting them to where they should go.
Presumably securely.

>Let me repeat something I said a couple of weeks ago:  I suspect
>that the weakest point in DigiCash security is on the end-user's
>own harddrive.  A malicious cracker could write a Trojan horse
>or even a virus which would steal the user's coins and send them
>to himself.

Given the amounts likely to be found on a drive, I doubt it would be worth
the effort.


-- Lucky Green <mailto:shamrock@netcom.com>
   PGP encrypted mail preferred.







Thread