While we can never make any language safe (except perhaps ADA) for bad programmers, pike does it's best. The fact that the programmer doesn't have to worry about allocating/freeing memory saves us from a lot of potential problems. Sure, the GC in Pike has it's flaws but I think it does a better job than most C-programmers does.
When it comes to the implementation of cryptoalgorithms in Pike, I do believe that it is reasonably safe. If I were to build a system which required high security (as in a military system or equal), I would not trust the Pike implementations and most certainly I would not trust OpenSSL. A quick search at securityfocus.com reveals that Roxen has 8 documented flaws. They all seem to originate from within roxen. OpenSSL had 10+ *PAGES*! Ok, I know that the userbase for OpenSSL is larger than for Pike, but still. DES, RC{4|5}, AES etc are all welldocumented algorithms which most of my friends would be able to implement in Pike without any major flaws. Considering that the people working on Pike are usualy pretty smart, I don't think we have much of a problem here.
The only thing I see as a problem, is how the key is cleared from memory once the algorithm is done with it. I agree with you that it might be a weak point in the Pike implementation. But that can be fixed with ease.
I think you made my point in your last paragraph. Using OpenSSL won't, by itself, resolv the problem of "safe programming". It's a fact that we've known about most exploits for 20 years and they are still around...
/ Marcus Agehall (Trådlös)
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