Re: Hmm... (discoveries about BIGNUM code)

[Richard Levitte - VMS Whacker]

From: [EMAIL PROTECTED] (Peter Gutmann)

pgut001> Currently the bignum code takes care to zeroise bignums after
pgut001> they're no longer needed in all locations *except* when
pgut001> realloc() is called, I see this as a hole in its security if
pgut001> situations can occur where the zeroisation is bypassed.

I was wrong, it doesn't a realloc(), it does a malloc followed later
on by a free().  However, I found no place where the expansion zeroes
the previous memory, not even before I made my changes in there.

I will take your words to heart and do the needed change.  I agree
with you that it's a concern, and for those wondering, the explanation
that Peter doesn't provide is that free'd memory goes back to the
system and may be given to other programs that allocate memory,
without the memory getting touched, thereby giving the contents (for
example a key) to some other random program.

I know, many systems zeroes allocated memory for you (uhm, at least
VMS usually does), but is that something anyone can guarantee?  I
definitely can't...

-- 
Richard Levitte   \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \      SWEDEN       \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis                -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]