> Jeffrey Altman wrote: >> I think we need to take a very close look at the situations when >> it is safe to replace memset(buf,0,sizeof(buf)) with >> OPENSSL_cleanse(buf,sizeof(buf)). It is clearly safe to make this
[snip] Ben> OPENSSL_cleanse() should be followed by a memset()? OTOH, if the Ben> result of memset() is used, then it can't be optimised away... Yoram> Same concerns are raised while trying to gain performance by Yoram> reusing the SSL structure, instead of reallocating it for new Yoram> connection establishment. Using SSL_clear(SSL *s), as part of Yoram> the reuse flow, involves a call to OPENSSL_cleanse. Yoram> Following OPENSSL_cleanse with a call to memset() may result Yoram> with performance degradation. Are the OPENSSL_cleanse Yoram> replacements required in all cases ? Should we be able to Yoram> dynamically define which behavior is preferable ? Configurable behaviour is certainly preferable for many embedded applications. Processes typically don't have the separation on embedded apps that big iron boxes do. I guess that there are many instances where OpenSSL does things in order to prevent prying eyes on the same box. I can appreciate this on my Linux machine. However, most people wouldn't want this on a router. Perhaps a macro like the NO_MD5, etc could be used. I know that the BIO's make this rather slick for the ciphers. Conditionalization of counter-measures against host originating attacks might be much more difficult to implement. fwiw, Bill Pringlemeir. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
