On 2/3/2013 7:18 PM, firstname.lastname@example.org wrote:
Some hours ago I sent an email to python-crypto asking how to securely wipe cryptographic secrets from memory: http://mail.python.org/pipermail/python-crypto/2013-February/001170.html
Antoine said that cryptographic secret wiping could be achieved if one uses bytearrays carefully and then overwrites their contents after use. I
I presume he meant with CPython with its non-compacting gc on current major OSes. Perhaps the system also needs to be unloaded enough that the memory is not written to disk. Or the secret is written and erased before that would happen.
agree that this sounds reasonable, but I think it would be even better if that was a documented property of bytearrays.
I do not think such a low-level special-case property would be appropriate. Python is a high-level languages for manipulating fairly abstract objects defined by interface and behavior. The reference manual defining the language intentionally says almost nothing about the hardware and memory of an implementation. This is partly why Python is relatively easy to read and mentally execute in a human brain. One usually does not need to mentally simulate a linear byte memory.
If that property of bytearrays was specified in the Python standards, it would be easier for people who write cryptographic applications and libraries to use bytearrays correctly, and it would also guarantee that this property won't change in future versions of Python.
This would mean that Python could not run on hardware that made the guarantee impossible. What if a future OS ran directly off an SSD, either dispensing with current DRAM, or using it as the outer cache layer? My understanding is that SSDs run independently with their own os and that external access is to logical rather than physical memory. What if a farther future system had a write-once, read-many, never-erase petabyte or exabyte 3d cube memory, with the SSD only serving as an index? Of course, it is possible that security concern will figure into future designs.
The statement 'del x' only means "break the association between the name 'x' and the object currently associated with 'x'". If that is the last link to the object, it becomes inaccessible from Python and *eligible* to be physically deleted. What what happens in concrete hardware is explicitly not Python's concern. From 3.1. Objects, values and types:
"Objects are never explicitly destroyed; however, when they become unreachable they may be garbage-collected. An implementation is allowed to postpone garbage collection or omit it altogether ..."
Furthermore, it would help authors of cryptographic libraries to design their APIs and internal functions in a way that would allow the secure erasure of sensitive data.
I agree with Dustin that you need a 3rd-party crytobytes module. It could be specific to OS and hardware, keep up with changes, and refuse to run if the required guarantees cannot be met.
Would this make sense or am I asking too much from Python?
To me, it makes perfect sense for you to want a cryptobytes class that does exactly what you want it to do. And, again to me, you are asking too much for such to be part of the stdlib. Whether you are asking too much of any particular OS is beyond my knowledge. If the OS can provide the guarantees, a 3rd party Python wrapping should be possible.