Ask Slashdot: Which Encrypted Cloud Storage Provider? 200
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?"
Why Pay Somebody Else? (Score:4, Informative)
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:Give it up. (Score:5, Informative)
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.
Truecrypt + Dropbox (Score:5, Informative)
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.
Re:Give it up. (Score:4, Informative)
<plug>Or, better yet, use rsyncrypto [lingnu.com].</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
Seafile (Score:4, Informative)
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).
Re:Give it up. (Score:4, Informative)
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. (Score:4, Informative)
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. (Score:4, Informative)
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.