Ask Slashdot: Which Encrypted Cloud Storage Provider?

An anonymous reader writes "Almost three years ago, I started looking for a cloud storage service. Encryption and the "zero-knowledge" concept were not concerns. Frankly, after two weeks testing services, it boiled down to one service I used for almost 2 years. It was perfect — in the technical sense — because it simply works as advertised and is one of the cheapest for 500GB. But this year, I decided changing that service for another one, that would encrypt my files before leaving my machine. Some of these services call themselves 'zero-knowledge' services, because (as they claim) clear text does not leave your host: they only receive encrypted data — keys or passwords are not sent. I did all testing I could, with the free bit of their services, and then, chose one of them. After a while, when the load got higher (more files, more folders, more GB...), my horror story began. I started experiencing sync problems of all sorts. In fact, I have paid for and tested another service and both had the same issues with sync. Worse, one of them could not even handle restoring files correctly. I had to restore from my local backup more than once and I ended up losing files for real. In your experience, which service (or services) are really able to handle more than a hundred files, in sync within 5+ hosts, without messing up (deleting, renaming, duplicating) files and folders?"

Comments

Ooh I know this one

[symbolset]

Build a couple Backblaze boxes and work out a deal with some KC residents. That gets you 180TB offsite stuff with whatever sw leverage you want to lay on top of that.

Re:Ooh I know this one

[SuricouRaven]

Cloud is not a technical term. It's a business term.

Re:Ooh I know this one

[BrokenHalo]

2) If you are serious about actually storing stuff, get yourself a server and secure it.

I hate those FTFY posts, but if you are really serious about storing stuff, then you should do it yourself. The so-called "cloud" services might be convenient (depending on the cost and availability of your internet connection), but they are totally out of your control, especially if you care even the slightest about security.

Give it up.

[philip.paradis]

Write yourself a simple set of scripts that use rdiff-backup or rsnapshot to perform differential/incremental backups to an internal host, make a secondary mirror encrypted at a file level with GPG/PGP, and use rsync to sync the encrypted mirror to several offsite hosts. Done. If this level of security matters to you, do it yourself.

Re:Give it up.

[Rosyna]

Indeed. Mostly give up the idea of having the host encrypt files for you. You never know if they have a backdoor of some sort. Find/write software (I use Arq) to encrypt files and then send the encrypted files to a host like Amazon S3. It's really the only way for the host to have the "zero-knowledge" you desire.

Re:Give it up.

[Sun]

<plug>Or, better yet, use rsyncrypto.</plug>

The advantage is that the incremental diffs don't accumolate on your computer, making your entire archive volatile (lose one rdiff, lose everything after that point). You just sync like you always do.

Theoretically, rsyncrypto is less secure. I am, of course, far from being objective about this point, but I believe this is not a practical weakness for most people, even with the renewed (justified) paranoia. Then again, the tradeoffs are clearly discussed on the project's site, so you are free to draw your own conclusions on the matter.

Shachar

Re:Give it up.

[fnj]

I'll go you one better than rsnapshot (and make no mistake, I think rsnapshot was an absolutely wonderful idea and a superb invention).

Just use rsync to a zfs backup point. Take a zfs snapshot after each backup, or not; your call. Make zfs snapshots whenever you feel like it. There is no undue performance or storage problem with many, many snapshots. You could make one snapshot a day and have a simple cron job that deletes all the snapshots older than the last couple of weeks, except retains all the Sundays for a couple of months, all the first Sunday of the months for a couple of years, and all the first Sunday of the years forever. That would leave you with about 50 snapshots plus 1 for every year, which is very light. Or suit yourself with your own schedule.

Zfs snapshots are essentially instantaneous to make, and very quick to delete. Every single snapshot is a directly addressable representation of the entire store: every file. The differential mechanics are all handled by zfs internally. It's as if you are making a full (not differential) backup every day and somehow finding and financing a small city to store them all in. But your actual storage is only differentially larger than a single backup. OK, so far that's essentially what rsnapshot does, with a bunch of code.

The advantage over rsnapshot is efficiency and simplicity. All those zillions of hard links behind rsnapshot's strategy are time consuming to create and delete.

Obviously, either way you do have to be reasonably smart about database files, sparse files and open files.

BTW, rsyncing an encrypted fs to a remote, well, err, it doesn't really work. Because normal encryption turns small localized file deltas into completely different file contents, turning every rsync in which a lot of large files are modestly changed into a huge data transfer. You can use rsyncrypto to try to work around this, at the cost of some of the security of the encryption.

Re:Give it up.

[Sun]

Uhm, that property is exactly what you DON'T want in an encryption algorithm. There's a reason we don't use ECB mode. And if you rely on compression for security, you're doing something wrong. Anyway, if you just want to be able to diff encrypted files, what's wrong with counter mode? No need to invent a new mode, right?

I also don't understand why RSA is needed here. What's the point of asymmetric crypto when there's only one party involved?

