Re: properties of FV
Excerpts from fv: 15-Dec-94 Re: properties of FV Eric Hughes@remailer.net (3987)
I'm not trying to imply that you couldn't cobble something up fairly quickly, but I have my doubts that a good quick hack will scale appropriately for even a modest sized operation.
Assuming that thing that you're "cobbling together" is based on a reasonably robust database engine, it should scale a long, long way. Basically all you need is a set of three-part records: account-id, cumulative amount, and timestamp of oldest transaction. (You might want a fourth field that gives all the purchasing details as text, if your services sells a range of different kinds of things). Any good commercial db system should be able to handle a LOT of such records.
The very nature of such a net billing system requires linkability of transaction to transaction, or in other words generates identity. So FV is unsuitable for small value anonymous transactions.
I would still like to you address this issue, if only to acknowledge the above characterization.
This goes back to the two kinds of anonymity that you so usefully defined in your earlier message. These small transactions would have counterparty anonymity -- all that the seller knows is your first virtual id, which is essentially a user-chosen pseudonym -- but not issuer anonymity.
As I had recalled from reading your materials, you were charging 29 cents plus 2% on one leg of the transaction plus an additional 2% on the other. Rereading, this is not the case. Am I remembering a previous situation?
No, you're just confused. Our charges have not changed, this is what they've always been. Probably our materials weren't clear enough somewhere, in which case I apologize.
Partial security is better than no security.
That's a *very* interesting statement. I'm not at all sure what it means, so I'm not sure if I believe it or not. Sometimes partial security is worse than no security because it gives people a false *sense* of security. (People who know their email is going in the clear are likely to be more prudent than people who believe their email is "encrypted" even though the encryption algorithm might be a very poor one. I've even known people to pass real secrets around using rot13, amazingly enough. People can be quite naive.)
One of the underlying conceptual problems with allowing a key to be at risk is some sort of belief that compromises of secret keys should never ever EVER be allowed to happen. This is ludicrous. When the benefit of the use of a private key means that it might be compromised, don't rely upon it's not being compromised.
This is a very good point. It is one that is often missed in analyses of digital banks, in particular, where the consequences of compromising the bank's keys are often not sufficiently considered.
In particular, if a digital signature does not, by agreement, carry an implied warrantee of identity, then there's no problem at all. Use the crypto entirely for transit security. If someone hacks your machine and grabs your passphrase and forges a transaction, at least the intruder has to grab your passphrase.
This is exactly the way we would expect to use crypto layered on top of First Virtual's protocols, if and when such cryptographic protocols are deployed widely enough to have penetrated af meaningful portion of our market. -- Nathaniel
[re: making a receivables system for small value] Assuming that thing that you're "cobbling together" is based on a reasonably robust database engine, it should scale a long, long way. It's not the technology but the number of different kinds of exceptions to track that cause it not to scale. You don't need to solve those problems right away, though.
Partial security is better than no security.
That's a *very* interesting statement. I'm not at all sure what it means, so I'm not sure if I believe it or not. Sometimes partial security is worse than no security because it gives people a false *sense* of security. It's like this. If there are two ways to break into my house, bashing in the front door and climbing through second story windows, it's better to have a strong front door and no bars on the upper windows than to have no strength in the front door and still no bars. Regardless of the security, users need to understand what it gives them. This is orthogonal to the choice of security, as well as to the persistence of thick-headedness in society.
In particular, if a digital signature does not, by agreement, carry an implied warrantee of identity, then there's no problem at all.
I sense that I this wording was less than fully explanatory. What this means using FV as an example, say, is that FV will not claim that a signed message actually originated from someone. A signature would be _advisory only_, and carry no legal weight as a signature or a proof of identity. You can still require signatures, because this does improve security. Suppose that a customer disavows a signed transaction, saying "Someone must have hacked my account". What you could _not_ do in this example is then to claim that "Well, it must be your account; it has your signature on it", because _by agreement_ the customer is not making any implicit claims about who actually holds the private key. In fact, the disclaimer of a warrantee of identity makes _explicit_ the fact that the private key is not relied upon to be held secretly. This is partial security. It is not all that can be accomplished with crypto; it is only a part. The partial security, however, still has value.
Use the crypto entirely for transit security. If someone hacks your machine and grabs your passphrase and forges a transaction, at least the intruder has to grab your passphrase.
This is exactly the way we would expect to use crypto layered on top of First Virtual's protocols, if and when such cryptographic protocols are deployed widely enough to have penetrated af meaningful portion of our market. "If and When" is Yes and Today. Anybody who can autosign their outgoing mail can participate in this kind of transaction already. Assuming the above agreement is made with respect to private keys, there is _no_ risk to the customer about loss of secret keys, and no greater risk to the merchant than what currently obtains. The dreams of utopia in cryptography are beginning to hold back deployment as much as architectural problems. Eric
Eric Hughes writes
The dreams of utopia in cryptography are beginning to hold back deployment as much as architectural problems.
Very true. Now could everyone keep that in mind before flaming Netscape. -- --------------------------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we James A. Donald are. True law derives from this right, not from the arbitrary power of the omnipotent state. jamesd@netcom.com
participants (3)
-
eric＠remailer.net -
jamesd＠netcom.com -
Nathaniel Borenstein