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

["NSB's Portable (via RadioMail)" <nsb@radiomail.net>]

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