Michael Jung mjung@iss.tu-darmstadt.de writes:
When a context is released, the corresponding heap based struct variable is zero'ed before being released. When the CryptDestroyHash function is called, the corresponding context is checked if it was already being zero'ed out. Note that a heap location is read, which has already been released. However, this only happens in case of incorrect api usage. This is not guaranteed to work, but it should be more robust.
I suspect that windows does it in a similar way. Looking at the actual values of HCRYPTHASH variables shows that those are addresses in WinXP SP2. Considering this, I think that the only 100% clean way to implement this behaviour would be to have a list of currently existing hash and key objects in the context, which then would be marked invalid when the context is released.
I don't think there's any need to go that far, and I doubt Windows does either. The usual way to handle that is to store a magic number in the struct and clear it on destroy; this is more robust than simply zeroing the pointer since even if the block gets reused it's very unlikely that the proper magic number would get restored.