[Cryptography] Heartbleed and fundamental crypto programming practices

[Bear]

On Thu, 2014-04-10 at 07:15 -0400, Jerry Leichter wrote:

> It is - or should be - just a fundamental principle of secure coding
> that you minimize the amount and time you keep "sensitive" data around
> in memory - *and that you never release control of it*.  It's your
> responsibility - you don't hand it to the memory allocator.

'Strewth, but most folks don't even know how to zero memory 
reliably before the allocator gets it back, because many 
compilers now include optimizers that eliminate even explicit 
writes to memory when they can show it will not be read again 
before it is deallocated (and also eliminate reads that 
don't affect output, etc).

"Doesn't affect program output: therefore is a waste of work"  
is the underlying assumption, correct for most software, which 
is utterly, utterly wrong for crypto.

In C and C++, variable locations are stable (and mostly have to 
be because those languages use explicit pointers) but you have 
to declare them 'volatile' to be absolutely sure that the compiler 
will never move them (without zeroing the old location) and that 
writes to them prior to deallocation will happen as the code 
commands.  

In most languages, there is absolutely no standard way to be sure 
of getting an optimizing compiler to leave final writes alone.  
After a conversion to single-assignment form or continuation 
passing style, which lots of compilers do as a *first* step, it 
isn't even likely that a write of a new value for a variable, 
if performed at all prior to the variable going out of scope, 
will be written to the same memory address that held a previous 
value.  

Nor is it guaranteed that what you think is a value you assigned
once and never copied, isn't getting copied to new locations on 
a regular basis by a compacting or 2-space garbage collector.

Unless the language standard guarantees that variables have 
stable locations, and provides a way to guarantee that final 
writes to those locations are honored regardless of whether 
they are read again affecting program output, the best you 
can do is to analyze and test a single version of a single
implementation.  

			Bear