[Python-ideas] Specification of procedures to store cryptographic secrets

[Terry Reedy]

On 2/3/2013 7:18 PM, desnacked at riseup.net 
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.

-- 
Terry Jan Reedy