SSL (https, really) accelerators for Linux/Apache?

[Anne & Lynn Wheeler]

for lots of topic drift about fast transactions and lightweight SSL
(somewhat related to past assertions that majority of SSL use has been
e-commerce related)... recent post in thread on secure financial
transactions
http://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007

having some discussion about this news URL from today:

Faster payments should not result in weaker authentication
http://www.securitypark.co.uk/article.asp?articleid=26294&CategoryID=1

... other posts in the same thread:
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007

so having done a lot of optimization on the original payment gateway
and some other SSL uses ... some of it mentioned in this thread
(to help minimize payment transaction elapsed time):
http://www.garlic.com/~lynn/2007.html#7 SSL info
http://www.garlic.com/~lynn/2007.html#15 SSL info
http://www.garlic.com/~lynn/2007.html#17 SSL info

now, in the above thread, I've discussed the possible "catch-22" for
the SSL domain name certification industry 
http://www.garlic.com/~lynn/subpubkey.html#catch22

however, in the past, I've also discussed leveraging the "catch-22"
to implement a really lightweight SSL ... somewhat similar proposal
mentioned here in old email from 1981
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

and a couple past posts discussing really lightweight SSL in the 
context of the catch-22 scenario:
http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh

So after the initial e-commerce activity ... there were some number of
efforts in the mid-90s to improve the internet payment technologies
...  two such activities were SET and X9A10. The financial standards
X9A10 working group had been given the requirement to preserve the
integrity of the financial infrastructure for all retail payments (not
just internet) ...  resulting X9.59
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

I had gotten ahold of the SET specification when it was first
available and did a crypto-op profile and calculated some crypto-op
performance for typical SET transactions. Some number of people
associated with SET claimed that my numbers were off by two orders of
magnitude (too large by a factor of one hundred times) ... however
when they eventually had running code ... my profile numbers were
within a couple percent of the measured numbers. On an otherwise idle
dedicated test infrastructure, a simple SET transaction was over 30
seconds elapsed time ... nearly all of that crypto-op processing.  In
a loaded infrastructure, contention and queueing delays could stretch
that out to several minutes (or longer). Besides the enormous 
processing bloat ... there was also a lot of protocol chatter and
enormous payload bloat. misc. posts:
http://www.garlic.com/~lynn/subpubkey.html#bloat

by comparison, X9.59 had to be a lightweight payload, lightweight
processing, and fast transaction that was applicable to all
environments (not just the internet).

x9.59 went for lightweight payload transaction that could complete in
a single transaction roundtrip, with strong end-to-end security
(applicable whether the transaction was "in-transit" or "at-rest").  It
effectively substituted end-to-end strong authentication and strong
integrity for information hiding encryption. X9.59 also eliminated 
knowledge of the account number as a fraud exploit
http://www.garlic.com/~lynn/subingetrity.html#harvest

and therefor eliminated the need for the most common use of SSL for
hiding account numbers in e-commerce transactions (i.e. for really
high performance and lightweight SSL is when you don't have to do it
at all).

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