Yes, but if you did something stupid like,
class { string key; ... { ... secure_destruct(key); ... } }
you wouldn't even get a warning. I think a zero_when_destroyed flag would work better then. But it's probably best to use a special solution for the key, like System.Memory, if that is possible.
/ Mirar
Previous text:
2003-01-28 19:03: Subject: Re: OpenSSL wrapper vs Pike's SSL (Was: Bz2)
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:
- 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.
- 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!)