At 10:40 AM 7/7/2004, Hal Finney wrote:
SET failed due to the complexity of distributing the software and setting
up the credentials.  I think another reason was the go-fast atmosphere of
the late 90s, where no one wanted to slow down the growth of ecommerce.
The path of least resistance was simply to bring across the old way of
authorizing transactions by card number.

the other issue was rsa public key op overhead (besides extreme payload
bloat, extreme additional complexity, and no significant countermeasures for
prime exploits compared to e-commerce incumbent SSL).

when the initial set specification was published, i did a business profile and
a performance profile (including public key operations profile). somebody
i knew was playing with bsafe library and tweaked it to run four times
faster. I got him to run the set public key op profile on a number of processors.

i mentioned the numbers at some set get together and the response from
the set people was that it was 100 times too slow (if they had ever run
any bsafe they should have realized that it was four times too fast).
anyway ... sometime later when they actual set implementations running ...
the earlier profile numbers were within a couple percent of measured on
actual implementations.

i also observed that given nominal extended peak avgs. of 1000/transactions
per sec .... that if SET ever actually became mainstream operational (rather than
just toy pilots) ... processing would need something like 100,000 to 250,000
extra processors to handle the RSA op processing load. the counter argument
was that SET would take so long to became mainstream ... that by
then CPUs might be ten to 100 times faster and it might only
require 10,000 to 25,000 (or 1,000 to 2,500) extra processors.

Anne & Lynn Wheeler

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to