[Cryptography] Making sure memory erasure is not optimized away

[Stephan Mueller]

Am Donnerstag, 25. August 2022, 21:24:57 CEST schrieb Phillip Hallam-Baker:

Hi Phillip,

> [Before we start, use language X instead is not an answer here.]
> 
> 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.
> 
> 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'.
> 
> So the question is how to ensure this does not happen by implementing
> disposal mechanisms THAT DO NOT GET OPTIMIZED AWAY.
> 
> 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.
> 
> 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.
> 
> Has anyone got pointers to ways to make sure this is done right?

See attached. I used this to validate the Linux kernel memory clearing 
implementatino.


Ciao
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memset_secure.c
Type: text/x-csrc
Size: 4035 bytes
Desc: not available
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20220827/384b57f3/attachment.c>