Re: Passwords can sit on disk for years

2004-06-22 Thread Ben Laurie
[EMAIL PROTECTED] 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 it is, here's gcc -O3:
main()
{
int a=3;
}
becomes:
.file   xx.c
.version01.01
gcc2_compiled.:
.text
.p2align 2,0x90
.globl main
.typemain,@function
main:
pushl %ebp
movl %esp,%ebp
leave
ret
.Lfe1:
.sizemain,.Lfe1-main
.ident  GCC: (GNU) c 2.95.4 20020320 [FreeBSD]
look, ma, no variables!
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Passwords can sit on disk for years

2004-06-14 Thread jdean
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.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Passwords can sit on disk for years

2004-06-14 Thread Jack Lloyd
On Mon, Jun 14, 2004 at 11:31:23AM +, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]


Re: Passwords can sit on disk for years

2004-06-14 Thread Ernst Lippe
On Monday 14 June 2004 13:31, [EMAIL PROTECTED] 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.

Most modern compilers can do flow analysis. The common case is
that the variable is a local variable in some function, and
even very simplistic flow analysis will detect the case that
a variable is dead, i.e. that its value will never be used.
All operations on a dead variable, like overwriting its
value will be removed by the compiler.
The same is true for instance variables in most object-oriented
languages. 

Ernst Lippe


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Passwords can sit on disk for years

2004-06-14 Thread Rich Salz
 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.

Given the semantics of C pointers, and multiple compilation units, the
answer to your question is probably not in non-research use.
/r$
--
Rich Salz  Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Passwords can sit on disk for years

2004-06-09 Thread John Gilmore
 Really, a red page needs to be red all the way through all levels of
 virtualization.  Very low level, or even hardware, support might even prove
 useful - e.g., if for whatever reason the data in the physical page frame
 needs to be copied (after a soft ECC error?), zero the previous page frame.)

Intel, Microsoft and Hollywood are solving this for us.  Their new
hardware can't be virtualized, so it can't leak the
monopolists/oligopolists' keys.  In their scheme, of course, OUR keys
don't get the same level of protection as monopolist keys.

John

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Passwords can sit on disk for years

2004-06-08 Thread jdean
And of course, the article didn't get it right.  Because of optimizing 
compilers, it is *not* trivial to zero passwords.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Passwords can sit on disk for years

2004-06-07 Thread Adam Fields

Tal Garfinkel (related to Simpson?) is a Stanford PHD student who has
put together a working model for tracking tainted data stored in RAM
in various popular applications.

This is the first mention I've seen of this - interesting stuff.

http://www.newscientist.com/news/news.jsp?id=ns5064

Abstract here:

http://forum.stanford.edu/events/workshop/security/abstract/garfinkel.html


-- 
- Adam

-
http://www.adamfields.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]