> On Feb 23, 2018, at 11:00 , cryptography-dev-requ...@python.org wrote:
> However, as several others have explained, this does not prevent the memory
> getting stored on the disk in some manner.


        You are absolutely correct. Prudence is required. Your advice to 
skeptically believe that I have fully protected myself from key snooping is 
noted and embraced. Note that I am attempting to make the key's exposure last 
for as short a time as possible. Certainly you support this goal?

        I ask each cloud vendor what their VM swap encryption policy is. Some 
claim that just their disks are encrypted. That encrypted swap is not 
necessary. These are also the same folks who believe secrets are safe as 
environment variables. (*cough* Docker *cough* Heroku *cough*) At least AWS is 
now offering explicitly secure secret parameters. Yes, we should know exactly 
what are the swap and encryption policies of each of the function execution 
environment vendors. When pressed at conferences like OSCON, these vendors fall 
back upon the “Top Men” argument. They employ “Top Men” who never make 
mistakes. (Nor will the org stand behind them not making mistakes.) 

        BTW, this is the same “Top Men” defense offered by AWS when I ask to 
see the results of any third party security audit of Boto3, the AWS access 
library. I hope their “Top Men” are truly “Top Men.” More transparency would be 
welcome. In particular, I’ve inquired of the AWS Encryption SDK team how they 
control the lifetime of their cached, unencrypted credentials. They did not 
have a good solution nor did they explicitly address exposed key lifetimes. I 
believe a member of that team has already participated in this thread. For 
which I thank him. Here’s a critical patch notice: Amazon Linux AMI Security 
Advisory: ALAS-2018-939, <https://alas.aws.amazon.com/ALAS-2018-939.html 
<https://alas.aws.amazon.com/ALAS-2018-939.html>>. Clearly, this threat of 
cross process snooping is taken seriously by AWS and, I assume, will soon be 
addressed in their other services. One assumes this would be done relatively 
quickly for the AWS Encryption SDK. I assume each of the cloud vendors views 
Meltdown with similar concern. I, as a user, have a responsibility too. I 
should not leave unencrypted key material lying around my address space. That 
is why I use specialized services that exploit hardware security modules. 

        Hence, I’ve come here to address the exposed key problem myself instead 
of depending upon the AWS Encryption SDK. This open and engaged community has 
rewarded my effort. Thank you.

        More folks should be asking for public disclosure of these important 
security policies.

        In my case, I am attempting to precisely control the lifetime of these 
secrets. I am attempting to minimize the time I am exposed. With the advice and 
guidance of this team, I feel I can now track the explicit lifetime and 
disposition of my EC and AES secrets. I’ll leave password strings to another 
time. BTW, gc.collect(generation=0) has surprisingly little impact on my test 
routine’s execution speeds. It appears to properly cause the collection of my 
ec.privateKey. In other words, once again, the pyca/cryptography team has 
implemented their system well. Bravo!

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

Reply via email to