Re: Software leaves encryption keys, passwords lying around in memory

[Dan Kaminsky <dan () doxpara com>]

> volatile char key[ 16 ];
>
> (== don't optimise access to/from this var in any way)
>
> end of problem.
>  
Yes, but here you *hope* the compiler has the same semantics for 
"volatile" that you do.  The "keys to the kingdom"(sufficient context to 
zap your memset) are left in place; you just hope the compiler bothers 
to ignore it.  I'd rather *know*, at least at the same level of 
confidence I have that I know anything else about the compiler.

Creating a dynamic dependancy during memory clearing effectively 
deprives even the most rabidly optimizing compiler of, well, the keys to 
leave your data untouched.  You do have to accept that the compiler is 
emitting assembly that is computationally equivalent to what you're 
writing -- but this is a necessary batch of trust you need to give to 
anything running your code, including the processor itself(which doesn't 
even run assembly anymore, but a massively reordered form of microcode). 
You also need to ignore that bizarre corner case where the same memory 
address is mapped to multiple *physical* addresses -- such a memory 
architecture could simply alter one of the addresses and tag the rest as 
"tainted" without in fact clearing them.  But I don't think anyone 
actually does this -- I'm at least significantly more sure of that than 
I am of the precise semantics of "volatile" vis-a-vis dead code elimination.

Yours Truly,

   Dan Kaminsky
   DoxPara Research
   http://www.doxpara.com