Howto fix the problem: [LWN.net]

Howto fix the problem:

Posted Oct 15, 2009 4:09 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

the only issue with encrypting the data before you send it up to the cloud is where you store your encryption keys.

if you loose those keys you loose your data, so it does no good to store your data in multiple places if your keys only exist on one machine.

for many people who do not have good ways to store the keys, they are actually better of in many ways with the data in the clear so that they can pull it back down to a replacement machine if something happens to the first one.

yes, this is not good from a security point of view, but in this case the security risks need to be balanced against the availability risks. which one is more important will vary from person to person.

Howto fix the problem:

Posted Oct 15, 2009 5:33 UTC (Thu) by drag (subscriber, #31333) [Link]

For important things I write down my passwords and put them in my wallet.
Then I also save another copy somewhere else.

The choice is simple really.

Do you want to keep track of a password..
or depend on the security of every machine in Canonical, every workstation
in the data center that people come into contact with that people use to
access administrative portions of the "cloud"? Do want to trust the
security of every machine on the cloud? Do you want to trust every
employee, every administrator, every janitor that access to the machines
that house your data?

All in all it is a massive undertaking trying to keep data safe and
security for what will be practically forever if you take the approach that
users should take no responsibility for their data!

And it's hugely expensive undertaking, to boot. It is virtually impossible
to do in correct manner if you think about it.

Meanwhile if your job is to handle already encrypted data then it is much
simpler. You could post your customer's data to craigslist and not have to
worry about it.

It is not difficult to print out copies of your keys into ascii armor
format and put a hard copy in a secure place. People do that shit all the
time with all sorts of documents. They rent out lock boxes in banks, go and
get fire-proof safes at Walmart for 50 bucks, and all sorts of stuff like
that.

(and, frankly, the notion that you should never write down your passwords
or create hard copies of your keys is one of the worst pieces of security
"common sense" I have had the misfortune to run into over and over again.)

If you value your data and want to be able to use Ubuntu's cloud service
for anything other then a toy or a cheap way to sync address books then
client-side encryption is just the obvious way to go from my perspective.
I could be wrong, but it makes sense to me.

Howto fix the problem:

Posted Oct 15, 2009 7:22 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

do you want to run the risk of loosing everything if you loose the password? or are you willing to take the risk that someone will break in through the Canonical security, download your data, dig through it to find something interesting, and take action on it?

I would not use their service personally (I would do the client-side encryption and keep track of the key), but I know a lot of users who I would recommend use something like this so that when they trash their system badly enough that they need to reinstall their systems they will still have their data. Many of these users have trouble remembering one password for their system, let alone taking appropriate actions to protect an encryption key.

Howto fix the problem:

Posted Oct 15, 2009 8:02 UTC (Thu) by ekj (subscriber, #1524) [Link]

I have a laptop, it does backups to a fileserver in the basement. It also does encrypted backups to a backup-service on the internet. The latter is there for the case that our house is burglarised, or burn down, or some other disaster destroys BOTH laptop AND fileserver at the same time.

And yes, if that happens AND I've forgotten the password for the encryption, it's acceptable for me to suffer data-loss. We're talking miniscule probabilities here. (I'd have to forget the password I use for logging in every day at the precise same time that something catastrophic happens at home. That's a level of risk that is entirely acceptable to me.)

Sending my entire digital world to some random company on the internet, for them and anyone that aquires, breaks into, subpoenas or otherwise gains access to their servers ? No thank you, not interested.

Howto fix the problem:

Posted Oct 15, 2009 17:39 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

you are not the common case (neither am I), we can and do take steps like this so that we do not have a single point of failure.

we also don't need a service like this because we can replicate and protect things ourselves.

this service is intended for people who otherwise are not backing things up, let alone replicating an encryption key for the backup.

Howto fix the problem:

Posted Oct 15, 2009 13:19 UTC (Thu) by sourcejedi (guest, #45153) [Link]

Won't help. They still need their launchpad password.

If you can trust someone to hold your launchpad password in escrow, you can surely trust them to do the same with your encryption password.

In practice, I suspect you can just reset your launchpad password by email. So you have to rely on your ISP resetting your email password when you forget _that_. And that they don't go bust or disconnect you for using too much bandwidth making online backups :-)...

Yes, many people are likely to accept this service given the choice. But this is a pretty low bar to pass. We can and should do better.

Howto fix the problem:

Posted Oct 15, 2009 16:23 UTC (Thu) by drag (subscriber, #31333) [Link]

> do you want to run the risk of loosing everything if you loose the
password? or are you willing to take the risk that someone will break in
through the Canonical security, download your data, dig through it to find
something interesting, and take action on it?

It is easy to keep a password or key safe. Print it out into a hard copy
and put it in a secure place with the rest of my critical documentation
(automobile title, birth certificate, mortgage information, etc etc)

Then it is win on both sides. As long as you make it absolutely known that
Canonical has no knowledge and cannot ever retrieve the password for you
then I think that is acceptable.

I suppose if customers trust Canonical then they can just send them the
key/password to keep track of. It would be a lot easier to keep that safe
then a "cloud".

Howto fix the problem:

Posted Oct 15, 2009 17:37 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

you would be amazed at the number of people so do not protect their important documents like this.

Howto fix the problem:

Posted Oct 15, 2009 10:14 UTC (Thu) by nix (subscriber, #2304) [Link]

If the encryption key is relatively 'bare' (i.e. it's not made clear in the keyfile what service's data it's encrypting), just keep the encryption key on a USB key. Even if you drop it on a train, nobody who picks it up will have a clue what it's meant to decrypt.

(Now everyone else can tell me how stupid this idea is.)

Howto fix the problem:

Posted Oct 15, 2009 16:33 UTC (Thu) by drag (subscriber, #31333) [Link]

I save my important passwords on a LUKS-encrypted SD card. (it is small and
fits in my wallet and my laptops have SD support)

The LUKS password is relatively simple (plain english phrase), but it
should be enough to protect it if I drop it somewhere.

When you plug it into a Linux Gnome desktop automatically prompts you for
the password and opens up the folder for you. So it is very convenient.

I can't recommend this approach to normal folks because it only works if
you plug it in rarely. If you leave it plugged in all the time then it is
no better then having it in a folder.

But what is better (in terms of security) would be to print out keys into
ascii armor format or write down passwords to a hard copy. That way they
are impossible to hack! A person would have to physically break into my
house and search through my drawers and filing tower to find it.

Howto fix the problem:

Posted Oct 15, 2009 17:36 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

and a flood or fire would destroy your printout as well as your computer.

Howto fix the problem:

Posted Oct 15, 2009 11:06 UTC (Thu) by endecotp (guest, #36428) [Link]

> I am very uninterested in any sort of "cloud" backup
> scheme that does not integrate encryption on the client
> side.

Does anyone know how to get rsync-like functionality with the data at the other end stored encrypted?

I currently use rsync over ssh for some of my backups, so the data is encrypted on the wire but unencrypted on the remote disk. When I set this up I tried to find a way of storing the remote copy encrypted without losing rsync's efficient incremental transfers, but I didn't find anything satisfactory. Any ideas?

Check out Tarsnap

Posted Oct 15, 2009 12:26 UTC (Thu) by fghorow (subscriber, #5229) [Link]

From Colin Percival, the (Free?)BSD Security officer.

Just a happy user of the service.

(Be aware, it is a *for a fee* service, but the micropayments are truly micro!)

Howto fix the problem:

Posted Oct 15, 2009 13:09 UTC (Thu) by sourcejedi (guest, #45153) [Link]

Try encfs + rsync. Encfs will encrypt both file content and names. (It won't hide filesizes, directory topology, permissions, and the approximate _lengths_ of filenames).

http://ubuntuforums.org/showthread.php?t=148600

Howto fix the problem:

Posted Oct 15, 2009 16:01 UTC (Thu) by zooko (subscriber, #2589) [Link]

Tarsnap seems like a well-engineered system, from reading the author's blog, but as far as I know
the server-side code is proprietary. The Tahoe-LAFS project (I'm a contributor) has excellent
encryption and erasure-coding features and if you like duplicity you can use Tahoe-LAFS as a
backend for duplicity. Also Tahoe-LAFS comes with its own integrated backup system which has
different trade-offs than the duplicity backend. (Duplicity does deltas for you, but you can't view or
download your files without going through duplicity. The Tahoe-LAFS integrated backup doesn't do
deltas, but it stores the files in a time-machine-style layout which you can browse and download
through the web.)