<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 27, 2022 at 12:51 AM Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com">phill@hallambaker.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small">[Before we start, use language X instead is not an answer here.]</div><div style="font-size:small"><br></div><div style="font-size:small">We all know array bounds checking etc. is a good thing to have to write any application code. But the cost of abstracting away memory management is that cryptographic code has the very particular property that we want to ensure data is cleared AFTER USE rather than BEFORE REUSE.</div><div style="font-size:small"><br></div><div style="font-size:small">A lot of applications written in high level languages are vulnerable to attacks when someone uses portable assembly language, aka C to write a program that allocates large chunks of memory and then greps through it looking for 'good stuff'.</div><div style="font-size:small"><br></div><div style="font-size:small">So the question is how to ensure this does not happen by implementing disposal mechanisms THAT DO NOT GET OPTIMIZED AWAY.</div></div></blockquote><div><br></div><div>There are generally no absolute guarantees that the generated code is not optimized away - a future compiler may get smarter about memory lifetimes.</div><div><br></div><div>That said, I wrote an implementation that's worked pretty well across various versions of gcc and clang: <a href="https://chromium.googlesource.com/chromiumos/third_party/cryptoc/+/refs/heads/main/util.c">https://chromium.googlesource.com/chromiumos/third_party/cryptoc/+/refs/heads/main/util.c</a>.  The basic idea is to trick the compiler into not optimizing away writes to a memory destination marked volatile.</div><div><br></div><div>Here's a demo on arm gcc -O2:<br><a href="https://godbolt.org/z/q9v8dTrPb">https://godbolt.org/z/q9v8dTrPb</a> (destination range marked as 'volatile char *')<br></div><div><a href="https://godbolt.org/z/WE7q8sa1z">https://godbolt.org/z/WE7q8sa1z</a> (destination range marked as 'char *')<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small"><br></div><div style="font-size:small">See here is the thing. I can check my code and check my code but I can only check the current version of the compiler/optimizer. And some of the things I know the C# optimizer is now doing are pretty hard core. Yes, when generating assemblies, it can optimize across assembly boundaries now.</div><div style="font-size:small"><br></div><div style="font-size:small">I am pretty sure most other high level languages suffer from the same thing unless there is a mechanism to explicitly state 'do not optimize'. Same goes for things like the Montgomery ladder which isn't as reliably constant time as some people might imagine. </div><div style="font-size:small"><br></div><div style="font-size:small">Has anyone got pointers to ways to make sure this is done right?</div><div style="font-size:small"><br></div><div style="font-size:small"><br></div></div>
_______________________________________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com" target="_blank">cryptography@metzdowd.com</a><br>
<a href="https://www.metzdowd.com/mailman/listinfo/cryptography" rel="noreferrer" target="_blank">https://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</blockquote></div></div>