// COMPLETE THREAD

Re: properties of FV

2 expanded posts ยท every known parent and child

NODE 90ccd432Re: properties of FV
Excerpts from fv: 15-Dec-94 Re: properties of FV Eric
Hughes@remailer.net (3122)

>    > 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 risk analysis is absolutely true.  However, I have the impression
you missed the phrase "deployed widely enough to have penetrated a
meaningful portion of our market".  I suspect that the cypherbunks and
www-buyinfo communities are not the best place to get a feel for the
extent to which crypto is widely deployed.  Pick some random other list
or newsgroup, however, and I'll be surprised if you find 1% market
penetration for crypto.
NODE cb5eef27Re: properties of FV
From: Nathaniel Borenstein <nsb@nsb.fv.com>

   > "If and When" is Yes and Today.  Anybody who can autosign their
   > outgoing mail can participate in this kind of transaction already.

   However, I have the impression
   you missed the phrase "deployed widely enough to have penetrated a
   meaningful portion of our market".  

The argument I see here is like this: "Not very many people have it,
so we can't use it."  Under this rule, FV shouldn't worry about
support for smart front ends, because most people don't have them
already.  FV shouldn't try to deploy mechant software, because most
people don't have it already.  Now I know that you're not claiming any
of these ridiculous things, that is, outside of cryptography.

What I am suggesting is that FV _allow_, not require, the use of
encryption.  Your main concern with cryptography, it seemed, was theft
of secret keys.  As you agree, that concern can be disposed of.  Now
the reason not to use crypto rests on paucity of existing sites which
use it.  If FV were to _require_ crypto, there would be grounds for
concern.  Yet neither of us think that a crypto requirement is
appropriate for the current FV mechanism.

So why, then, will not FV lead for crypto rather than follow?

It must not be the software integration.  PGP-encrypted mail can be
recognized by a regular expression and filtered if you want to
preserve a single address, or even easier make another address.  Raph
Levien's premail will automatically encrypt mail for outgoing users,
transparently.

It must not be the licensing.  Perfectly legal PGP can be had from
Viacrypt, even for server applications as FV would need.

It must not be for marketing.  Offering merchants a system where the
customers can undertake an effort to lower the merchants's fraud rates
seems like nothing but a win.

It might be for saving face.  Having argued against crypto so
publicly, changing positions so rapidly might be seen to look bad.

So, I'm confused.  What _is_ still the problem?

Eric