[Cryptography] Secure erasure

Arnold Reinhold agr at me.com
Thu Sep 8 20:19:28 EDT 2016


On Wed, 7 Sep 2016 17:24 John Denker wrote:

> AFAICT it is simply not possible to write a truly secure erase
> routine in C.  The language is defined with respect to an abstract
> machine that does not support the concept of erasure, secure or
> otherwise.
> 
>  You can implement "some" measures that take away "some" of
>  the attack surface, but that's far removed from a complete,
>  provably-correct solution.
> 
> The language is guaranteed to produce "the" right answer and leave
> it in "the" appropriate place.  It offers no guarantees as to how
> many extraneous copies are left lying around.
…

Imagine for a moment what might be possible if the toolmakers were actually trying to help instead of sticking to a language spec largely from the PDP-11 era. One might add a "zeroizable” keyword, for example. All that code generation ingenuity could be applied to not only insuring the code that erases zeroizable data was not elided, but also to keeping track of copies, and even minimizing their creation. The compiler might be able to recognize when the data in question was no longer needed it and erase each copy of it at the earliest instant. Object destructors could reliably destroy. Pragmas could prevent optimization of critical code. Leaky constructs, such as storing zeroizable data in flash, could be flagged. And so on.

This thread, and so many like it, have concentrated on the problems facing the programmer. But what about software maintenance, management and quality assurance? The sin qua non of the last is strict configuration management. This thread and others over the years say that it is not possible to insure that object code which has passed tests in the past will not change in the future, despite unchanged source files. There are relatively simple things that could be added to the tool chain to fix that, if we were all cooperating. 

> AFAICT if you want to shrink the attack surface, it requires rethinking
> and redesigning everything including hardware, operating system, and
> language.  ...


Yes there are many security dragons to slay, but they must be attacked individually. Fixing the tool chain seems like one of the easiest problem technically. The barrier seems to be in human relations, not technology. The Free Software Foundation says it is opposed to mass surveillance and has even joined in a law suit against the NSA. (http://www.fsf.org/news/fsf-other-groups-join-eff-to-sue-nsa-over-unconstitutional-surveillance <http://www.fsf.org/news/fsf-other-groups-join-eff-to-sue-nsa-over-unconstitutional-surveillance>) Do they realize that the tools they develop and promote stymie efforts to develop secure software and no doubt make the NSA’s hacking job much easier? 

How do we start what FBI Director Comey calls “an adult conversation" with the computer language and tool community?

Arnold Reinhold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160908/40ea9747/attachment.html>


More information about the cryptography mailing list