SC-based link encryption

2007-01-04 Thread Steve Schear
I haven't been following the smartcard scene for a while.  I'm looking to 
create a low-cost and portable link encryptor, with D-H or similar key 
exchange, for lower 100kbps data speeds. Is this possible?


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

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

2007-01-04 Thread 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 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

... other posts in the same thread: Securing financial transactions a high 
priority for 2007 Securing financial transactions a high 
priority for 2007 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): SSL info SSL info SSL info

now, in the above thread, I've discussed the possible catch-22 for
the SSL domain name certification industry

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 more secure communication over the 

and a couple past posts discussing really lightweight SSL in the 
context of the catch-22 scenario: Another entry in the internet 
security hall of shame GP4.3 - Growth and Fraud - Case #3 - 
Phishing 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

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:

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

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 [EMAIL PROTECTED]