I promised myself that I would not involve myself in this discussion, but.
First, many people doing the wrong thing does not make it right. SSLEY was _horrible_. Just plain _horrible_. It was at least 10 times larger than it needed to be, and the code was anything but safe. A causual read-through found 10 static sized buffers that theoretically could be overflowed.
I cannot imagine that OpenSSL is all that much better.
Your arguments boils down to two things: 1> Many people are using OpenSSL, and 2> Clearing memory should always be done when creating keys, and is not done in pike.
I assume you are running Windows only, and IE5.0
Well.
All string allocated by the crypto library tends to be overwritten a few microseconds later. It is of course possible that they are not, but it's very, very, very unlikely. For more or less 100% certainity, using the current interface, do something like this:
string key = Crypto.reasonably_random()->read(length); // Use key here.. key = 0; key = Crypto.reasonably_random()->read(length); // Same size. I have yet to see a malloc that does not use the same // location. This is not really 100% certain, though. See next // solution.
System.Memory key = System.Memory( bits>>8 ); Crypto.reasonably_random( key, bits>>8 ); // requires a trivial modification of the interface. // use key here. key->write( "this is not the real key", bits>>8 ); // Overwrite key here.
Also, generating new keys are not exactly a common problem. Most of the time you use a key you need to explicitly keep it in memory.
Also, a quick check of the openssl keygen program seems to indicate that it does not actually clear the generated keys before it exists. Not that it really matters, since they are saved to disk, but still. :-)
/ Per Hedbor ()
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