On which systems is an SSL key in the memory an issue?
Wouldn't that require that 1) you have root access to the system, or similar and 2) that you on the same system at the same time can't do much worse things much simpler then trying to scan the memory real time, like for instance replacing the server with a version that simply mails the keys to you, or edits the transmission to your liking?
When is that applicable? I'm not saying it's not an issue, I'm just curious.
But, *why not* have an OpenSSL glue in Pike? If someone wants to use it, why not? I don't think we should tell people what to use. When I want to use something in Pike, I commit a glue for it. Then I bugfix it (removes bashisms and suchlike) and makes sure it works nicely. I don't see any problem with anyone doing that with an OpenSSL glue.
Maybe an OpenSSL glue could be used to verify the Pike SSL, and vice versa?
/ Mirar
Previous text:
2003-01-28 13:26: Subject: Re: OpenSSL wrapper vs Pike's SSL (Was: Bz2)
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 ()