the limits of crypto and authentication

[Anne & Lynn Wheeler]

Rich Salz wrote:
> Wasn't that a goal of SET?

there was an observation that SET possibly wouldn't divulge your account
number until the merchant had been determined to be some entity
registered as a merchant (akin to the SSL domain name infrastructure
certificates ... if a spoofed site didn't use SSL until you hit the
pay/checkout button, what is the probability that the spoofed site
provide a URL that matched some valid certificate that they did have).

note, however, some of the participants even got confused about this issue.

note that there are a lot of merchant business processes that require
the account number ... and therefor you can't prevent the merchant from
possessing the account number. some might be tempted to observe that
there is a kind of conflict of interest ... using the same value for
authentication purposes as well as widely needed for a large number of
other purposes (akin to designing a system that widely uses your userid
a basis for normal functioning ... as well as making your userid also
your password).

some past posts where the SET issue of divulging account number was
disucssed.
http://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption
http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re:
crypto flaw in secure mail standards

I thot the goal of SET was to maximize the number of RSA-ops being
executed in the world.

When I first obtained a copy of the initial SET specification, I did a
RSA-ops profile and a business operation profile. An acquatance had done
some work on the BSAFE library and improved the performance by a factor
of four times. I got him to run timing tests on the SET RSA-ops profile
across a number of different machines. I then communicated the results
to a number of people that were part of the SET group. The reply from
various members of the SET group was that the numbers were obviously one
hundred times too slow (the correct answer should have been that the
numbers were four times too fast). Six months later when the first
prototype SET code was running ... their measured numbers were within a
couple percent of my earlier profile numbers (aka the BSAFE enhancements
had been given back to RSA).

One possible observation was that SSL work
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

was already providing account number confidentiality for
*data-in-flight*.  The significantly much more complex, and heavyweight
SET would have needed to provide countermeasures for significantly more
threats and vulnerabilities ... like security for *data-at-rest* (aka
data breaches) in order to make any headway against the (SSL) incumbant.

I also made a couple comments to the SET group about the heavy-weight
nature of SET (apparently the RSA-ops being one hundred times more
onerous than they had anticipated). Effectively, the SET RSA-op profile
was symmetrical .... but the standard processing is quite asymmetrical.
In effect, the massive datacenters that are currently processing credit
card transactions would have needed their computational facilities
increased by at least one hundred times (SET RSA-op profile was looking
at tens of seconds per transaction while many of these datacenters
measure their thruput in thousands of transactions per second ... a four
orders of magnitude gap).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com