[Cryptography-dev] Cryptography-dev Digest, Vol 54, Issue 2

[Andrew W. Donoho]

> On Feb 17, 2018, at 11:00 , cryptography-dev-request at python.org wrote:
> 
> Date: Sat, 17 Feb 2018 04:04:00 +0100
> From: Alex <python-cryptography at qu3.org>
> To: cryptography-dev at python.org
> Subject: Re: [Cryptography-dev] Destroying keys and secrets?
> Message-ID: <d057417f-ce19-1a60-4d18-18680c56279a at 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.



> On Feb 16, 2018, at 16:44 , cryptography-dev-request at python.org wrote:
> Date: Fri, 16 Feb 2018 21:54:23 +0000
> From: Matt Bullock <matt.s.b.42 at gmail.com>
> To: cryptography-dev at 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-request at python.org wrote:
> 
> Date: Fri, 16 Feb 2018 15:44:39 -0700
> From: John Pacific <me at johnpacific.com>
> To: cryptography-dev at python.org
> Subject: Re: [Cryptography-dev] Destroying keys and secrets?
> Message-ID:
> 	<CAHr1PUP6Wvzdho02YfoZg4mWttdz3CXRkPjssBUJ1wtLuPUBYQ at 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.donoho at gmail.com, +1 (512) 666-7596, twitter.com/adonoho

No risk, no art.
	No art, no reward.
		-- Seth Godin