> On Feb 17, 2018, at 11:00 , cryptography-dev-requ...@python.org wrote: > > Date: Sat, 17 Feb 2018 04:04:00 +0100 > From: Alex <python-cryptogra...@qu3.org> > To: cryptography-dev@python.org > Subject: Re: [Cryptography-dev] Destroying keys and secrets? > Message-ID: <d057417f-ce19-1a60-4d18-18680c562...@nigl.biz> > Content-Type: text/plain; charset="utf-8" > > You might have a look at: > https://github.com/dnet/pysecstr > > Here is a longer description about the used method: > https://www.sjoerdlangkemper.nl/2016/06/09/clearing-memory-in-python/ > > Disclaimer: This is not a recommendation just a hint for further > exploration. Be also aware that you can't control if and when Python > swaps memory to disk.
Advertising
> On Feb 16, 2018, at 16:44 , cryptography-dev-requ...@python.org wrote: > Date: Fri, 16 Feb 2018 21:54:23 +0000 > From: Matt Bullock <matt.s.b...@gmail.com> > To: cryptography-dev@python.org > Subject: Re: [Cryptography-dev] Destroying keys and secrets? > > 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… > On Feb 16, 2018, at 16:44 , cryptography-dev-requ...@python.org wrote: > > Date: Fri, 16 Feb 2018 15:44:39 -0700 > From: John Pacific <m...@johnpacific.com> > To: cryptography-dev@python.org > Subject: Re: [Cryptography-dev] Destroying keys and secrets? > Message-ID: > <cahr1pup6wvzdho02yfozg4mwttdz3cxrkpjssbuj1wtlupu...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Afaik, there is no reliable way to do this in Python. > > I have taken some time to implement some OpenSSL methods that at least > clear the memory on private numbers before freeing it in BIGNUMBER > operations. > > See the PR here: https://github.com/pyca/cryptography/pull/4072 > > However, as it comes for the Elliptic curve Gentlemen, Thank you for your fine answers. They comport with my expectations. Without boring you with my details, I am doing something similar to an ephemeral ECDH exchange. The secrets have a very short lifetime. Hence, I’m not worried about swapping to disk. (Though most of the cloud vendors claim the swap vm is encrypted.) For example: secret_bytes = os.urandom(384//8) secret_int = int.from_bytes(secret_bytes, byteorder='big') private_key = ec.derive_private_key(secret_int, ec.SECP384R1(), backend) I would like secret_bytes, secret_int, and private_key to be zeroed-out before I exit the function. I want as precise an object lifetime as possible. While I fully understand the values of a library maintainer wishing to have a robust solution for all supported versions and runtimes, I have explicit control of this function and its execution environment. I’m more concerned about revealing the secret in a hostile cloud. In particular, I don’t have the string aliasing problem. Yes, this is a fragile and extremely hazardous solution. OTOH, the industry just freaked out about Meltdown. It behooves us all to manage key lifetimes carefully. As I dig into examining this problem further, I assume the ec.derive_private_key() function takes a conservative approach and doesn’t ever copy the secret_int? If I’m living well, banging the bytes in secret_bytes might hit the only copy of the secret. Depends upon whether int.from_bytes() copies the storage of an immutable source. Again, thank you for your answers. I’ll keep you posted with my progress. Anon, Andrew ____________________________________ Andrew W. Donoho Donoho Design Group, L.L.C. andrew.don...@gmail.com, +1 (512) 666-7596, twitter.com/adonoho No risk, no art. No art, no reward. -- Seth Godin _______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
