Re: properties of FV

[eric@remailer.net (Eric Hughes)]

[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