<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 2, 2014 at 1:51 PM, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra">Consider if you want to protect against data which is hot in memory. If you decrypt, how do you make sure the data you decrypted is overwritten straight away, once you don't need them anymore? This approach is so much against the <span class="">Erlang</span> philosophy so it might require a <span class="">NIF</span> to pull off.</div></blockquote></div><br>So, Colin Percival has been up to this for a while. The goal is to protect against an enemy grabbing hold of the memory area later. For example through a heartbleed-like attack.</div><div class="gmail_extra"><br></div><div class="gmail_extra">He starts out with some C code:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html">http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">the problem is to make sure an aggressive optimization doesn't remove the memory zero of the buffer. He thinks he has a clever construction by threading the memset call through an unoptimizable pointer, but alas:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://www.daemonology.net/blog/2014-09-05-erratum.html">http://www.daemonology.net/blog/2014-09-05-erratum.html</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">No, this doesn't work :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">And then he correctly identifies the real problem:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html">http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">which is that sensitive information can be in many locations and memory and you have no way of knowing where: stacks, registers, ... you name it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The consequence is that it is hard to guarantee a given piece of memory is overwritten and never used again. There is no good way of doing this right now, and it is a problem in computing in general.<br><br clear="all"><div><br></div>-- <br>J.
</div></div>