Well, the key just might happen to coincide with some other string used by the program. If you start complaining about that, you give away much more information (i.e. you are _telling_ the would-be attacker that the key is a string which normally occurs in the program as something other than the key) than if you pretend it's raining and do nothing.
Remember that if the key string has more references then one of the following must be true:
1) Some other portion of the program is also processing the key. In this case, that other portion should also do secure_destruct() when it's done, and at this time it should actually be overwritten since it's the last ref.
2) The key string coincides with some unrelated string. In this case, there is no need to overwrite the key. The string occurs in the program as something else than the key, so it's ok for it to be there. It might exist before you even _know_ it happens to be the same string as the key.
In neither case do you get any worse securite than if you had had a C program and done memset(buf, 0, sizeof(buf)) at the point that corresponds to the secure_destruct(). The fact that there are more references means that the key is stored in _some other_ "buf" as well, so the memset would not eradicate the key from the process' memory space in the C case either.
Of course, this is assuming the compiler doesn't let references hang around in dead variables, as I pointed out in the previous post.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-28 18:52: Subject: Re: OpenSSL wrapper vs Pike's SSL (Was: Bz2)
Yes, that is a possibility. But it doesn't feel very secure.
It could throw an error on anything with more then one reference, though, I guess, but it feels like that could be used as an exploit to keep the key in memory :)
/ Mirar