Idea: mutable types for keys and better memory handling

[earonesty]

Python is notoriously a "bad language" for crypto because of the lack of memory management tools, but we can try.

Each can be implemented separately, but all are probably necessary if we want some decent chance of the library being safe.

• private and symmetric key types could internally be represented as opaque openssl references, not ints or bytes ... which are automatically zeroed on close() or __del__ methods

• all bytes key arguments to functions allow bytearray, which "finally" zeroes the mutable argument after use/construction of the internal representation (eventually we could deprecate the use of immutable types for secret key material)

• add explicit with block handlers that call close() methods of private and symmetric keys, allowing for safe use

• document the use of close() in all private/symmetric keys for longer-term handles

[earonesty]

I use tests like this to help discover potential issues:

https://gist.github.com/earonesty/e24df86bf815031479e6b761dccd100f

[earonesty]

This package makes testing for "secrets in memory leaks" easier: https://github.com/AtakamaLLC/pysecbytes

[alex]

On deeper review, we do not intend to add APIs for this. While they do provide some value, it would come at the cost of considerable complexity (new APIs, all existing APIs needing to be updated to handle "closed" states), and frankly it's incredibly difficult in Python for a user to correctly use any of these -- even simple idioms like:

with open("path/to/key") as f:
    with load_der_private_key(f.read()) as key:
        # ...
    # key is cleared here

are subtly wrong

Notwithstanding this, in practice lots of progress has been made on this goal, via our objective of using more memory safe code, that is not prone to disclosing the contents of memory on a whim. We have removed substantial attack surface since this issue was filed.