Hey there,
On Fri, 17 Nov 2000, Bodo Moeller wrote:
> On Thu, Nov 16, 2000 at 01:45:44PM -0800, Geoff Thorpe wrote:
>
> [...]
> > 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.
>
> We already have 'OPENSSL_malloc_locked', which is intended for memory
> blocks that should not be swapped out, or something like that.
> Actually OPENSSL_malloc_locked() is (usually) the same as
> OPENSSL_malloc(), and I have never checked if all code that should be
> using OPENSSL_malloc_locked() actually uses it (probably not). More
> annoyingly, OPENSSL_realloc() can't tell if a pointer given to it
> points to memory obtained by OPENSSL_malloc_locked() or by
> OPENSSL_malloc().
Exactly - until you implement something "heap"ish around
malloc/realloc/free that tracks allocated blocks, you've got no way of
knowing when you hit a realloc or free if there was anything "special"
about the data regarding locking, sanitisation, etc. Of course, once you
do track those mallocs, you also then have state which allows you to retag
allocated blocks in certain ways if its use/role changes. (eg. RSA going
through and marking the private-key data as sensitive).
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
