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.

Re:Ooh I know this one

[mlts]

I treat cloud storage as another media type, with its advantages and disadvantages:

Optical, once the disk is finalized, is resistant to tampering, but suffers from bit rot.

Hard drives are not archival media, but they are relatively inexpensive, quick, and easy to use.

Tapes are great for long term archiving, but modern tape drives are expensive.

USB flash drives are cheap and easy to use, but data can vanish from them at any time.

MicroSD cards are excellent for data per volume, but they are relatively slow, and just like USB flash drives, data can vanish, and vanish forever and not be recoverable.

The cloud is "just" another media type. Its advantage is that in theory, stuff stored is stored fairly robustly. However, because the data is stored physically out of one's control, it is only prudent to assume that it is accessible (and alterable) to all and sundry, just like it would be if stored on a public anonymous FTP server. With this in mind, encrypting (and signing) all data before sending it offsite is not a best practice, it is basic sanity.

SLAs are a joke. Good luck suing if the other side breaches their side of the contract, even if they have a SLA that supposedly guards your data. Of course, if a cloud provider goes under, the next owner of the physical servers will own the data on them, free and clear. Business bank records and payroll database? It can be a BitTorrent for all to download, and there is nothing that can be done.

So, cloud storage has its uses. It is fairly fault tolerant, it is durable. However, one needs clientside encryption, no matter what.

Re:Ooh I know this one

[duke_cheetah2003]

With you on this. May not be terribly user friendly, but securely storing things on 'cloud' services is only something YOU can do.

The last thing you want when securely storing data is some cookie cutter solution someone else designed.

I've written about this before.. I use EC2 myself, with OpenVPN for transit and truecrypt on the server to secure my data.

Is it perfect? No. It is easy to use? For the average guy? No. But I think it's easy to use, I run samba over the openvpn. Once set, its just a matter of mounting network drives and copying files. I dunno how you can get much easier. I also can't see how it could possibly get any more secure. Well, ok I could drop truecrypt and encrypt on my end so nothing is ever visible on the server itself in the clear (despite the server being pretty much inaccessible without the openvpn key) but that's not my aim. My goal was to have transit and storage encrypted and secure. All bets are off if someone breaks into the server (without rebooting it, if it gets rebooted, the truecrypt volume is gone until I come along to put in the key.) That was the level of protection and risk I decided upon.

And that's why you need to design a solution that fits your needs. Everyone's protection and risk requirements are different, and so you really should have a solution that's tailored to you. There's lots of free tools and most of them aren't too hard to use, in my opinion. But I've been around computers for 30 years, I find little of it 'difficult to use.'

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.

[OpenSourced]

I'm curious. I've always thought that encrypting a lot of files individually (as opposed to as a block) would open you to attacks based on the content of well known files (example configuration files, etc.) that you may add to the lot. That is, if the attacker has knowledge of the content of a couple of files, could he derive the keys for unencrypting the rest?

Re:Give it up.

[mstefanro]

It sounds to me like Rsyncrypto have no idea what they're doing:
"Rsyncrypto is a modified encryption scheme. It is based on industry standard AES for symmetric encryption, as well as RSA for having different keys for each file while allowing a single key to decrypt all files. It even uses an encryption mode that is based on CBC.

Rsyncrypto does, however, do one thing differently. It changes the encryption schema from plain CBC to a slightly modified version. This modification ensures that two almost identical files, such as the same file before an after a change, when encrypted using rsyncrypto and the same key, will produce almost identical encrypted files. This means that both objectives can be achieved simultaneously. "

Inventing their own crypto? Using public-key crypto for no good reason?

Re:Give it up.

[Anonymous Coward]

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?

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.

[unrtst]

+1 to parent.

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.

I love rsnapshot, but the zillions of hard links can indeed be difficult to work with. I recently had to copy the backup data to another server/disk. I initially reached for rsync to do the job, and it couldn'thandle it (same issue with BackupPC pools, btw) - ran out of memory. Ended up using cpio (I think it was something like "find . -depth -print | cpio -pdm /destination/path"). One can stick ssh in the pipe too to get it to a remote location if needed. While this worked, it still took a LONG LONG time, and it's not a solution for keeping two copies of the rsnapshot destination in sync (would need something like block level mirroring, like raid1 on ndb). Long story short, zfs elegantly solves many of the edge cases that other systems still struggle with.

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.

[philip.paradis]

I should have clarified the remote sync bit. The idea is to only rsync the encrypted deltas of your primary mirror. Doing it this way with an added layer of tracking does incur a ton of additional overhead for your local storage to gain minimized network transfer, though. A better method, one I've actually used in the past, involves a script that scans your rdiff-backup mirror for changed files, encrypts them, and shuttles the encrypted files off to remote servers. The state of your mirror is saved in a simple flat file, one line per entry. You could use a persistent key-value store instead if you like.

I use ZFS for bulk data storage, but then added complexity comes from getting the snapshots encrypted and mirrored to offsite servers with any reasonable level of efficiency. All things considered, I'd say ZFS snapshots are great for local point in time recovery, but you'd really want to use something akin to the "track/encrypt/upload" method described above for maximum efficiency.

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

Re:Roll your own - but choose the right SW

[franciscohs]

Depending on your needs this might not be the right choice, as stated on their home:

Great:

Frequently changing project files, like text, office documents, and images
Tracking and syncing files edited by multiple people
Reverting a file to any point in its history
Preventing spying on your files on the server using encryption

Not so great:

Full computer backups
Storing your photo or music collection
Large binary files that change often, like video editing projects

For general purpose Dropbox replacement I recommend ownCloud

Re:Roll your own - but choose the right SW

[SpzToid]

I've tried SparkleShare and it works really well, so long as you don't have many large binary files, like images or videos. It fails where traditional GIT fails.

What I found that works better is git-annex assistant and either your own redundant and cheap hardware disks, or you can also ssh somewhere, OR you can also use Amazon Glacier for a very very low cost. Yes, you can also encrypt everything before it leaves your machine. Check out the nice video tutorials.

http://git-annex.branchable.com/assistant

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.

Re:Focus on your local encryption method first

[bolt_the_dhampir]

Parent needs voting up. With EncFS, you can even use the reverse function, in case you like your local files unencrypted for some reason, to get an encrypted "view" of the files and sync that. You can mount a remote Windows machine's drive, for instance, get an encrypted view of said drive and sync that to the cloud. Also, check out Jottacloud if you have a Windows machine available. I don't think their "unlimited storage" deal can be beaten.

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).

Re:SpiderOak

[grub]

Sorry, forgot to add: I also checked similar services some time ago and after much playing around decided on SpiderOak. I pay for 200 GB with them and am quite happy.