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

Header Data

From: Bryce <wilcoxb@nagina.cs.colorado.edu>
To: “Marcel van der Peijl” <bigmac@digicash.com>
Message Hash: 2926f7281153d85e5cd4a33deee8dea04cdac2b5eee853b7b3125854a71cbad7
Message ID: <199601221826.LAA04610@nagina.cs.colorado.edu>
Reply To: <199601221635.RAA13080@digicash.com>
UTC Datetime: 1996-01-22 18:26:35 UTC
Raw Date: Mon, 22 Jan 96 10:26:35 PST

Raw message

From: Bryce <wilcoxb@nagina.cs.colorado.edu>
Date: Mon, 22 Jan 96 10:26:35 PST
To: "Marcel van der Peijl" <bigmac@digicash.com>
Subject: DigiCash Ecash - 2 security topics
In-Reply-To: <199601221635.RAA13080@digicash.com>
Message-ID: <199601221826.LAA04610@nagina.cs.colorado.edu>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

 An entity calling itself "Marcel van der Peijl"
 <bigmac@digicash.com> is alleged to have written:
> 
> 

(I wrote:)

> > E.g. has there been a DigiCash response to Ian Goldberg's
> > publication of a denial-of-service attack which operates by 
> > spending a coin with the same serial number as your victim's 
> > coin?
> After discussing things with Ian we came up with several solutions. 
> One is encrypting more messages (which we will do in a next revision 
> of the protocol), the other is enabling ecash to work over ssl 
> servers. You may not see the answer directly in the list, but you 
> will see it in the next protocol revision.


What kind of performance hit does this new encryption entail?
(No additional performance hit if SSL does it, I know.)
Are you considering having different protocols for SSL-protected
transactions versus unprotected ones?


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.


Hm.  Now that I think about it, if the user has a back-up copy
of those coins then he can reveal their blinding factors to the
bank after the theft, thus catching the thief!  So the thief
program would have to deposit those coins with the bank, make a
new withdrawal (ouch!) and then steal the new coins.


I'm not sure that anything can be done by DigiCash or by Ecash-
issuing banks to prevent this, but I thought I'd mention it.


(Hm.  The program also has to steal the user's password in order
to make the withdrawal..  This is getting to be a pretty smart
program!)


Regards,

Bryce
                 "Toys, Tools and Technologies"
  the Niche 
        New Signal Consulting -- C++, Java, HTML, Ecash     
            Bryce 
 
PGP sig follows



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.01

iQCVAwUBMQPWs/WZSllhfG25AQHv2gQAuJsZqQh+IF0vk8C2OY9zsvMlbqN0+GxN
LinbZhWRDlqcRJ69dtzYDhbuvDphHuQYdNUJka5r3Bzplj5tim3sJ+wvEF2eiXTO
vUSXrJ8DvnZPji+qEuv1Zs5D8gXdFs2ALsUbsDxQxVrVlcTbDKnz2EQel0apzqld
VTV8CFvHaRY=
=i3hX
-----END PGP SIGNATURE-----





Thread