[toomuchtodo]

Once you have physical access, no need for the private key. Unless you're encrypting all of your data, they'll just snapshot your VM to go through it later (or your EBS volume, depending on where the data is stored).

And yes, you can write out whatever is in RAM just as easily.

Did everyone forget that "cloud" means "someone else fully controls the hardware"?

[cpucycling]

Right, but this has nothing to do with the practice of protecting your private key.

That the most sophisticated attacker with the most resources may be able to tunnel into your data is no excuse for lax security.

[toomuchtodo]

I was replying to this parent post: "I email myself my encryption passwords so that I - and any interested government agencies - can log in without me needing to remember them all the time."

Yes, you should protect your private key. No, protecting it isn't going to stop a government agency. A VM is not Schroeder's cat: you can peak without there being any evidence. That was my point. Apologies if I wasn't straightforward in my explanation.

[derefr]

It's actually kind of hard to remember sometimes that cloud-compute providers don't employ some sort of homeomorphically-encrypted VM containers. Even though they are completely impractical and have never even seen a proof-of-concept, the idea is so intuitive that I bet if you asked a random non-IT manager if Amazon could read memory or CPU registers on the instances his employees have running on EC2, he'd say no. "Because obviously," he'd pontificate, "nobody would be using cloud-computation otherwise."

[toomuchtodo]

I agree with this.

If I want my data to be very secure, its going to run on VMs that boot and run entirely in RAM, read the encrypted data in from persistent storage, and have their power controlled by an intrusion detection system. If you attempt to open the rack, power is removed, unencrypted data is lost, and everything is safely encrypted at rest.

You would only need this security for the most sensitive types of data though.