Some comments:

- I don't have small files which just contain one function. Do you expect that we may add other security-related functions? You may add a "pysecurity.c" file. (It's maybe a stupid idea.)

- Why only a few hash functions (sha1, sha3)? We must use the same policy for all hash functions: always force memset() or never use memset().

- Why not touching the ssl module? PySSL_dealloc() and context_dealloc() for example.

- Would it be possible to use a custom memory allocator which would memset() the memory before releasing it for security related objects? If yes, would it be possible to switch it on or off at runtime? It may be interesting if memset() has a visible overhead on performances.

Antoine wrote:

"I think I still don't understand the use case within Python. Why would you want to clear the internal state of a hash object? If you can read the computer's memory, you probably have access to sensitive data already?"

Data are usually duplicated in many places. I'm also dubious that memset() adds any security. If it has no impact on performance, why not using memset() for hash functions and security modules like ssl.

But for example, ssl.RAND_bytes() stores its result in a common bytes object. The bytes type doesn't use a custom memory allocator, and so the secret random bytes will still be present in memory after the bytes object has been "deleted". If you really care of security, you may need a security allocator which reset all memory blocks on free(), not only a few modules.

And what happens when you pass data to a C module which copies the data somewhere. Does it later reset correctly the memory when data becomes useless?

@Christian: Do you have examples of other projects clearing the memory when objects are destroyed?