Is it common to implement crypto software in such a way that sensitive buffers are overwritten before free'ing memory? For example when they contain a private key or the plaintext message.

2 Answers 2


It is common but a bit of a myth, too. In older days, the overwrite was felt to be important because of the following:

  • Some widely deployed operating systems (in particular Windows from the "3.1" lineage, up to and including Windows 98 and Millenium) did not zero out memory pages before giving them to applications, so an application could obtain excerpts of old memory from another application.
  • Data in RAM may leak to the disk through virtual memory.
  • It was believed at some point that "partial leakage" could be prevalent, e.g. that a read-only buffer overflow could reveal part of the RAM but not everything.

These properties have gone quite stale nowadays. In particular, modern operating systems (including Windows 2000, XP and successors) do zero out pages systematically. Also, swap file usage has diminished; devices like smartphones and tablets don't use swap at all, and are happy with that (and I also do as such on my laptop computers). More importantly, people have begun to understand that the problem of leaked data has a large scope: when you decrypt a private message, the private key is indeed a piece of sensitive data, but so is the message itself. And the memory buffers used to display the said message on the screen, too. As well as all the temporary buffers for the algorithm which computed how the private text had to be broken down into properly justified paragraphs for display. And so on.

At the same time, the software ecosystem has evolved, and we now use a lot more programming languages which allocate memory through a garbage collector (e.g. Java, C#, Python, PHP, Javascript, Perl, Ruby... all use a GC). The efficient GC algorithms move objects around in RAM, transparently. And by "move" I really mean "copy". A consequence is that "wiping out" memory from the program itself no longer guarantees that no trace of the data remains.

The synthetic conclusion is that wiping data from application code is a poor response to the overall problem of data leakage. It is common, but that's not the same as recommended. If the local security model calls for such wiping out at all, then it should be done in a systematic and system-wide fashion, by the memory allocator (e.g. the GC, for languages which are GC-based), not by cluttering the application code with explicit calls to memset().

One first step, which is easy enough to apply, is to see whether you could not just deactivate swap space altogether. This would remove the source of the most serious leaks (leaks to physical mediums).


Yes, and not just crypto software, even normal software that saves insensitive information in memory like private key and password.

Its recommended hold these data for short time in memory and then overwrite it (not just delete).

The risks behind this are possibilities for hibernate, memory dumping, and copying memory into swap file.

Therefore, its recommended to overwrite memory and use it for very short time as possible.

Please see this project: Buffer with overwrite protection and memory allocation on demand also it has further explanation and real example.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .