On Thu, 16 Nov 2000, Richard Levitte - VMS Whacker wrote:
> levitte> That sounds reasonable. However, I'd like it to be enabled by
> levitte> default, and give people the option to remove or replace at their
> levitte> leasure.
>
> Uhmm, when I come to think of it, that's a bad solution from a
> performance point of view. There's no point zeroing things you know
> are non-secret, like public keys or certificates...
Actually, I was just in the middle of composing the same point when your
post arrived. There is a solution to exactly that issue, and it's probably
overdue anyway. Ie. currently nothing in OpenSSL has any centralised way
of saying "this will need to be cleaned up in *this* way when the time
comes, and that should be be malloc'd in *that* way". Eg. a malloc should
be able to have variable levels for systems that can exploit them, but
also so that reallocation of the allocated memory block gets treated in
the manner intended by the original malloc call.
I'd have thought that it should be possible, in a backwards compatible
manner, to have a "controllable" malloc. Hmmm..
Perhaps
OPENSSL_malloc(size_t size);
translating implicitly to
OPENSSL_malloc_ext(size_t size, unsigned int level);
with the second parameter set to zero?
The idea being that memory replacements can choose if they wish to support
variable levels of "sensitivity". At that point, we'd simply have to find
the points when memory is about to be used for sensitive purposes and mark
the memory appropriately.
Exploring that a bit further ... customised memory functions (or even
defaults) could also support the ability to alter the level of sensitivity
of data after it has been allocated - hence BIGNUM neededn't be inherently
sensitive which would hopefully actually gain effecieincy - eg. the RSA
code could load up the key parameters and go in afterwards marking only
private key data as "sensitive" which means only *that* data is going to
be subject to sanitisation when it's realloc'd and free'd. Otherwise
you're going to memset for every single low-level "free" or "realloc" use
when in all probability a good number of them don't need it (ASN, ERR, and
the majority of uses of BIGNUM for example). Being more selective also
makes the idea of more rigourous sanitisation techniques more appealing.
This stuff is certainly way outside the scope of what's there right now,
and I'm wondering if anyone actually cares enough to take it to this
extent. But it can certainly be done, and remains IMHO a better way of
going than splattering memset's throughout the library in an
all-or-nothing way.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
