OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Looking for a very computationally asymetric public key cryptosystem
From: Alex Alten (Altenhome.com)
Date: Thu Dec 14 2000 - 00:17:43 CST

Hello Jesus,

Sorry for the late reply, I moved into another house and couldn't quite
organize a smooth transition with my AT&T AtHome ISP (the email transfer
was the hardest part oddly enough).

Anyway, when I was at TriStrata (remember them?) I was faced with a
similar problem. I'm assuming that you are willing to design your own
custom solution rather than do something off the shelf. Our final
solution performed 2000 unique authentications (request/response packets)
per sec on a dual 200 Mhz Pentium Pro (1000/cpu), all in software.
We rekeyed per transaction (many thanks to Peter Trei for suggesting the
key setup optimization technique, maybe he can suggest something as
clever for AES), each one had about 300-400 bytes of encrypted material
(it was designed primarily for UDP/IP). If you want to do this in
software I think you need to seriously consider a symmetric cipher like
3DES or AES instead of RSA, etc., for authentication. The big problem
with this is the key management aspects, e.g. enrollment, revocation,
etc. TriStrata solution works well (actually I still think it's the best
around--but I may be a bit biased ;-), but it probably is too expensive
for you. Possibly using Kerberos might work for you, although I think it
would slower and it would not be a complete solution. We also used
TCP/IP, but we found that the overhead of TCP actually slowed things
down to about 200+ transactions/sec (i.e. a TCP connection for 300 bytes
of enciphered data!). On top of that you have to worry about connection
pooling, DOS attacks, and client timeouts/crashes. The big drawback with
rolling your own is that you have to be careful not to screw up handling
your keys/IVs and that the authentication handshake is solid. This often
means you should seriously consider getting someone discrete to review it,
like Peter Pearson over at Uptronics (I wasn't too impressed with some of
the other better known names). Of course this can be super expensive.

Anyway I hope this helps. The SSL hardware accelerators are expensive.
If I remember correctly, they can be over $1000 for the ones that support
200 x 1024 bit RSA authentications.

Good luck,

- Alex

At 01:00 PM 11/22/2000 +0100, Jesus Cea Avion wrote:
>> If you cache sessions, as SSLv3 (and TLS) do, the load due to the PK
>> part becomes much less of an issue, especially in scenarios like
>> yours.
>
>I'm having 20-30 new sessions per second, from different clients, and
>that number is climbing up from day to day. No caching possible.
>
>In some circunstantes, I can get up to 500 new sessions per second,
>within a limited timespan. All of them are new clients, no caching.
>
>Ideally, the system should allow 200 new sessions per second, using a
>Pentium 200 like system. Yes, a Pentium running at 200Mhz :-).
>
>(the real system is far more powerful, but it runs a lot more code than
>PK cripto :-)
>
>--
>Jesus Cea Avion _/_/ _/_/_/ _/_/_/
>jceaargo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
> _/_/ _/_/ _/_/_/_/_/
>PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/
>"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
>"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
>"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> 

--

Alex Alten

AltenHome.Com