[Cryptography] Secure erasure in C.

[Patrick Pelletier]

On 9/7/16 1:04 PM, Ray Dillinger wrote:
> When possible, I do operations that can be done in finite
> bounded memory using a static volatile buffer to hold
> sensitive data.  Design the program right so you absolutely
> know how much memory the operations need, and the static
> volatile buffer solves many problems.

If you're writing a program which is single-threaded, and which you know 
is always going to be single-threaded, that works.  But if you're 
writing a library, chances are that someone will want to use it in a 
multithreaded program someday.

> Transient copies and virtual-memory caches don't get made
> because if the compiler can't assume the copies remain in
> sync to the buffer, then making copies is useless.

As others have pointed out, virtual memory is completely orthogonal to 
what the compiler is doing, and volatile will in no way prevent 
swapping.  You'd need to lock the pages, using OS-specific calls, to 
avoid swapping.

> For years I'd been defining 'erase' using
>
> //////
> static void *(*const volatile deleter)(void*,int,size_t)=memset;
> static void erase(void *buf,size_t len){deleter(buf, 0, len);}
> //////

I think the problem is that deleter is static, therefore it only takes 
analysis of a single compilation unit to know that it won't change.  If 
you make deleter non-static, then its value could always be changed from 
another compilation unit, and the compiler can't make assumptions about 
its value.  (You might need to remove the "const" as well; I'm not sure.)

Even with whole-program optimization, the optimizer can't know that some 
dynamically loaded library won't change the value of deleter. I suppose 
that if your program is 100% statically linked, and you use a whole 
program optimizer, then maybe it could still outsmart you.  But you've 
still raised the bar substantially over the "static" version.

--Patrick