On Wed, Oct 31, 2001 at 12:35:25PM -0800, Imran Badr wrote: > I think Eric Rescorla responded to a similar question sometimes ago that RSA > operation would be a limiting factor. But if you take that bottleneck away > then I think putting SSL handshake and record porcessing layers in kernel > space would be a next better thing to do because we can see many new > hardware accelerators out there in the near future market which are 10-20 > times better than what we have today. > We can have certficate management in the user space for the sake of > simplicity. > > Any comments ???
Since most implementations don't use Accelerators for symetric operations, it might be interesting to start with a split implementation. Record layer symetric processing in the kernel, retaining the handshake and public key management in user space... > > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Imran Badr > Sent: Wednesday, October 31, 2001 12:15 PM > To: [EMAIL PROTECTED] > Subject: RE: porting openssl to linux kernel > > > The (un)encrypted data stream is already coming from the kernel ( socket > read/write ) calls. So if everyting is in kernel space then you again save > yourself from the overhead of context switch in reading/writing sockets ... > > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Rich Salz > Sent: Wednesday, October 31, 2001 5:53 AM > To: [EMAIL PROTECTED] > Subject: Re: porting openssl to linux kernel > > > > > The matter here is not to be more secure but definitely one can go > faster. > > > The guys who use hardware acceleration normally use device drivers which > > > reside in kernel space. Now for every operation, the system has to take > a > > > context switch which could be expensive. But if openssl resides in > kernel > > > space then instead of calling a device driver it would be just another > > > function call. Does it make sense now?? > > If you put the hardware crypto into the kernel, then you replace the > crypto context switch -- which only transfers a small amount of data, > typically an RSA-encrypted RC4 session key -- with a new context switch > that transfers a LARGE amount of data, the (un)encrypted data stream. > > Performance would probably be MUCH WORSE. > /r$ > -- > Zolera Systems, Securing web services (XML, SOAP, Signatures, > Encryption) > http://www.zolera.com > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 "Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want" this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) he Hat) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
