Re: first virtual "security" (!!) (was Re: Security Flaw Is Discovered InSoftware Used in Shopping)

At  4:32 AM 9/21/95 +0200, Laurent Demailly wrote:
>You have excellent points in your detailed answer, thank you, but

Thanks.  I'm glad to be able to conduct this discussion at a cordial and
intelligent level.

>If FV was as used as SSL could be, what prevents, to use your terms,
>someone to get MILLIONS of FV's identifiers and use each one only
>once, etc ... (imo your figures about SSL and crypto softs risks are
>over evaluated, so I over evaluate the 'risks' of yours using same
>assumptions)

I think you still don't get it, Laurent.  If you intercept millions of
credit cards, you immediately have something very valuable and untraceable.
 An FV-ID is much less useful than a credit card number, because it only
works with email confirmation and only works on the net.  And merely
intercepting them doesn't get you anything -- you have to be able to answer
the confirmation messages, which is much harder to do "en masse" than
passively sniffing for things (and possibly then decrypting them).  And a
scheme that also replies to such messages is far more likely to leave
traces by which the criminal is caught.

In other words, when you look at the "millions of interceptions" case, the
value of doing this is lower for FV, the difficulty of automating it in the
large scale is higher, and the risk of detection is higher, as compared
with a one-way scheme that transmits credit cards, whether encrypted or
not.

>There can't be more security by transferring data on the clear
>compared to an encrypted one... except maybe that people using
>encryption can often feel overconfident. 

Of course there can, if you're not talking about the same data, which we're
not.  It's much safer to transmit something without high intrinsic value in
unencrypted form than to transmit something with high intrinsic value in
encrypted form.  That's why FV-ID's were designed the way they are -- low
intrinsic value, easy to revoke & reissue, etc.  By analogy, it is safer to
send a weather report unencrypted than to send detailed instructions about
nuclear weapons encrypted.

>So, as someone pointed out,
>it is not that much a problem about CC# which are available easily
>anyway, but in fact, using encrypted communications is the only way to
>ensure (some) *privacy*, in addition to being a security improvement. 

Also not true.  A scheme like FV's gives a fairly high privacy level
through the use of pseudonyms.  Your FV-ID can be traced to you *only* by
FV, and we won't hand out that informaton without a court order.

>financial insecurity never was a problem as
>long as it remains under a small %.

This is an amazing statement, Laurent.  It's sort of like saying that
building a city in the middle of a flood plain isn't a problem as long as
there isn't a flood.  You can't dismiss even a low-probability disaster if
the consequences of the disaster are extremely high.

If the SSL bug had been discovered AFTER there were hundreds of millions of
credit cards being transmitted via SSL, and if the person who discovered it
had criminal intent, the entire global credit card infrastructure really
would have been endangered.  Personally, I'm always suspicious of any
claims to have "fixed the last bug", so I don't see any reason to assume
this isn't inevitable in the long run if a scheme like SSL is used.

>Anyway, if you have happy customers, good for you... I'd suggest that
>you'd use "Security through Clarity" as motto ;-)

That's not a bad motto.  I'd prefer to describe our system as focusing on
practical, comprehensive security rather than chasing the myth of perfect
cryptographic security.  (For example, we've probably put more effort into
making our server secure from breakins than just about any other site on
the Internet.)

We're not opposed to cryptography, by the way.  There are some obvious
places where the use of digital signatures could directly enhance our
system, and we're pursuing them.  It has also not escaped our notice that,
even though we strongly believe that transmitting FV-ID's in the clear is
safer than transmitting credit cards encrypted, it would be safer STILL to
transmitthe FV-ID's encrypted -- sort of the best of both worlds.  And you
can count on our doing that when there is a good Internet infrastructure
for doing so, which we don't yet believe to be the case.  -- Nathaniel

-----BEGIN PGP SIGNED MESSAGE-----

Hello Laurent Demailly <dl@hplyot.obspm.fr>
  and "NSB's Portable (via RadioMail)" <nsb@radiomail.net>
  and cypherpunks@toad.com

"NSB's Portable (via RadioMail)" <nsb@radiomail.net> writes:
> At  4:32 AM 9/21/95 +0200, Laurent Demailly wrote:
...
> >financial insecurity never was a problem as
> >long as it remains under a small %.
> 
> This is an amazing statement, Laurent.
...

It's not an amazing statement. As long as the cost of insecurity is
less than cost of security, there's no problem.

...
> We're not opposed to cryptography, by the way.  There are some obvious
> places where the use of digital signatures could directly enhance our
...

Okay, so what's stopping you from starting right now with PGP?
You could simply have that as an alternative to the current system
(on a per-ID basis, ie new customers specify PGP or not).

Quite a few people both have PGP and would think well of you if you
started using it.

How about "The safest Internet payment system just got safer."?


Jiri
- --
If you want an answer, please mail to <jirib@cs.monash.edu.au>.
On sweeney, I may delete without reading!
PGP 463A14D5 (but it's at home so it'll take a day or two)
PGP EF0607F9 (but it's at uni so don't rely on it too much)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAwUBMGITYCxV6mvvBgf5AQGN0wP8DxZ50ZMR3H+W6LCc0vhFZ6GMrTRZPSM4
XULabVj4w59aEDUWj2wbueXaPJUMHpAgYK83oMGLtlu1Hrxzo9/SXT/WzcMUZp7q
qajmCXRY9q3b+OXznTLavrF5qISlPY8NU/HbSi/nCF8kbT6eEf8rXc/uZgPCyV6j
RuvE2VDWaCc=
=J4iR
-----END PGP SIGNATURE-----

Excerpts from mail.fv: 22-Sep-95 Re: first virtual "security.. Jiri
Baum@sweeney.cs.mon (1560*)

> > >financial insecurity never was a problem as
> > >long as it remains under a small %.
> > 
> > This is an amazing statement, Laurent.

> It's not an amazing statement. As long as the cost of insecurity is
> less than cost of security, there's no problem.

I think the basic confusion here is precisely about the cost.

The cost of having one credit card stolen is small.

The cost of having millions stolen at once is *astronomical*.  It really
could bring down the whole credit card system, if that was the
criminal's goal.

My concern is about schemes in which the compromise of the cryptographic
algorithms or software leads to a scenario in which one criminal steals
millions of credit cards.  In such a scenario, the cost of insecurity is
unacceptably high.

> Okay, so what's stopping you from starting right now with PGP?
> You could simply have that as an alternative to the current system
> (on a per-ID basis, ie new customers specify PGP or not).

> Quite a few people both have PGP and would think well of you if you
> started using it.

> How about "The safest Internet payment system just got safer."?

We're definitely moving in this direction.  It's more complicated than
you make it sound, though.  Personally, I don't want to use any
cryptography without an explicit, clear, policy and mechanism for key
expiration and key lifetimes.  The risk of key compromise is directly
proportional to the key lifetime.  PGP today -- which we use very
heavily internal to FV -- is not well-equipped for dealing with key
management issues on a scale of millions of users.

Now, having said that...  we're currently planning to deploy FV version
2 before the end of the year.  Version 2 *will* include the first use of
PGP in the FV system, but it will NOT work the way you probably expect. 
Stay tuned!  -- Nathaniel
--------
Nathaniel S. Borenstein <nsb@fv.com>    |           When privacy is outlawed,
Chief Scientist, First Virtual Holdings |     only outlaws will have privacy!
FAQ & PGP key: nsb+faq@nsb.fv.com       | SUPPORT THE ZIMMERMANN DEFENSE FUND!

---VIRTUAL YELLOW RIBBON-->> zldf@clark.net <http://www.netresponse.com/zldf>