On Thu, Jun 17, 1999 at 12:30:07PM -0400, [EMAIL PROTECTED] wrote: > Bodo Moeller: >> I don't think that using SSL is appropriate for what you want to do >> (if client and server run on the same system, why would you want to >> use cryptography?) > To protect against "casual" examination of the shared memory which > has to be "world-readable" since virtually any process on that > system could potentially be a client. But this sounds horribly inefficient. Can't you just use an ordinary pipe or socket (of whatever kind)? As noted at <URL:ftp://koobera.math.uic.edu/www/docs/secureipc.html>, no really nice portable solutions for Unix systems exists, but SSL looks like an extremely clumsy way to overcome OS weaknesses. > If you think that SSL is inappropriate for reasons other than > because you don't think same-system communication is necessary, > could please provide those reasons? I don't think that same-system communcation is not necessary; I just think that using encryption for it should not be necessary, because the OS could just as well protect the communication channel against any attacks that encryption is good against; similarly for authentication. If the data is not organized as a stream, then using shared memory -- possibly with encryption -- may make sense; but in this case SSL is not applicable anyway. > I'm already encrypting the shared memory channel, but I need to add, > at least, authentication of the server which SSL does, so I'm > looking at it for that. Is there a way to do SSL authentication > independently of an SSL stream? During the handshake, both parties can assure who the other party is, and derive symmetric keys for MAC-based authentication of the following communication; you could abuse those keys for something else, sure. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
