Re: More FUD from First Virtual
At 09:58 AM 12/9/95 -0500, you wrote:
The real open question about anonymous digital cash is whether people will want it badly enough to bear that kind of risk. My guess is that a few people will, and that a few (even fewer) small banks will accept the risk, so there will indeed be a niche in anonymous cash. But I think that for better or worse, most people and banks won't value anonymity so highly as to incur a low-probability catastrophic risk, which I think is inherent in anonymous cash.
I find this hard (read: "impossible") to believe. The significance of the risk is, essentially, its magnitude multiplied by its probability. Assuming that its probability is reduced to an arbitrarily low value, SOMEBODY will be willing to accept the risk in exchange for a return. By way of comparison, most credit card companies charge 2-3% of the value of a transaction, which apparently the market has decided is a "reasonable" cost. The question is, why wouldn't it be possible to raise the reliability of the whole digital cash system simply to the point where somebody is willing to accept the risk for, say, 0.5% of the value of each transaction, which would be a good improvement over credit cards? The answer, I think, it that there would be no problem finding people to take that risk in exchange for the return, ESPECIALLY if they have some input into the design (level of security) of the system. They might insist on 2048-bit RSA keys, instead of 1024-bit, for example.
Well, maybe I haven't been following those reasons, but I see little or no reason privacy should "inevitably carry a high surcharge." If the relevant encryptions had to be carried out with a pencil and a piece of paper, that claim would make sense, but remember, we've got MICROPROCESSORS on our side!
The cost isn't the computation. The cost comes primarily from the efforts (both practical and actuarial) that will be made by the underwriters to minimize and amortize their risk. As Lloyds of London has demonstrated, almost any risk can be undertaken at a high enough premium....
However, the premium only needs to be high enough to cover the actual risk, plus perhaps a little profit on the deal. (Even if the premium was 10x the actual risk, or even 100x, I think it would end up costing well under 1% of each transaction.) Your arguments seem to only be qualitative, not quantitative. Maybe that's why the other guy calls them "FUD."
jim bell wrote: [Good points about cost of transactions deleted] | The answer, I think, it that there would be no problem finding people to | take that risk in exchange for the return, ESPECIALLY if they have some | input into the design (level of security) of the system. They might insist | on 2048-bit RSA keys, instead of 1024-bit, for example. (I know its only an example, but...) Key length is not what is needed for better security; more solid code and better interfaces are needed. (I might also argue for hardware keys that are more difficult to steal..) Cryptosystems fail because of bad storage of keys, coding mistakes, accidentally writing passphrases to disk during a swap, etc. Moving to 2048 bit keys is no help if you lose the key to a non-cryptanalytic attack. Moving to keys with a week or day lifetimes might be better. You need to figure how the system might fail, and design to protect yourself from those failures. Keys with a thousand bits aren't lost to factoring very often. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
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
participants (3)
-
Adam Shostack -
jim bell -
Nathaniel Borenstein