> On Feb 23, 2018, at 11:00 , [email protected] 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.
[email protected], +1 (512) 666-7596, twitter.com/adonoho
No risk, no art.
No art, no reward.
-- Seth Godin
_______________________________________________
Cryptography-dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/cryptography-dev
