1995-12-10 - Re: More FUD from First Virtual

Header Data

From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: jim bell <jimbell@pacifier.com>
Message Hash: aeb7b316cd634e41ebd1bbaecf602760e376b0d9d29fe05d076ea407a697fffe
Message ID: <ckmiLlOMc50eE2isEP@nsb.fv.com>
Reply To: <m0tOVMF-000927C@pacifier.com>
UTC Datetime: 1995-12-10 13:58:01 UTC
Raw Date: Sun, 10 Dec 95 05:58:01 PST

Raw message

From: Nathaniel Borenstein <nsb@nsb.fv.com>
Date: Sun, 10 Dec 95 05:58:01 PST
To: jim bell <jimbell@pacifier.com>
Subject: Re: More FUD from First Virtual
In-Reply-To: <m0tOVMF-000927C@pacifier.com>
Message-ID: <ckmiLlOMc50eE2isEP@nsb.fv.com>
MIME-Version: 1.0
Content-Type: text/plain


I think Adam's already covered the red herring of key length.   You can
use 4-billion-bit keys and it won't help prevent an attack based on
stealing secret keys.

Ed Carp hit the nail on the head when he wrote:  

> What is needed is better human management of keys.  Why 
> brute-force, why look for weak keys, why bother calculating how much 
> safer 2047-bit keys are rather than 1024-bit keys when someone can 
> look on your HD and find your secret key, when they can open your 
> desk drawer and find your pass phrase or password, when they can 
> guess that you used your wife's maiden name as your password?

What some people seem to miss is that, in the absence of hardware keys
(which I believe is the only workable long term solution for mass-market
cryptography), this sort of thing is just plain too easy.  If a Windows
cryptoprogram stores its secret keys in a known location, I can write a
Windows virus that flies through the net and steals zillions.  If the
program insists on making the users insert a floppy every time, the
program's perceived usability will go through the floor, and people will
find workarounds.  In any event, I could write a virus that sits in
front of the e-cash program and steals your keys when next you run the
e-cash program.  Software's just too easy to fool.  That's why I regard
the risk of catastrophe as being fairly large in software-based e-cash
schemes.

Jim, I never denied that some banks would be willing to take the risk
(in fact, read my post, I said just the opposite).  What I said was that
the assumption of the risk would carry a significant underwriting cost,
which would be, in essence, the "cost of anonymity" when comparing
payment systems.  

Finally Jim writes:

> Your arguments seem to only be qualitative, not quantitative.  Maybe that's
> why the other guy calls them "FUD."  

I'm saying that there will be a high underwriting cost for anonymous
cash, and that this will make it much more expensive than non-anonymous
payment systems.  To my mind, that's a discussion about quantity of
costs, not quality.  If you want me to give you numbers, I'm sorry, but
I can't -- I'm not a banker or an actuary, and a lot of leg work would
be required to come up with a precise number in any event.  If I were a
banker, however, I think I'd be too conservative to underwrite e-cash at
any price, and would suggest that you find a less risk-averse banker.  
-- Nathaniel
--------
Nathaniel Borenstein <nsb@fv.com>       | (Tense Hot Alien In Barn)
Chief Scientist, First Virtual Holdings | VIRTUAL YELLOW RIBBON:
FAQ & PGP key: nsb+faq@nsb.fv.com       | http://www.netresponse.com/zldf





Thread