Thanks for pointing this out. I've checked in a fix (r467, r468) to SVN.

SecureZeroMemory turned out to be a macro that calls a regular inline 
function defined in winnt.h. Instead of including a big Windows header file, 
I created my own SecureWipeArray() function in misc.h. I've confirmed on 
MSVC 2005 and GCC 4.3.2 that it's not being optimized out.

--------------------------------------------------
From: "Paul Pelzl" <[email protected]>
Sent: Thursday, April 30, 2009 5:37 PM
To: "Crypto++ Users" <[email protected]>
Subject: Re: AllocatorWithCleanup not guaranteed to clean up?

>
> On Thu, Apr 30, 2009 at 07:51:16PM -0400, Jeffrey Walton wrote:
>> >  ... as the better optimizing compilers are
>> >  likely to eliminate the call to memset()
>> Howard and LeBlanc discuss the topic in Writing Secure Code starting
>> at p. 325 (ISBN 0-7356-1722-8).
>>
>> On Windows, you can call SecureZeroMemory. It is guaranteed *not* to
>> be optimized away. But it is only available for Windows 2000 and
>> above. On Windows, you can also use #pragma optimize [2] to keep the
>> compiler from removing otherwise dead code. Finally, you can declare
>> the pointer as volatile. But Howard and LeBlanc warn that the volatile
>> trick may disappear if optimizers improve.
>
> Right.  SecureZeroMemory() is a good solution, but I'm not aware of
> equivalent library functions for other platforms.
>
> OpenSSL defeats the optimization by combining the memory clear with
> modification of a global variable:
> http://www.srcdoc.com/openssl_0.9.6m/mem__clr_8c-source.html
>
> Paul
>
>
> >
> 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---

Reply via email to