[15610] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Passwords can sit on disk for years

daemon@ATHENA.MIT.EDU (Jack Lloyd)
Mon Jun 14 16:23:30 2004

X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Mon, 14 Jun 2004 13:31:37 -0400
From: Jack Lloyd <lloyd@randombit.net>
To: cryptography@metzdowd.com
Mail-Followup-To: cryptography@metzdowd.com
In-Reply-To: <EXCHMX2YixMwInhdAHx00001b7e@relay.lsuhsc.edu>

On Mon, Jun 14, 2004 at 11:31:23AM +0000, jdean@lsuhsc.edu wrote:
> Ben Laurie wrote:
> 
> > In OpenSSL we overwrite with random gunk for this reason.
> 
> What?  No compiler is smart enough to say, "The program
> sets these variables but they are never referenced again.
> I'll save time and not set them."

Sure there are. In fact there was a discussion (either here or cypherpunks)
maybe a year or two ago about how Visual C++ has exactly that problem with
memset. Consider the following:

void foo()
{
   char buffer[1024];

   /* do something */

   memset(buffer, 0, 1024);
   return;
}

As far as the compiler can tell, that memset has no effect, because as soon as
it returns from the function the stack will go away, so whatever value it may
or may not have doesn't matter (basically - there is no way for you to tell if
that memset executed or not). Since it has no effect, why bother executing it?
It's just a waste of time.

That's because languages are defined in terms of side-effects that are visible
to the program - not in terms of side effects visible to some external
entity. The fact that someone messing around with swap can tell if that memset
executed or not is not something C cares about.

-Jack

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

home help back first fref pref prev next nref lref last post