1. Rsyncrypto is very very very far from ECB. I am hard pressed (but open to counter examples) to find a real life file that exhibits cypher text repetitions due to plain text repetitions. This is not the case with ECB, as clearly evident from the ECB wikipedia page.
2. Your statement about compression is strange. It is quite customary to compress before encrypting. Partly because compressing after encrypting makes no sense at all, but also because compression increases the bit entropy of the data, making known plain text attacks harder. It is true that rsyncrypto is more sensitive to such things than other algorithms. It is this little thing I like to call a "trade off". Anticipating your objection, ECB with compression is better than ECB without, but still pretty horrible. You will get repetitions the length of the compression blocks. Like I said above, this is not the case with rsyncrypto.
3. RSA is needed because you do not want to encrypt all files involved using the same symmetric key, but you also don't want the secret your backup depends on to need constant updating. With this scheme, you only need to reliably and securely store one key (the RSA key), but each file is encrypted with a different key.

Counter mode is horrible for this application, for two reasons:

First, any change to the file that adds or removes even a single byte causes the entire cypher text to change from that point on. This makes it quite rsync unfriendly indeed. This is not the case with rsyncrypto.

The more horrible reason, however, is that counter mode has zero resilience to key reuse. A simple XOR of the cypher texts from two encryption passes will cancel out the encryption, key and all, and leave you with a XOR of the plain texts.

Shachar

Re:Give it up.

[Agent ME]

Eh, one-time pad has exactly that property: if you use the same key to encrypt similar files, you get similar output. And nobody complains about one-time pad. ;)

That's not a one-time pad if you use it more than one time. It's extremely insecure to use a one-time pad twice. An attacker can XOR both ciphertexts to remove the keystream and be left with the XOR of both plaintexts. From there, they just have to figure out one of the plaintexts, and they can decrypt the matching parts from the other.

Why Pay Somebody Else?

[Jane Q. Public]

For the money you're paying a service, why not just hoop up an inexpensive machine for a server, put a TB or two in it, and use BitTorrent Sync?

It's pretty secure, you can share files with others, it's available for all major OSes (including iOS and Android), you don't have to mess with any 3rd parties seeing your data... what more do you want?

Re:Copy

[Anonymous Coward]

A Barracuda will always be able to help in those cases where you forget your password.

http://krebsonsecurity.com/2013/01/backdoors-found-in-barracuda-networks-gear/

Roll your own - but choose the right SW

[Anonymous Coward]

I've not tried this, but always meant to. Sparkleshare is an attempt to make an open source Dropbox - and a couple of years after I first bookmarked it it's still going strong.

You can get a cheap dedicated server for under £10 a month and roll your own based on this?

Also has client-side encryption
https://github.com/hbons/SparkleShare/wiki/Client-Side-Encryption

None of them.

[MrL0G1C]

After all of this NSA business, why would you ask which storage provider keeps you safe when clearly none of them do.

If you want your data encrypted, why would you not do it yourself, then you don't need to pay for an encrypted storage provider because you can upload your encrypted data to any storage provider. Paying extra for something you're not guaranteed to get is not very intelligent.

This article brought to you by an anonymous reader / encrypted storage provider.

Focus on your local encryption method first

[tiznom]

Your problem isn't the storage, it's whatever you are doing locally that is the issue. I've got tens of thousands of files backed up with no issues, across several devices.

You didn't mention your OS. I'll assume you are running Linux because if you are running WIndows/MacOS you are missing a fundamental weakness already.

On Linux, use EncFS which also has a nice GUI manager via GEncfsM for those that prefer it.

Using EncFS means you don't have to upload entire files when you edit them, only the changes are synced. This is efficient, open-source, and works perfectly.

Once EncFS is working, pick any cloud storage you want and sync the encrypted folder(s). I do it with Dropbox + symlinks and it is flawless, no issues for years now.

TarSnap

[broknstrngz]

tarsnap.com. Not very user-friendly, but it does what it says on the tin.

Truecrypt + Dropbox

[joelleo]

I use Truecrypt's encrypted drive containers in my local Dropbox folder. The file sync'd to Dropbox is encrypted when the sync occurs, so that is all they ever see. Because Dropbox does a binary diff of the file and only uploads the differences which makes syncing large encrypted files feasible.

I've seen some chatter that Truecrypt may have been compromised - Bruce Schneier and Snowden use it so I'll trust in their judgement.

Seafile

[Juba]

I've found Seafile to be quite good and reliable. It's a multiplatform, free software, self-hosted Dropbox alternative that provides file syncing, sharing, a web interface, and tools for team work. Libraries can be encrypted server-side.
I use it for several months now and it is both fast and reliable (much more than the owncloud versions I tested previously). It handles my whole pictures collection (about 90GB) very easily. You can install your own Seafile server (there's even a raspberry pi version), or buy storage space from them. Clients are multiplatform (Windows, Mac, Linux, Android, iPhone/iPad).