-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Secure memory wiping #7
Comments
I'm not sure this is going to be relevant for this. Ideally we won't be writing any crypto ourselves and will just be making an API over top of a backing library like OpenSSL. |
Most crypto libs don't handle memory management themselves. The application is responsible for allocating and freeing blocks of memory. Usually a consumer of a crypto lib allocates a fixed size buffer on the stack and applies the buffer to a crypto function. The buffer should be whipped with memset_s() afterwards. The page [2] explains it in great detail. |
Yup, we can add a |
We can implement this for |
I think #845 should close this for now? |
The patch in http://bugs.python.org/issue17405 might be interesting for cryptography. It contains my research on secure memory wiping and a C89 implementation of C11's memset_s() function.
Quote:
Compilers like GCC optimize away code like memset(var, 0, sizeof(var)) if the code occurs at the end of a function and var is not used anymore [1]. But security relevant code like hash and encryption use this to overwrite sensitive data with zeros.
The code in _sha3module.c uses memset() to clear its internal state. The other hash modules don't clear their internal states yet.
There exists a couple of solutions for the problem:
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
[2] https://www.securecoding.cert.org/confluence/display/seccode/MSC06-C.+Be+aware+of+compiler+optimization+when+dealing+with+sensitive+data
The text was updated successfully, but these errors were encountered: