Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

"try-finally" block vs. "using" block when disposing of SymmetricAlgorithm

According to the msdn docs for System.Security.Cryptography.SymmetricAlgorithm

Note that when using derived classes, it is not enough, from a security perspective, to simply force a garbage collection after you have finished using the object. You must explicitly call the Clear method on the object to zero out any sensitive data within the object before it is released. Note that garbage collection does not zero out the contents of collected objects but simply marks the memory as available for reallocation. Thus the data contained within a garbage collected object may still be present in the memory heap in unallocated memory. In the case of cryptographic objects, this data could contain sensitive information such as key data or a block of plain text.

All cryptographic classes in the .NET Framework that hold sensitive data implement a Clear method. When called, the Clear method overwrites all sensitive data within the object with zeros and then releases the object so that it can be safely garbage collected. When the object has been zeroed and released, you should then call the Dispose method with the disposing parameter set to True to dispose of all managed and unmanaged resources associated with the object.

What I'm getting from this is that I have to use a try-finally block to dispose of my algorithm, like so:

SymmetricAlgorithm symmetricAlgorithm = SymmetricAlgorithm.Create()
try 
{
     //stuff
}
finally
{
    symmetricAlgorithm.Clear();
    symmetricAlgorithm.Dispose(true)
}

I wouldn't be able to use the more concise using block

using (var symmetricAlgorithm = SymmetricAlgorithm.Create())
{
    //do stuff
}

because it won't clear the memory. It will only mark it for collection. Is that correct? Thanks for the help.

like image 670
Vish Avatar asked Jun 29 '11 21:06

Vish


1 Answers

[calling Dispose] will only mark it for collection. Is that correct?

No it is not correct. You have a misunderstanding of what "Dispose" does. This is a very common misunderstanding.

Let me be super clear on this point: "Dispose" in of itself has absolutely nothing to do with garbage collection. There's nothing special about "Dispose" that you couldn't do in any other method with any other name. Many people believe the following myths:

  • Calling a method called Dispose on an object that implements an interface called IDisposable "marks" the object for collection.
  • The garbage collector calls IDisposable.Dispose when an object is collected.

Neither of those myths are true.

The facts are:

  • Calling "Dispose" when you are done with an object is a convention that is intended to ensure that non-managed resources are cleaned up before the garbage collector gets around to cleaning up the managed memory resources associated with an object.

  • The garbage collector decides when an object is to be collected solely based on whether any reference to the object is reachable through a known-to-be-alive object. Calling "Dispose", or any other method, does nothing to make an object unreachable.

  • The garbage collector will (sometimes) call a "finalizer" (aka "destructor") on an object shortly before it is collected. As a convention, the author of an object typically chooses to have the finalization of an object be identical to its disposal. But again, this is just a convention.

  • As a convention, an object that has just been disposed should tell the garbage collector that the GC can safely skip finalization of this object when it eventually becomes unreachable.

"Dispose" is just a method. If that method happens to tell the GC a bunch of stuff, like "by the way, someone has already taken care of finalizing this object", the method is free to do so. There is no magic inherent in "Dispose". You could write up your own method "MyDispose" and your own interface "IMyDisposable" that did the same thing; the GC neither knows nor cares what conventions you have chosen to organize your code so that it releases unmanaged resources early.

like image 55
Eric Lippert Avatar answered Oct 03 '22 15:10

Eric Lippert