There has never been any Pike-related issues on Bugtraq. Pike did have the same SSL-analysation problem as all SSL implementations, and it is has the same fix.
/ Peter Bortas
Previous text:
2003-01-28 12:56: Subject: Re: OpenSSL wrapper vs Pike's SSL (Was: Bz2)
On Tue, Jan 28, 2003 at 10:55:03AM +0100, Marcus Agehall (Trådlös) @ Pike (-) developers forum wrote:
crypto-related code. Crypt-algorithms are in them selves often very simple. Their principles are based on diffusion and avalanche effects which are pretty easy concepts to grasp.
I am talking about implementation errors, which may lead to weakness.
Poor random number generator is good example of bad implementation, key material which is left in memory awating GC is another one.
Most of the problems within C/C++ implementations of crypto-algorithms are derived from buffer-overflows, not from flawed algorithm
Not only. If you don't clear memory used in key generation after use, this is _bad_ practice. And this is exactly what I am talking about.
implementations. It would actually be pretty difficult to make a flawed implemementation of an algorithm and still have it work for even
Sure. The algorithm and its implementation is perfect. OK. But what is bad is the fact that one could retrieve some valuable data and use it for analysis. Did you think about such things?
That said, I want to express my full confidence that the people who have implemented things within the crypto-parts of Pike have more than sufficient knowledge of what they are doing and have created correct implementations of the algorithms present.
Ok. Tell me a way how I can _clear_ the space allocated for the key in Pike?
To _clear_ (memset(X, 0, sizeof(X)) but not to "mark for GC".
within OpenSSL are quite frequent and often serious. Please tell me of the last time you found an exploit which would give you root-access within Pike and the SSL within Pike.
Pike's user base is few hundreths, OpenSSL user base is tens of thousands, see the difference?
When Pike will be widely used, the we will talk about security and related holes. Right now it is too early - we just don't have enough apps and testers to find ones. Though, I remember some flaws in Roxen implementation - just visit securityfocus.com and search for Roxen in Bugtraq :) You might say that it was not Pike's fault - OK, but it is a reminder that Pike by itself won't resolve problem of "safe programming".
Regards, /Al
/ Brevbäraren