Re: Passwords can sit on disk for years
[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
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
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
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
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
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
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]
