Hacker News Reader

Comment by sdfjkl | Hacker News Reader

It's not worth bothering with filesystem encryption on a VPS. Keep in mind that the hypervisor has full, unrestricted and essentially undetectable access to the contents of the virtual machine's RAM, so they can read decrypted data, private keys and cleartext passwords.

If you want even a hint of privacy, you'll have to rent some rackspace and put a tamper-resistant box of your own in there - and stop trusting it the first time it goes down unexpectedly.

View on HN

... or make sure that your cloud-based resources, whatever they are, only see ciphertext, and access them only through heavily secured machines that you hold locally. Which requires the attacker to compromise your laptop, or phone, or whatever. (Which is almost certainly still possible for an attacker with the resources of a major government that decides you're of sufficient interest, but it raises the bar a bit.)

How do you propose bootstrapping the cipher onto a "known compromised" machine in a known compromised environment?

Use full end-to-end encryption. The "known compromised" machine doesn't do the encryption or decryption in the first place; that's done at the physically secure (you hope!) endpoints.

By cloud resource, did you mean storage? In which case, sure. But if you meant to do work "in the cloud" on the cipher text's content, the under-bad-actor-control machine is one of the "ends".

I do not doubt the claim, and believe it as much as you. However, I have always wondered: how long does it take a skilled technician to do this? Is it assume to assume, if we talk luks/dmcrypt for a filesystem or something per-file like GnuPG, is the passphrase, since it is small, just stored in the same block of memory contiguously? Is it hard to find, ASLR or not?

You don't need the pass-phrase when you can get the encryption key itself. And there are several techniques to identify encryption keys and vastly reduce the search space for these, making it rather fast to extract.

This paper describes (and implements) a few of these (Chapter "Key Identification"): http://cryptome.org/0003/RAMisKey.pdf

You can't even trust your server if it never goes down.

This 5-year marketing video for police demonstrates switching a computer over to another power source without powering down:

https://www.youtube.com/watch?v=erq4TO_a3z8

There's a spectrum of concerns... Same as there's a whole range of options between "I live in a compound guarded by genetic clones of me, conditioned to do my bidding" and "my house has no doors, I trust everybody"

As such, an encrypted file system even on a VPS provides slightly more protection than an unencrypted one. If it's worth the effort depends on your threat model.

So, if you're really the person who needs a tamper-resistant box that's untrusted after unexpected downtime, even renting rackspace is a bad idea. You probably want it under physical control.

If you're however an average user, a VPS with encrypted FS provides decent protection against most casual attackers. For many of us, that's enough.

Encrypting disks can be reasonable, but for a different reason: It reduces the chance that a third party gains access to your data upon recycling of the hard-drives.

If you want to have privacy, don't let anything get onto the internet. That's been true from day one.

The NSA hasn't changed that.

It's important to understand that privacy, like security, isn't an all or nothing proposition.

Instead, they're both questions of degrees of inconvenience and degrees of difficulty.

Security might be about layers, but privacy very much is all or nothing. A given piece of information either is or is not private.

Reply on news.ycombinator.com