> 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.
tux, 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! 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