Hence cperciva's "Playing chicken with cat.jpg": http://www.daemonology.net/blog/2012-01-19-playing-chicken-w...

When we're talking about protection against government data requests, only companies that make sure they have access to the absolute minimum client information they possible can do truly have our backs. Everyone else just has good intentions.

Colin has it right. If you don't want to ever compromise your clients data make sure you can't read any of it. It's that simple. Anything else simply won't do.

That's why I keep recommending tarsnap to customers.

Or you could.. you know... recommend an appropriate client-side encryption tool so they can then store the archive/backup data on the storage provider of their choice...

The advantage of having client-side encryption built into tarsnap is that it encrypts only after data deduplication and compression.

Obviously there could be a tarsnap option to stream the data to be uploaded through an encryption program of your choice, but doing it just as you suggest would nerf a few of tarsnap's prime advantages.

I think you've misunderstood me.

Tarsnap is a combination client-side application and remote service.

I am suggesting instead to use/recommend one of the existing client-side tools that work similar to the tarsnap client does, but don't lock the user into a single service provider.

By using a client-side tool that just generates archives (and isn't tied to a single storage service provider), you can store them anywhere - AWS, iCloud, Google Drive, Rsync.net, a rented VPS, a friends computer, an external hard drive, all of the above. You name it.

I understood what you said, I just didn't know that there were tools in existence that are as good as or better than tarsnap at the archiving part which allow you to specify the storage location.

Edit: I used 'specify the storage location' very loosely. I.e., I realise it could mean simply piping the archive data to yet another program in the shell.

Mostly these tools would expect a local storage location and you'd schedule scp/rsync/whatever to copy to the destination of your choice.

Cool, could you please give me a few examples?

I've never used it, but I've seen people on HN recommend Attic. It dedups and encrypts. https://attic-backup.org

Personally, I use git-annex, which isn't exactly a backup tool but a general distributed file manager which can, among other things, automatically make encrypted copies of the files to various places (SSH servers, S3, Google Drive, etc).

As mentioned, there is Attic [1] and Obnam [2].

Both do dedup and encryption, Attic can also store the data remotely via SSH (either with or without installation on the remote end) and Obnam can handle remote storage to an SFTP server.

[1] https://attic-backup.org [2] http://obnam.org

I use EncFS with Dropbox.

It's an almost completely transparent user-space filesystem. Basically you store your files in a given folder, and it automatically stores a parallel encrypted copy in a different folder.

http://www.howtogeek.com/121737/how-to-encrypt-cloud-storage...

Does it do data deduplication? Doesn't sound like it to me from skimming that article.

Edit: sounds like EncFS has some significant security issues: http://sourceforge.net/p/encfs/mailman/message/31849549/. No recent information in that discussion, so I don't know whether it's all been resolved. Here's an HN discussion of the audit: https://news.ycombinator.com/item?id=7384730

To my siblings, thanks for the examples. It's good that there is a more UNIXy alternative approach.

However, until I have reason to dislike tarsnap's archiving or encryption or AWS, it's simply easier to use a single tool.

>In the latter case you will probably be forced to cough up the decryption keys.

Not if you make the users password the key.

I've always wondered, what do you do in the case of a user forgets their password and has to reset it? Reset it and lose all their data?

Seems like the only way.

If a group planned ahead they could give out some secondary kind of key. Gmail gives out these really long codes I can use to login should I not have the authenticator app.

Sorry, I might be missing something here, but would there be any tangible differences between the service provider having access to a secondary key vs them having access to the primary key if both can be used to access your data?

I'm honestly interested because I'm building a distributed system where only the user has the decryption key, and I've always just assumed that password recovery is a lost cause in such systems.

I would assume the recovery key is not stored in plain-text - it's likely hashed, similar to a password. If you need to use it, you enter the (hopefully safely stored) recovery key you have, they re-hash it and compare to the hashed one they keep.

OS X's whole-disk encryption (FileVault 2) similarly creates a recovery key at encrypt-time.

I believe it is the only way if you truly want a single user to have complete control of decryption. There are other solutions if you don't. I heard of one the other day (from MaidSafe maybe?) where you have a shared secret amongst your "friends" and if a quorum of them agree, it can reset your password. I assume this means your data is duplicated and encrypted via that shared secret as well which could be coerced I suppose.