From RISKS: http://catless.ncl.ac.uk/Risks/22.35.html#subj6

Those of us who write code need to be reminded of this now and then. Peter Trei --------------- Software leaves encryption keys, passwords lying around in memory Monty Solomon <monty@roscom.com> Wed, 30 Oct 2002 22:31:46 -0500 http://online.securityfocus.com/archive/82/297827 Date: Thu, 31 Oct 2002 05:11:31 +1300 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) Subject: Software leaves encryption keys, passwords lying around in memory The following problem was first pointed out (in private mail) by Michael Howard from Microsoft. His writeup is now available at http://msdn.microsoft.com/library/en-us/dncode/html/secure10102002.asp. From a representative check of a few widely-used open source crypto programs, this affects quite a bit of software. The problem he points out is that clearing sensitive information such as encryption keys from memory may not work as expected because an optimising compiler removes the memset() if it decides it's redundant. Consider for example the following: int encrypt( const void *key ) { puts( key ); /* Normally we'd encrypt here */ } void main( void ) /* Because we can */ { char key[ 16 ]; strcpy( key, "secretkey" ); encrypt( key ); memset( key, 0, 16 ); } When compiled with any level of optimisation using gcc, the key clearing call goes away because of dead code elimination (see the MSDN article for more details on this, which uses VC++ to get the same effect). While you can kludge enough stuff around a custom memory-clear call to fool the optimiser (hacks with 'volatile', touching the memory after it's cleared and hoping the optimiser is fooled, etc etc) there's no guarantee that it'll work for anything but the compiler(s) you happen to test it with - any future enhancement to the optimiser may turn it back into a nop. What it really needs is the addition of a #pragma dont_remove_this_code_you_bastard in the compiler. Until then, a lot of security code will be affected by this problem. [In RISKS, I tend never to alter British spellings. However, in American English, an "optimiser" must be the ultimate miser.]