[Cryptography-dev] Destroying keys and secrets…

Matt Bullock matt.s.b.42 at gmail.com
Fri Feb 16 16:54:23 EST 2018


This is an area I've spent a fairly significant amount of time
investigating. My conclusion was "no, there is no reliable way to do this",
but I'd love to be proven wrong.

The fundamental problem is that how exactly <Python implementation> stores
variables in memory is not defined as part of the implementation
requirements, and so even if you can figure out a way to wipe a value from
memory on one implementation, there is no guarantee that it will work on
any other implementation.

With CPython, you /can/ technically use "ctypes" to read and write memory
directly, and by introspecting a similar object (say, an arbitrary string
with known value), you can reach in and overwrite data that is /probably/
the data you're trying to wipe out.

Unfortunately, this approach makes a lot of assumptions about how CPython
actually structures variables in memory: assumptions that may or may not be
valid today and may or may not be valid in the future (or the past, for
that matter). /At best/ the only thing you can reasonably say is that this
/probably/ works for the specific version of the specific implementation
you have tested it on, and that it /might/ not have adverse side effects.

I've also toyed with the idea of making a C extension analogous to the
SecretKey structure from Java, which never lets the actual key material out
of the structure, but in order to actually do anything with the key
material it still needs to surface to Python at some point, which puts us
back in the same position we started with. ..unless we were to re-implement
all of pyca/cryptography in Cython, but that's a thought for a different
time...

   --Matt

On Fri, Feb 16, 2018 at 1:25 PM Andrew Donoho <awd at ddg.com> wrote:

> Gentlefolk,
>
>
>
>         Apparently, my Google-fu is weak and I come seeking advice.
>
>         Secret management is important. In particular, I want to make sure
> that any secrets I decrypt are erased from memory before the storage is
> reclaimed by the VM. In other environments, I would just dig into each
> object until I get the pointer for the storage and then bang zeros, ones
> and randomness into the block. Then garbage collection would proceed apace.
>
>
>
> Here’s an example from the cryptography documentation, <
> https://cryptography.io/en/latest/hazmat/primitives/symmetric-encryption/
> >:
>
> >>> import os
> >>> from cryptography.hazmat.primitives.ciphers import Cipher, algorithms,
> modes
> >>> from cryptography.hazmat.backends import default_backend
> >>> backend = default_backend()
> >>> key = os.urandom(32)
> >>> iv = os.urandom(16)
> >>> cipher = Cipher(algorithms.AES(key), modes.CBC(iv), backend=backend)
> >>> encryptor = cipher.encryptor()
> >>> ct = encryptor.update(b"a secret message") + encryptor.finalize()
> >>> decryptor = cipher.decryptor()
> >>> decryptor.update(ct) + decryptor.finalize()
> 'a secret message’
>
>
> The `key` above is a `bytes` object. It has storage somewhere. Even though
> it is a read-only Python object, I can pierce the abstraction, if I have
> to, with C.
>
> My question is: has someone else already done so and published the handful
> of methods needed?
>
> If not, should this be an API added to cryptography?
>
>
>
> Anon,
> Andrew
> ____________________________________
> Andrew W. Donoho
> Donoho Design Group, L.L.C.
> awd at DDG.com, +1 (512) 750-7596 <(512)%20750-7596>, twitter.com/adonoho
>
> Doubt is not a pleasant condition, but certainty is absurd.
>     — Voltaire
>
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20180216/0af8e3ad/attachment.html>


More information about the Cryptography-dev mailing list