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

[symbolset]

Compared to what SANs cost you might consider buying up some KC residential real estate. BTW: you're already late to this game so expect to pay a premium.

Re:Ooh I know this one

[Anonymous Coward]

I think the submission is actually a troll. Cloud? Hello? Anyone using the expression "The Cloud" is either a troll or lost cause.

Either

1) Put your stuff on TPB.

or

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

Now shut up.

Not very helpful, eh?

Here, let me elaborate. Either contribute to the conversation, or kindly STFU.

Cloud can work. It all depends on your own SLA (and their ability to actually work as advertised), which is the technical dilemma being debated here, so knock it off with your snarky attitude as if someone just brought up a Kardashian using Windows 98. "Cloud", much like the internet, is likely here to stay for a while whether you like it or not.

And over history, I'm sure the people who were "serious" about storage have lost a shitload of data even with tape backup too, so don't act like that solution is magically bulletproof.

Re:Ooh I know this one

[SuricouRaven]

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

Re:Ooh I know this one

[Anonymous Coward]

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

And Linux is not an OS, but everyone knows what is meant by the term.

Re:Ooh I know this one

[slick7]

One that does not evaporate when the sun comes out?

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

[Takeel]

Actually, it's a meteorological term...but who's counting?

Re:Ooh I know this one

[davester666]

in the summary, it was used as a scatological term

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

Re:Ooh I know this one

[real gumby]

I think you meant to say, "`Cloud' is a technical term which has also been hijacked by marketing people who have no idea what it meant in a technical sense, so don't waste your time trying to use it any more."

Other examples include "broadband" (and even more perversely, "narrowband" when they mean "baseband"), "organic", "natural", "3G telephony", inter alia.

Re: Ooh I know this one

[Anonymous Coward]

If you are using Windoze, the solution you want is SymForm.

Copy

[unitarian]

I'm not sure if it is "zero-knowledge" or just "little-knowledge" (file meta-data might be transmitted. I honestly don't know), but I've had very good luck with Copy, which was created by Barracuda (the company that's always advertising in airports, for some reason). Check them out: https://www1.copy.com/home/

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/

Re: Copy

[Anonymous Coward]

Good catch. If you can recover your files without your password, then there's no meaningful encryption happening. Simple as that.

Re:Copy

[gl4ss]

I'm curious, how would zero knowledge go with partial syncs?

Re: Copy

[BrokenHalo]

Good catch.

Only if you consider a barracuda worth eating, which I don't...

Have a box live somewhere

[Anonymous Coward]

Bittorrent sync + local encryption. Leave a box, or several boxes, running in some datacentres somewhere without the encryption key and you have failover backups (and increased bandwidth).

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.

[worf_mo]

I found duply to be a nice solution. It is a (command line) frontend for duplicity which in turn is based on librsync. This combinations makes it easy to create encrypted incremental backups.

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.

[dyfet]

Indeed, locally encrypting and then mirroring is a good solution. Another can be to use something like ecryptfs if one wants "live" usable files shared in a folder and synced over multiple machines. The service (dropbox, gdrive, whomever) only see the encrypted files, and are happy to mirror that without awareness that they are encrypted at all. You only need to make sure to not pick a NSA friendly cipher ;). You can then access your files on each machine directly through the ecryptfs mount point. ecryptfs can also generate encrypted filenames, so what little you do still leak is only file size and creation date this way.

Re:Give it up.

[vtcodger]

Not that I know anything about cracking encryption or have given this much thought, but wouldn't packing well known and unknown files into single files -- e.g. zip,tar,etc -- prior to encrypting make known content analysis pretty much impractical? ... for todays computers anyway?

Re:Give it up.

[Bruco]

Right, this. In my case, the local files aren't encrypted. I stage a backup to an encfs mount, then unmount and rsync the encrypted files to my cheap VPS many, many miles away. Yes, a small amount of metadata is visible, but not actual content. The scripts to do so aren't very long, and were fun to write, even for a relative newbie like me.

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.

[mstefanro]

Knowing plaintext and ciphertext does not make retrieving the key easier for real cryptosystems.

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.

[Streetlight]

If I remember correctly, Steve Gibson in the latest Security Now net cast (http://twit.tv/show/security-now/428) answered this question. Someone asked if a person got hold of a file of known content, maybe a Windows .dll or something, that was encrypted could the encryption key be found by some reverse engineering process and thus decrypt other stuff that used the same key. The answer is this could not be done with modern encryption methods (pgp) and I think he gave a reason why. Check out the Q&A part of the net cast if you're interested.

Re:Give it up.

[mpe]

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.

Even "pre-Snowden" relying on a remote service or software provided by that service to perform such "encryption" was a bad idea. Even without deliberate "backdoors" there are many ways in which such a system can can fail, especially if proprietary software in involved.

Re:Give it up.

[gspear]

I rsync to an ext2 filesystem on a LUKS (cryptsetup) volume running on an S3-backed virtual device (using s3backer).

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.

[Anonymous Coward]

Make sure to use symmetric keys with gpg. At this point, the NSA can easily crack RSA-1024, can probably crack RSA-2048, and I would not be surprised if they are sitting on working quantum computers. Maybe not 4096-qubit machines, but being able to solve discrete logs for common sizes of elliptic curves would be easier than RSA.

Re:Give it up.

[ArbitraryName]

If I don't already know that it's wrong, I just generally assume anything Steve Gibson says is wrong until I learn otherwise. He has a well documented history of being totally wrong just about every time he opens his mouth, so it seems like a safe bet,

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.

[DMUTPeregrine]

Security against known-plaintext and chosen-plaintext attacks is important for modern cryptosystems. Any that are vulnerable to them are considered insecure. So here he's actually right, for once in his life.

Re:Give it up.

[archie.cobbs]

I rolled my own similar solution using rsync and S3... s3backer.

Re:Give it up.

[Anonymous Coward]

One of the protections against known-plaintext attacks is the 'initialization vector' (in other contexts, it's simply called 'salt'). With an appropriately random IV added, most modern algorithms are very resistant to attacks like you're describing.

Re:Give it up.

[foobar bazbot]

I agree that rsyncrypto sounds exactly like the poster child of cryptosystems invented by people who don't understand cryptography.

But I can't resist:

Uhm, that property is exactly what you DON'T want in an encryption algorithm.

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

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.

[Sun]

I have posted an answer to AC below (in this comment). On the off-chance that your use of Ad-Hominem was not a sign of the ordinary way you conduct discussions, I hope you will find the comment linked above provides an answer to why RSA is, in fact, needed.

As for inventing our own crypto - you are more than welcome to offer a standard way that resolves the core need. The AC below you offered counter mode, and I hope I showed why "we" didn't think it was a good idea to use it (thus also refuting your claim that "we" have no idea what "we're" doing).

I did not want to invent my own, but had no choice. With that, I did the next best thing - I did it the least secretive way I could. The implementation is documented in detail, and the implementation is open source.

I also consulted a few people who know more about cryptography than I do. I got one offer for an alternative implementation that was marginally more secure, but was not O(n) (and, therefor, also not suitable for one pass). I was offered zero (0) viable attacks against the algorithm (or the implementation), except the obvious one (i.e. - that the attacker can see approximately how much and where things changed between the versions). I should point out that at least the "how much" is also true for the "use rdiff" suggestion that started this thread.

Shachar

Re:Give it up.

[Anonymous Coward]

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

Hopefully they complain about that part!

Re:Give it up.

[ChatHuant]

This is good advice, but note that it still leaves your vulnerable to traffic analysis; if this level of security matters to you, consider doing regular updates of fixed size to the cloud even if your local data hasn't changed. For example, put your data in a TrueCrypt volume, and run a script to do minor changes on a regular basis and upload the whole file to the cloud. This will cost more bandwidth (obviously) but the attacker will only see your regular daily/weekly/whatever upload of a fixed length binary lump and won't be able to correlate the changes in the churn and size of your data to your other activities.

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.

Re: Give it up.

[Anonymous Coward]

[Citation needed]

Re:Give it up.

[PybusJ]

It's even possible to do this without the staged copy: encfs takes a --reverse option, which instead of producing an unencrypted view of an encrypted filestructure as a fuse filesystem, produces a fuse mount which shows an encrypted view of a plaintext source tree. This mountpoint can then be copied using any normal backup/sync tools. It's a rather neat feature.

Re:Give it up.

[Bruco]

That's very cool. My staging point also serves as my local backup of the files (external drive), but there's no reason I couldn't mount the existing file system with the --reverse option, then rsync it where ever I please. Thanks!

Re:Give it up.

[Bruco]

I expected as much - rsyncing an encrypted file system reduces rsync's functionality to that of Robocopy - any change to a file will result in the entire file being moved to the destination. For my purposes that's fine - I'm not working with large files that are frequently changed. But if needed could one use an encfs mount on top of an sshmount on the remote system, then rsync directly to that? Wouldn't the encryption still be occurring locally, or is there a big fat hole I'm not thinking of?

Re:Give it up.

[Bruco]

Ugh, I meant sshfs mount. Pardon my error.

Re:Give it up.

[mstefanro]

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

a) You do not want to encrypt all files involved using the same symmetric key.
Care to explain why? There is nothing wrong with using the same key for multiple files.
Anyway, if the main key is leaked then all the keys can be derived, so how is this different than
using a single key? What additional security does this give? Is there a scenario in which a single-key symmetric approach
does not survive an attack but your approach does?

b) With this scheme, you only need to reliably and securely store one key
And this is different from symmetric crypto how? Where does the need for asymmetry come from? Does the
set of people capable of doing one direction of the operation differ from the set of people that can do it backwards?
Even if you use different keys for each file, you can still encrypt each of those keys with your master key, which can
still be symmetric.

Re:Give it up.

[Sun]

I should point out that this comment, beginning to end, is criticism over rsyncrypto for following industry best practices, while previous comments (including this one, from the same author) were criticism for not following best practices. I do wish you'd make up your mind :-)

a) You do not want to encrypt all files involved using the same symmetric key.
Care to explain why? There is nothing wrong with using the same key for multiple files.

If two files are identical (or even start off identical), having them encrypted to different cypher texts is a nice bonus to have. This also makes an attacker's work more complicated, as there is no one jackpot to concentrate all effort into. Like I said above, this is just best practice. You'd be just as critical, if not more, had I used the same symmetric key for all files.

Anyway, if the main key is leaked then all the keys can be derived, so how is this different than
using a single key?

See my answer below.

b) With this scheme, you only need to reliably and securely store one key
And this is different from symmetric crypto how? Where does the need for asymmetry come from? Does the
set of people capable of doing one direction of the operation differ from the set of people that can do it backwards?

People, maybe not, but machines - certainly. This way, the trust level you need to assign to a machine in order to allow it to back up data is lower than the trust level you need in order to restore. This mode allows you to have several machines back up to the same store, with one compromised not meaning they are all compromised.

Which means that there is no reason for the master key to be compromised, as there is no reason for it to be anywhere but in a vault, only to be retrieved if a restore is needed. This is not something you could do had the master key been symmetric.

And the bottom line is that all of the above just boils down to "industry best practices". It is the exact same thing PGP does when encrypting files and messages.

The more important question, however, is why did the alleged "needless use of RSA" trigger such a huge red flag for you? What is the reason we should not use RSA?

Shachar

Re:Give it up.

[mstefanro]

> The more important question, however, is why did the alleged "needless use of
> RSA" trigger such a huge red flag for you? What is the reason we should not
> use RSA?

Because public-key cryptography, while being super awesome and very useful in
many situations, is orders of magnitude slower than private-key
cryptography (not only RSA, but everything that needs to deal with
exponentiations and multiplications of 2048bit numbers).
When I hear about hard-disk I/O and synchronization, I think of
encryption that must have almost no speed penalty (see Truecrypt).
Storing data in a way that can be retrieved only by the same person who stored
it is certainly not a good use-case for an asymmetric cryptosystem with huge
overhead. If I have to open 10000 file handles then the overhead of decrypting
10000 filekeys with RSA will not be negligible.

> If two files are identical (or even start off identical), having them
> encrypted to different cypher texts is a nice bonus to have.

Any Mode of operation that is not broken provides this feature, as
the IV is chosen at random. You do not need different keys to provide this
feature (hint: try running "echo -n a|openssl aes-128-cbc -k test -a" multiple
times on a terminal). Moreover, even if you do use different keys for each file,
those keys can still be encrypted with symmetric crypto.
Key-encrypting-key can be achieved with symmetric crypto alone. The use of
public key crypto appears only when those messages need to be authenticated,
signed or when multiple parties are involved somehow. Unless you do more fancy
stuff, such as distributed encrypted file systems or encrypted computation/databases,
data storage alone has little to gain from public key crypto.

As for the backup example, that does not make much sense. Why would a machine
need to look at any of the contents to perform a backup? Encrypted data should
in general be indistinguishable from random data (plausible deniability and
all). To backup encrypted data you simply copy it, there's no need to decrypt
anything. I see no reason why a backup machine should have any additional
insight on my data. And besides, how would that even work?
What would the backup machine be able to do? Decrypt? Encrypt? Encrypting new
files sounds useless for backupping (because you can't read the old ones).
Decrypting on the other hand, if provided to the backups machines, means that
they can read everything.

> And the bottom line is that all of the above just boils down to "industry
> best practices". It is the exact same thing PGP does when encrypting files
> and messages.

Truecrypt only uses AES. PGP uses public-key cryptography because it needs to
sign and authenticate messages (e.g. to prove that an e-mail has the author it
claims it has), which is a totally different usecase than what you have.

Do not get me wrong. This is not personal and I'm not attacking you, so stop
being so defensive. I simply made an initial comment that the devs don't seem
to know what they're doing in regards to crypto, and then you challenged me and
I simply detailed why I made the claim. I appreciate and respect open-source work, but
unless you can back up your design choices with pertinent arguments, try to
swallow criticism more easily. There's a reason why "don't make your own
crypto" is a rule of thumb for programmers. Unless you're working in the
field, let the experts deal with this. Or go study. "I have some crypto
knowledge" is not enough to justify modifying existent mode of operations such
as CBC.

Re:Give it up.

[foobar bazbot]

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.

Er, yeah. I actually did know that, considering it's right there in the name.

I was trying (and from both your reply and the downmod, obviously failing) to point out in a humorous way that it's not inherently a bad property for an algorithm as per GP, but rather any system including an algorithm with that property must prevent the same (or related) keys from being used for encrypting different files or different versions of the same file. (Of course, as applied to "rsyncrypto", it comes down to the same thing, since it depends on not rekeying.)

Re:Give it up.

[Sun]

> The more important question, however, is why did the alleged "needless use of
> RSA" trigger such a huge red flag for you? What is the reason we should not
> use RSA?

Because public-key cryptography, while being super awesome and very useful in
many situations, is orders of magnitude slower than private-key
cryptography

Wow. All of this over performance? I was prepared to hear some convoluted explanation about security, but performance got you so angry?

Unless you are backing up 10,000 files with an average length of 10 bytes, the time for performing 10,000 RSA decryptions is negligible compared to the time it will take to actually encrypt said 10,000 files (not to mention, store the to the disk and/or transmit them over the network). I will gladly accept counter arguments if they are backed up by actual data.

For the record, here are my own tests, from a few seconds ago. All tests on an SSD:
Create 10,000 files with 10 bytes of zeros. Time output:
real 0m12.213s
user 0m0.396s
sys 0m1.464s

Encrypt said 10,000 files with rsyncrypto (including symmetric encryption and compression) with a 1024 bit RSA certificate:
real 0m12.817s
user 0m1.288s
sys 0m3.308s

Encrypt said 10,000 files with rsyncrypto with a 2048 bit RSA certificate:
real 0m13.518s
user 0m1.924s
sys 0m3.312s

To me, spending the extra 1.7 seconds (CPU time, much less for wall time) for 10,000 files no one in his right mind will even want to back up is negligible.

When I hear about hard-disk I/O and synchronization

Who even brought it up? The only context in which I said "synchronization" was machine to machine synchronization: i.e. - rsync.

It seems to me like you are thinking of using rsyncrypto for purposes vastly different than the ones for which it was designed for. That's fine, of course, but complaining that it does a poor job there is off topic and redundant. Rsyncrypto is not built for full disk encryption. It is built for using untrusted storage for backup over a network. This is not everyone's need, but it is both the story poster's need and the original commenter.

Moreover, even if you do use different keys for each file,
those keys can still be encrypted with symmetric crypto.

Yes (well, no, see later), but why WOULD you? Like I said above, the performance argument is bull, and you do lose capabilities.

As for the backup example, that does not make much sense.

I have no idea what you are talking about, which leads me to believe you did not understand what I said. What I said was that you might back up several machines to the same storage provider. Using public key allows you not to have your entire data compromised by having one of those machines compromised. Also, not needing your master decryption key in order to encrypt means the chances it gets compromised are, more or less, zero.

Do not get me wrong. This is not personal and I'm not attacking you, so stop
being so defensive. I simply made an initial comment that the devs don't seem
to know what they're doing in regards to crypto, and then you challenged me and
I simply detailed why I made the claim. I appreciate and respect open-source work, but
unless you can back up your design choices with pertinent arguments, try to
swallow criticism more easily. There's a reason why "don't make your own
crypto" is a rule of thumb for programmers. Unless you're working in the
field, let the experts deal with this. Or go study. "I have some crypto
knowledge" is not enough to justify modifying existent mode of operations such
as CBC.

In order for you to be able to pass the above passage as likely, you should have done two things. You did neither. You needed to:
1. Show an actual design failure. At best, all you did was show a dislike to RSA due to performance rea

Re:Give it up.

[Sun]

I forgot to add an important note. The test I ran was to encrypt the files using the public key. Since you are claiming that a symmetric key would have done just a swell, it would make more sense to run the test with the private key. If you know RSA as well as you claim to, you should know that using the private key is even faster.

Shachar

Re:Give it up.

[Terrasque]

A bit late to the party, but.. There are some things I'm curious about.

If two files are identical (or even start off identical), having them encrypted to different cypher texts is a nice bonus to have.

Wouldn't different IV (or nonce in CTR mode) effectively stop that potential problem?

And from another of your posts that I was wondering about:

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.

A bit change in CTR mode shouldn't alter anything past it's block, from what I understand. There's no state that's moved on from one block to the other (well, except the counter, but that's not affected by the block data).

And again, wouldn't different IV / Nonce effectively stop that problem?

Re:Give it up.

[mstefanro]

Could we take this offline (e.g. IM)? Discussing this way seems highly counterproductive.

Re:Give it up.

[fnj]

Heh, I hear you. I have rsync'ed some pretty big rsnapshot repositories to backup repositories, but I was helped by having 16 GB of RAM :-) But still, it was appallingly slow reconciling all those links, even if the actual transfer for an incremental is not that much.

Re:Give it up.

[fnj]

Fair enough. My present requirements do not include encryption. If they did, maybe zfs send | encrypt | ssh target 'cat > snapshotxxx.crypt.img' might be worth consideration. Recovery from the remote would then be more complex, as it would involve reconstructing from a series of differentials.

Re:Give it up.

[Sun]

Email me.

Shachar

Re:Give it up.

[Sun]

Wouldn't different IV (or nonce in CTR mode) effectively stop that potential problem?

It would that particular problem, yes. As rsyncrypto is currently implemented, the IV is not embedded in the file at all (except as part of the encrypted key) - hence my confusion. My other points regarding why not one symmetric key for the entire archive do still stand, however.

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.

A bit change in CTR mode shouldn't alter anything past it's block, from what I understand. There's no state that's moved on from one block to the other (well, except the counter, but that's not affected by the block data).

And again, wouldn't different IV / Nonce effectively stop that problem?

No. A bit change won't propagate a change beyond that bit, but an attacker watching the two stream (before and after the update) will have complete knowledge on precisely which bits have changed and which remained the same. Reusing the same keys for CTR is no more secure than using a one time pad twice (i.e. - not particularly).

You will note, however, that I did not say a bit change. I talked about adding or removing a bit. That will change the entire rest of the stream, as stated.

A different IV/Nonce will solve that problem, at the cost of completely eliminating the advantages. Now instead of the stream being different from the point of the stream onwards, it is completely different from start to finish. The whole point of changing anything from the standard was so that rsync can efficiently transfer the (changed) file to the backup server. That requires that changes to the plain text create localized changes to the cypher text. CTR simply does not have that property.

Shachar

Re:Give it up.

[Terrasque]

I see, thanks for the answer :)

At least you have thought about things, and seem to have a good understanding of the mechanics, and have reasons for the changes. Which is more than sadly too many who develop crypto code have.

As for the changes you've made, I haven't looked at them closely so I won't even try to discuss them :)

The only thing I can say about it is the basic gut feeling that any novel approach to crypto should be distrusted until verified by time and experienced people :)

Use MEGA

[Anonymous Coward]

Http://mega.co.nz

Re:Use MEGA

[xcyther]

Why? How is mega different from the rest? He doesn't even offer sync options...

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:Why Pay Somebody Else?

[Anonymous Coward]

Why? Not everybody has the time to do it themselves and ultimately you have to pay someone for off-site storage regardless. Why not use BitTorrent Sync? It's a "A proprietary peer-to-peer file synchronization" tool. If your data is important enough to warrant encryption you don't utilize proprietary software. Hell. I wouldn't use it even if it wasn't that important. Proprietary software is a security risk I'd rather not have and it can't ever be relied upon. You don't know if- or more likely when that software will disappear. I should never be put in a position where I'm unable to access my data and thats exactly what you'll get using such tools. I shouldn't have to have Microsoft Windows XP because the data I want is encrypted using some untrustable utility that was discontinued during that era. That same thing goes for file formats and production applications.

Re:Why Pay Somebody Else?

[Jane Q. Public]

s/hoop/hook

Re:Why Pay Somebody Else?

[Anonymous Coward]

They are also planning to add a feature that allows you to sync your files to an untrusted computer, leaving them completely encrypted in the whole process.

http://forum.bittorrent.com/topic/16836-support-for-untrusted-encrypted-node/?p=62836

(FWIW, BTSync uses AES128-CTR. Good enough for random files and pictures but I would not use it for anything sensitive.)

Re: Why Pay Somebody Else?

[Anonymous Coward]

AES128-CTR is a very respected algorithm. I don't understand why that would be the past you're worried about. The worrying part is that Bittorrent sync is closed source.

Re:Why Pay Somebody Else?

[Anonymous Coward]

Bittorrent Sync *might* be pretty secure. We simply can't take that risk at this stage. Once the code is open we can take it seriously.

Re:Why Pay Somebody Else?

[Anonymous Coward]

Maybe because BTSync uses unencrypted nodes for trackers?

Re:Why Pay Somebody Else?

[vtcodger]

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?

Fires, thefts, etc can happen to pretty much anyone. There's something to be said for encrypted off-site storage. OTOH, there's no particular reason that can't be on a usb flash drive in the glove compartment of a car. (I'd suggest in the trunk under the spare tire instead). After all, the data is encrypted. What can possibly go wrong?)

Re:Why Pay Somebody Else?

[Anonymous Coward]

It's pretty secure,...

It sounds secure, but until they publish their protocol or open source their client their solution is just as good as using NSA approved software.

Re:Why Pay Somebody Else?

[Anonymous Coward]

BitTorrent Sync is proprietary software. It's probably backdoored for the NSA.

Re:Why Pay Somebody Else?

[Jane Q. Public]

"Not everybody has the time to do it themselves and ultimately you have to pay someone for off-site storage regardless."

No, you don't. With BT Sync you keep the data on your own machines. That's the point: no third party necessary.

"Why not use BitTorrent Sync? It's a 'A proprietary peer-to-peer file synchronization' tool." If your data is important enough to warrant encryption you don't utilize proprietary software.

That's a silly thing to say. Spoken like somebody who spent 30 seconds on Wikipedia and knows nothing more about it.

First, OP is comparing against other "proprietary tools". Further, the "proprietary" part of BTS is inherently simple, transparent, and easy to understand. And the BitTorrent protocol is common and open. Compare that against any of the services to which he refers.

Further yet, considering the advantages of the BitTorrent protocol, if BT Sync were ever to go down (or even if it doesn't), somebody else would produce an app to do it pretty quickly. Likely even open-source.

Frankly, in my opinion it's a non-argument in this particular case.

Re:Why Pay Somebody Else?

[Jane Q. Public]

"Fires, thefts, etc can happen to pretty much anyone. There's something to be said for encrypted off-site storage. "

This is not a "backup", it is a SYNC application. If anything happens to one copy, everybody else has another copy.

Why pay somebody else for what you already have?

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

[Anonymous Coward]

OwnCloud seems to be pretty good too

Re:Roll your own - but choose the right SW

[Anonymous Coward]

Tried them both - sparkleshare and owncloud. They're a complete joke, bug ridden and lacking in basic functionality.

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

EncFS or BoxCryptor

[Anonymous Coward]

Use EncFS or, if that's too tedious for you (it's not that polished on Windows), BoxCryptor.

Advantages: (i) you can use any cloud storage provider you want and (ii) EncFS is open source, so you have some means of verifying that there's strong encryption on your end without backdoors.

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.

Re:None of them.

[MrL0G1C]

Perhaps I should RTFS before posting. I still wouldn't trust these services anyway, how do you know the keys are made securely and stay secure?

Re:None of them.

[rvw]

Perhaps I should RTFS before posting. I still wouldn't trust these services anyway, how do you know the keys are made securely and stay secure?

Exactly! How will you ever know for sure that the program won't send your private key to the server - encrypted with another key so you will never see it if you would try to monitor traffic? I think it's impossible with hundreds of gigabytes of traffic.

Re: None of them.

[Anonymous Coward]

Well hey, embassies and other countries more likely than not use Microsoft Windows.

For the original question, Tahoe-LAFS should do it. Keep the keys secure in non-connected storage such as USB.

Re:None of them.

[rmstar]

Exactly! How will you ever know for sure that the program won't send your private key to the server - encrypted with another key so you will never see it if you would try to monitor traffic? I think it's impossible with hundreds of gigabytes of traffic.

You need an open source client, and you have to build it yourself.

That said - this slashdot news item looks like a psyop to me. Why would a halfway decent cloud storage provider botch up data integrity so badly? This isn't rocket science after all. I suspect this is FUD to keep people from using these encrypted storage solutions.

Re:None of them.

[Anonymous Coward]

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.

Agreed.

If someone were _genuinely_ afraid of the government, why would they give their stuff to ANYONE?
They aren't.

If they do not secure theirthings, it's like handing a stranger in a possibly foreign country a folded letter and asking them not to read it.
If their staffers read it and don't tell you, does it matter? I'm tired of people yelling police state when they'd give complete strangers their stuff but act "afraid" of their government.

Re:None of them.

[rvw]

EncFS might just do what you and I need!

Re:None of them.

[St.Creed]

Why would a halfway decent cloud storage provider botch up data integrity so badly? This isn't rocket science after all. I suspect this is FUD to keep people from using these encrypted storage solutions.

While it may not be rocket science, a lot of people underestimate the amount of corruption that files incur from bits flipping at random in storage or during transfer. It's one of the reasons many of those cloud services have checksums at EVERY step in the process. And if you use the wrong type of checksum you're going to get collisions once the number of customers goes up. Apart from that, you get sync issues if the clocks of all devices don't match up exactly, and you need to make sure you have a globally available checkpoint (a counter, or a good clock) that works.

It's a bit like cryptography. While the principles are well understood, a minor bug in the implementation can make the difference between a working solution and a subtly non-functional one.

Re:None of them.

[Anonymous Coward]

Obviously you shouldn't use non-opensource solutions for this. And if it's opensource then you and the community can check the source code to make sure your keys aren't transferred and that only the encrypted information is transferred.

Re:None of them.

[Anonymous Coward]

I've had US providers just deleting my whole VM just because they didn't "like it" (I was maintaining a legitimate mailinglist on it, that never got abused).
I was "free" to restore the VM on my own time and my own backups. Of course, if I bought their "backup-plan", they could help me with this problem in the future.

This was a monthly paid plan, and I made sure our organization stopped using and paying it promptly.
Fortunately, I had backups of the mailinglists, but we stopped using "cloud providers" from that point on.

Good luck with "your cloud"..

Captcha: dreading

Re:None of them.

[Pav]

Because it's good security practice to assume an adversary who is everywhere with huge resources perhaps? If you don't want to call your adversary NSA, call them the Gestapo or something (personally I call them "Chaos"... the evil team from Get Smart). They're always going to get in so why bother? Guess what... assuming that they will always get in is ALSO good security practice. You can continue to assume retarded script kiddies though... good luck with that.

Re:None of them.

[chihowa]

This is a good practice (and I really like KAOS as the bad guys). Always assume and plan for a sophisticated adversary, but never assume that their actions must be sophisticated. A bumbling opponent that gets things right often enough is great for that.

Re:None of them.

[ewieling]

The NSA does not have godlike powers.

The NSA does both targeted and non-targeted surveillance. In non-targeted surveillance the NSA simply vacuums up as much data as they can in the hope it will be useful some day. I think we can protect ourselves from much this non-targeted surveillance without taking extreme measures such as removing yourself from society and living off the grid. I have made many small changes in my life to reduce my electronic footprint and encrypt more of my data. Google, Amazon, etc can also take steps to help prevent this kind of surveillance.

In targeted surveillance the NSA wants to surveil a specific person. There is little you can do to prevent this kind of surveillance. It might be possible to slow them down a little, but eventually you will make a mistake and they will get you. The only possible way to avoid this is to not be seen as a threat.

Re:None of them.

[mpe]

How will you ever know for sure that the program won't send your private key to the server - encrypted with another key so you will never see it if you would try to monitor traffic?

Unless you control the "client side" software you can't even know if it is even using the key you think it is. Never mind doing something as elaborate as steganography to send data you don't know it's sending.

Re:None of them.

[DuckDodgers]

Google, Amazon, etc... are powerless to take steps to protect data because the Patriot Act allows the NSA to demand huge volumes of data, no questions asked, no right to refusal, and even no right to a public legal challenge to the move.

I genuinely don't think the customer data mining done by Google, Amazon, Microsoft, Mastercard, Bank of America, etc... etc.... is evil. But we have a government agency with agents already caught abusing their surveillance authority to watch spouses and significant others. There is currently nothing legal or technological in place to evolve the situation into something better and every indication it's only going to deteriorate.

It's not ready yet

[Anonymous Coward]

Considering the sorry state of basic cloud sync services, I would not be surprised if the advanced versions are even worse. The only service I can actually recommend is Dropbox - it is expensive, but it works, and even so it eats a lot of CPU time and hard disk activity at boot up.

The alternatives are worse to terrible. Google Drive claims that files are in sync when they aren't. It also seems to fight with files open in MS Office. It creates conflicts for no reason. It just plain fails to deliver, even if you neglect the absence of a Linux client. Box is much worse in my experience, although it has a nice and clean design. Skydrive is interesting, but I repeatedly ran into installation issues with it - funny given that it is MS software, or maybe to be expected.

Obviously encryption makes things a lot more difficult, especially the handling of temporary files and the merging of conflicts. So it should not be a surprise that it does not quite work yet.

Re:It's not ready yet

[icebike]

None of the services you mentioned are zero knowledge services. The all can and will hand your data to the first cop in the door with something vaguely resembling a warrant.

Spideroak claims to be zero knowledge, they don't have your keys and couldn't decrypt your Data if they were ordered to.

Unless or until they open source their client side software you have to take their word for this. Although they did say they would open source the client some time ago.

I have it backing up two different machines, and have not had it lose any files. It also can be used to sync machines but I use it for version backups (you can roll it back many increments).

HP Autonomy Cloud Backup Service

[scott9693]

This probably won't be a popular comment given Slashdot's DIY mentality, but why not go for an online backup system instead of cloud storage?

You stated you need it for backup, so use a backup service. They have the benefit of alerting you when backups occur and do not occur, can sync as little as every 15 minutes, provide up to 7 years of snapshots.
With block level synchronisation, it encrypts the data before leaving the server and I believe it is PCI compliant.

Re:HP Autonomy Cloud Backup Service

[rtb61]

Do it yourself means that you manage risk and cost. Handing it over to an outside contractor means, inevitably, eventually, with all companies, some douche nozzle accountant executive with limited tech knowledge in the pursuit personal bonuses and claiming great savings and extra profit with the typical B$ spreadsheet. Will take a series of cost savings short cuts that allow risk of data loss to become a certainty of data loss. They lose customers, the customers go elsewhere but unfortunately so do those douche nozzle executives and the problem relocates. It the cycle of greed, build trust, sell that trust for extra profit, fail and back too build trust (there ain't no profit, just bonuses for no nothing douche nozzle executives, you know, psychopaths in suits). It is always just a matter of time, to greed driven contractor failure.

Re:HP Autonomy Cloud Backup Service

[Anonymous Coward]

So you're willing to pay top dollar to keep your data stored online, securely and encrypted? Who do you work for, the mob?

Re:HP Autonomy Cloud Backup Service

[mpe]

Do it yourself means that you manage risk and cost. Handing it over to an outside contractor means, inevitably, eventually, with all companies, some douche nozzle accountant executive with limited tech knowledge in the pursuit personal bonuses and claiming great savings and extra profit with the typical B$ spreadsheet. Will take a series of cost savings short cuts that allow risk of data loss to become a certainty of data loss.

However you don't know when this is happening. So cannot assess and manage you risk. It' s possible you may not even find out even after a loss/disclosure has occured.
Note also that if the company you choose is bigger than you are then you automatically increase your risk. Since crackers, both criminal and government sponsored, tend to be interested in the biggest targets. Whilst momandpop.com might have to specifically attract the attention of the "bad guys" they are already looking at Dropbox, Amazon, Google, Skydrive, etc.

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.

Re:Focus on your local encryption method first

[CptJeanLuc]

Yes, this is exactly the type of solution. If OP does not run Linux or otherwise have access to EncFS, something similar like TrueCrypt might work. Also, with EncFS, though I don't remember the expert mode configuration options by heart, there may be some regarding how file names are encrypted, that need to be properly configured in order to work across multiple systems, e.g. avoid dependency on absolute path. The main point is not trusting any 3rd party to handle the secrecy of your data. By controlling the encryption, you effectively alter the level of trust you have to grant to a 3rd party.

Obviously, you are still exposed to whatever spyware may be on your PC. Managing encryption locally does not offer much additional secrecy if the dropbox (or similar) client you are using, contains a back door which allows snooping on your file systems. So even though you don't trust the cloud service provider to keep your data safe, you may have to trust their client if you want to use a cloud service. For me personally, I like the "roll-your-own" alternative of sshfs plus encfs (on Linux). I trust those related technologies and clients, and the providers of the related clients I run locally. If I keep data with a hosting provider, I don't need to trust any client they provide me, because I get that elsewhere - and ssh has been around for ages and the openssh source code is probably heavily audited.

All this being said ... at the end of the day, most of us will never need tinfoil level secrecy for most of our data. So I would tier the type of solutions I use for various data, and use the heavy-encryption stuff only for data that I feel deserves extra protection. For everyday stuff, I am perfectly happy to just use Google Drive. I don't think anyone is going to get too excited about getting their hands on my weekend shopping list for groceries.

Re:Focus on your local encryption method first

[Anonymous Coward]

Use aespipe to collect up anything into an encrypted package.

Only one answer...

[Anonymous Coward]

The NSA.

TarSnap

[broknstrngz]

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

encfs

[Anonymous Coward]

Linux/encfs/samba and then back up with your old provider.

Go with what works

[VortexCortex]

127.0.0.1 or 10.6.6.6 or 192.168.69.42. Those are my encrypted cloud service providers. Public address varies so I ping my web server for a redirect; You could use dynamic DNS. Since we're using pre-shared-key encryption no MITM can insert themselves -- data is encrypted before the session is even initiated -- No need to worry about SSL PKI shenanigans.

Re:Go with what works

[Anonymous Coward]

127.0.0.1 or 10.6.6.6 or 192.168.69.42. Those are my encrypted cloud service providers. Public address varies so I ping my web server for a redirect; You could use dynamic DNS. Since we're using pre-shared-key encryption no MITM can insert themselves -- data is encrypted before the session is even initiated -- No need to worry about SSL PKI shenanigans.

Are you sure you understand how SSL works?
No that's the wrong question.. you might be, you're just misinformed.

SSL can do the thing you said right before it. You don't HAVE to use a certificate chained to a key held by a third party, and you don't HAVE to chain certificates at all if you don't want to, but that makes key management much easier.

Re:Go with what works

[Anonymous Coward]

Not really, I saw 'SSL' on my MCSE exam and it sounded cool. There was something called 'SSH' too...I'll use that in my next post.
- Vortex

Re:Go with what works

[Anonymous Coward]

Using a pre-shared key means you don't have to deal with that sort of SSL PKI shenanigans.

No sympathy, yes solution

[Anonymous Coward]

I had to restore from my local backup more than once and I ended up losing files for real.

So sue them! What do you mean you didn't read the terms of service which clearly (if you're a crooked business lawyer) state you cannot sue for anything...

The only solution you can trust is DIY. That way you know what is happening.

It does not matter

[Omegium]

As far as encryption is concerned, you cannot trust anyone but yourself. So you can ignore anything your cloud provider says about encryption and focus on speed, reliability and cost.

You should make sure that your cloud provider only ever receives encrypted data from you, and if he decides to encrypt again, good for him, and if he decides to let the NSA listen in, well, it doesn't matter, your data was encrypted anyway.

Re:It does not matter

[Anonymous Coward]

As far as encryption is concerned, you cannot trust anyone but yourself. So you can ignore anything your cloud provider says about encryption and focus on speed, reliability and cost.

You should make sure that your cloud provider only ever receives encrypted data from you, and if he decides to encrypt again, good for him, and if he decides to let the NSA listen in, well, it doesn't matter, your data was encrypted anyway.

Speaking of the NSA and trust, I'm glad you feel the only one you need to trust is yourself, as you sit back and type away on a commercial piece of hardware running commercial firmware, running a commercial OS you did not write or audit personally (and may be closed source), with a commercial wireless radio and network stack, all while assuming that the crypto used to secure it all hasn't been broken or backdoored by the NSA long ago.

I heard the cloud of ignorance is fluffy and smells like McDonalds french fries. No wonder so many are addicted.

Re:It does not matter

[Decker-Mage]

I happen to like McDonald's french-fries, but then again, I developed that addiction very young. As for your assessment that it's the wrong way to think about risk, your dead on. It's just safer to assume that you are being surveilled and as a rule, do your best not getting on anybody's radar. I assess that now you can actually use some level of encryption, if your concerned about privacy or not serving up your media collection to the masses, and not land on that radar. "The tallest tree is the first one chopped down." Don't go freakazoid on this stuff.

For myself, I appreciate all of these techniques. I've never been worried about my 'stuff,' it's just making sure that the people I care about don't get chopped down.

Americans...

[Anonymous Coward]

"I decided changing that service"

Did you. Did you really. Idiot.

"I decided TO CHANGE that service."

DIY

[vikingpower]

Only solution. If you want a job done properly, then you best carry it out yourself. Buy a relatively cheap server, equip it with whatever you need to get a backup to it working, and have that server hosted. You'll pay for the hosting and the bandwidth ( in many cases, the latter is included in the former ). All cards are in your own hands. It takes some work, but except for man-in-the-middle attacks - which are always possible, BTW, and in any scenario - you are safe.

nau an

[nau an]

Thank you for share.! nau an

What's the point?

[stenvar]

If you don't control the software itself, you can't be sure that there aren't backdoors. Even if there aren't backdoors when you start, they can always get introduced later.

If you're really concerned about this, put a server somewhere and use encrypted rsync or something similar. Even then, be aware that backdoors can still be pushed onto your machine with a software update.

Least Authority

[Anonymous Coward]

https://leastauthority.com/

They are built by the guy who manages the Tahoe LAFS project, which is a distributed encrypted datastore. Encryption happens on your side, there's nothing they can do to read your data.

Re:Least Authority

[Decker-Mage]

Nice, and just what I would roll on my own.

Don't pick "free"

[Anonymous Coward]

Pick a serious commerical actor if you care about your files. I've used CrashPlan for many years, since it's cheap, fast and encrypts strongly.

I think a cloud backup is a must these days...

Crashplan

[Anonymous Coward]

Check out Crashplan they're the company that I've decided to go with. I pay for only one host to be backed up. I then use their utility to backup all other hosts to one server. I even use their utility to back-up my parents and several friends to my NAS at home. Then I use their tools to backup that server to their cloud. You get to define your own encryption key if you wish and at that point in time they become a zero knowledge service. A really quick search on the topic provides this list of services that support private encryption keys:

SpiderOak
CrashPlan
Mozy
Backblaze
Carbonite
IDrive
AltDrive
Bitcasa

Hope this helps.

Re:Crashplan

[Anonymous Coward]

Crashplan is a joke, in terms of security. It requires that you use a proprietary client, and nobody knows what all that client software does. You have to assume other parties have the decryption key.

Re:Crashplan

[Anonymous Coward]

also Cubby (yes terrible name)

ecryptfs + rsync

[Anonymous Coward]

As plenty of others have mentioned, you don't need or even want an "encrypted cloud provider". You cannot trust that.

Instead, use ecryptfs locally, and use rsync to copy the encrypted files to the provider. That's under your control, uses only software you can examine and build from source yourself if you want, and it works with any provider.

Using some proprietary, fragile, single-vendor solution is not a wise decision.

BoxCryptor

[Anonymous Coward]

I use BoxCryptor which you can use with existing cloud storage providers such as dropbox.

It gives you a driver letter / mount point, any file you save there is transparently encrypted before being placed onto for example dropbox. You have a 1:1 relation between the plain file and the encrypted file so you can still use things like deleted file recvoery.

filecloud

[ionix5891]

Try filecloud.io they are an Irish company with servers in Amsterdam

free accounts come with up to 1000GB free storage (reduced redundancy sort of like amazon) and more if you pay 6.99$ / month (29.99/6 months) that comes with raided storage

you can encrypt files yourself before uploading whichever method you want

they have previously went to courts and got advice from Irish Data Protection commissioner that if any 3rd party wants your data they have to get an Irish court order.

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.

Re:Truecrypt + Dropbox

[Anonymous Coward]

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.

I agree with you and this solution works perfectly for me as well. The sync method makes it very fast even for 10GB+ files.

Re:Truecrypt + Dropbox

[St.Creed]

That's a pretty good idea, actually. I think I'll go this route myself as well.

Re:Truecrypt + Dropbox

[Pav]

Is it recommended for this use case? If not I'd be leary of using it without expert advice... it's very easy to break a secure system by applying it to problem domains for which it wasn't designed. Could an attacker infer things by watching changes over time?

Re:Truecrypt + Dropbox

[Anonymous Coward]

Change one byte of a file and the before and after encrypted versions should be completely different (assuming good crypto). The binary diff feature is completely useless.

Re:Truecrypt + Dropbox

[Anonymous Coward]

Yup - doing the same thing. It works.

Re:Truecrypt + Dropbox

[Anonymous Coward]

Well, if you don't trust Truecrypt, then you can use GPG or LUKS. It amounts to the same thing. Simply create a 1GB encrypted container inside the Dropbox folder and General Alex is your uncle...

Re:Truecrypt + Dropbox

[Anonymous Coward]

You're using an encrypted filesystem. Truecrypt won't rewrite the whole filesystem if you change a single file within it, because that just wouldn't be practical. Dropbox sees the encrypted filesystem as a single file, and that is where Dropbox's binary diffs come into play.

Encrypted Google Drive

[Anonymous Coward]

syncdocs.com - encrypts Google Drive stuff before uploading. Simple to use and secure, and Google gives away 15GB of free space anyway.

OwnDrive

[Anonymous Coward]

use https://owndrive.com since i'm concerned about privacy and security. They are relatively new cloud storage provider, but they use strong AES server side encryption. Their web interface is the most user friendly one i've seen. And it's based on open API so i'd recommend OwnDrive.

--
Stian Sand

None of them!

[coder111]

Unless you do your crypto on your own machine, and your machine is not compromised, any such service is insecure. As soon as your cloud storage provide has your crypto keys, you need to assume your encryption compromised. There are several ways to implement it:

1. Use GPG and ecrypt each file before storing it on-line.
2. Pay for a normal Linux hosting server with ample storage. Export the raw block device using NBD (network block device). Encrypt it on your device using dm-crypt or luks and mount it. This encrypts the entire disk.
3. Use some kind of cloud storage, but do encryption in javascript on the browser, in your machine, without sending encryption keys anywhere. Look at http://openpgpjs.org/ I don't know any cloud services that would allow doing that.

--Coder

Why?

[Porchroof]

Why in the world would anyone want to store his valuable files on someone else's computer? Makes no sense.

Re:Why?

[Draknor]

Because people want automated off-site backups (a good idea), and not everyone has the knowledge to administer a remote hosted server?

Re:Why?

[ArbitraryName]

Do you keep your money in a bank? Why in the world would you let someone else store your valuable currency?

Stay with the good provider and encrypt locally

[Anonymous Coward]

If you have a provider that you're happy with, the continue using it and just encrypt the data locally.

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:Seafile

[Wonko]

I've been using Seafile since April and I am very, very pleased with it. It is one of the few self hosted options that supports client side encryption and manages to scale up to a reasonably large number of files. It fell down on me in the 100k file range, but I was able to get around that issue by breaking my data up into smaller libraries.

The client side encryption was slightly problematic in the 1.x releases. Back then, you had to type your encryption passphrase into the server to create a new library. As of 2.0 you can create new libraries in the client without your passphrase leaving your local machine. You still can't dig through your file revision history without giving the server your passphrase; hopefully that functionality will be integrated into the client in the future.

I took a quick look at SparkleShare, ownCloud, and BitTorrent Sync, but none of them were a good fit for me. BitTorrent Sync only encrypts your data while it is in flight, ownCloud only supports server side encryption, and you can't properly store Git repos under SparkleShare.

Artists cloud backup.?

[Anonymous Coward]

Artist do it all the time using this service to backup all their important files.

Tresorit

[Anonymous Coward]

Tresorit is cross platform and work a pretty well. Don't know about pricing though. Maybe look into it?

Re: Tresorit

[Anonymous Coward]

I've been using it since beta. Works nicely for me...

Zero Knowledge backup

[Anonymous Coward]

Had the exact same problem with our accounting dept. who refused to back up locally. Tried 3-4 different companies and finally settled on Altus from Cybrix Group. funny enough it IS built on Backblaze Storage pods and uses Duplicati (open source) for backups but you can bring whatever flavor of client you want as long as it backs up over SSH.

We need the security community...

[Pav]

...to think about this HARD and give us some solutions. An insecure solution seems to work just as well as a secure one, and I'm a geek generalist... and I know what I don't know. Hopefully the big guns have already been thinking about exactly this problem for a while. We know there's no such thing as perfect security... but it would be nice to have something good, and some best-practice guides so we know how to avoid compromising ourselves too obviously.

Genie9 with Amazon Glacier Storge?

[Proudrooster]

Have you tried this?

http://blog.genie9.com/index.php/tag/amazon-s3/

Cheap to check-in, expensive to check out, not super fast, but you get what you pay for.

don't trust any (closed-source) company

[Anonymous Coward]

Mostly you're down to creating a secure cloud on your own (disclaimer: I'm involved with the archistar project). This might be renting a couple of cheap ec2 instances or distributing some raspberry pi's at different locations.

Good thing is, that it's actually not that complex. There's for example secret-sharing: you distribute data to ie. 4 servers, and define that you'll need at least data from 3 servers to recover the original data. This allows you to live with one storage server gone rouge. Sounds complicated but the math behind it is real simple. I hope that I'll be allowed to pulish a simple Java library next week (management needs some convincing towards GPL).

Synchronizing access and operations between servers is tough. This is BFT (byzantine fault tolerance) country -- I am working on a BFT implementation that focuses on simlicity but this will take a couple of months. The archistar github project should include a 'real' (tm) working prototype sometime in the next half year, but I really focus on keeping most of the knowledge within small libraries to people can actually create their own secure cloud software.

cheers, A.
(also: end of shameless plug)

SpiderOak

[Anonymous Coward]

Does exactly what OP is looking for.

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.

Re:SpiderOak

[Overzeetop]

Borrow this tin foil hat for a second:

      But only if you trust both your operating system and the binary executable they send you to interface with their system.
      Really, there is no truly secure method unless you are a crypto expert and roll your own - from the components in the machine to the bios to to the OS (though you could audit anything which is OS).

Of course the problem there is that you're relying on yourself, or your encryption and end-to-end computer knowledge, to be better than several billion dollars of cracking resources which could be levied against your one man system. And those are not very good odds.

FWIW, I use SO for backup, but their sync capability between computers to be dodgy (admittedly - that was 4 years ago, when I first needed a multi-computer sync provider; it's not practical to change providers for a business at a whim)

Re:SpiderOak

[Anonymous Coward]

FWIW, I use SO for backup

You use your significant other for backup? Or are you abbreviating some "well-known" backup service, so you end up writing a post that can only be understood by people who have no interest in your opinion since they already know more than you?

Yes, I get it. I can refer to other posts for context to decipher your abbreviation. Or maybe I can say, "what the hell? oh, maybe there's a clue in the 'subject', which I ignored because it usually contains meaningless phrases like 'Give up.' or 'Why pay?' or 'Tinfoil' or 'Precious bodily fluids'. Yeah, there it is derp, stupid me, I wish I'd seen that two minutes ago." The problem is your rambling attempt to reassure yourself is not useful enough to be worth this effort. Things are complicated enough from their essential nature, so please put the reader to less pointless work.

Honest answer

[Anonymous Coward]

NONE, you stupid fuck.

Google Drive + encfs

[Anonymous Coward]

Or really, anything that supports sync + encfs. I've got XX GB and XXXX files, and since its mostly backup or changes to small files, the sync program doesn't have to be very smart.

tarnsap

[Anonymous Coward]

Tarsnap is run by the former Security Officer of FreeBSD: http://www.tarsnap.com/design.html

There's also Crashplan, which says it encrypts everything before it leaves your machine. Tarsnap provides source code so you can verify their claim though. It should be noted that with Crashplan you don't have to use their servers: you can do peer-to-peer back up with another one of your machines (or even a friend's).

SpiderOak

[grub]

SpiderOak is quite decent. It's not the fastest at syncing, but their compression and deduplication works very well.

They claim zero-knowledge, have clients for Mac OSX, Linux, Windows, iOS and Android. You get 2 GB for free, give it a shot!

Just say no to cloud encryption

[TheloniousToady]

I don't use encrypted cloud storage. Instead, for secure backup, I use USB hard drives that I leave disconnected from the computer except during backup operations. This method places a priority on security (no hacker or virus can get to a drive that's disconnected), but it leaves me open to physical theft or destruction. I don't worry much about the former, but for the latter, I keep a copy at a relative's house.

Of course, this method doesn't solve the sync problem. I don't personally have a much need to sync data across devices (except for program code, which is easily synced across computers via Git), but for those of you who do, I recommend you use it only for data that doesn't really need to be secure, such as personal photos. Then, you can use any cloud service that syncs well, without regard to encryption.

Wuala

[JasonTaylor4724]

I've been using the free service from Wuala for a couple months. I'm not sure exactly how many files I have, but well over 100, but only about 600 MB total. I've had one issue where it reported a problem with not being able to sync a file. It recovered in about one minute without any intervention from me. 500 GB is $55/month. Servers are homed in Switzerland, Germany, and France.

No such thing as Zero Knowledge

[fast turtle]

If you want an encrypted cloud storage service, use any of them but encrypt things before you upload. That is the only way to ensure Zero Knowledge and that it's encrypted effectively. Test the hell out of things afterwards to ensure they're not corrupting your files/data.

I use dropbox and my private folder is encrypted using truecrypt. It works and I've never had a problem with the file being corrupted or sync problems but then I'm only using 2GB of storage. Most of my files are now on 32+GB flash drives and they're encrypted from the beginning.

Tahoe-lafs filesystem may be good for you

[Anonymous Coward]

Give a check to Tahoe-lafs , that could be what you are looking for.

From their page

What we mean by "security" is something different. The service provider never has the ability to read or modify your data in the first place: never. If you use Tahoe-LAFS, then all of the threats described above are non-issues to you. Not only is it easy and inexpensive for the service provider to maintain the security of your data, but in fact they couldn't violate its security if they tried. This is what we call provider-independent security.

Never pay for an "encrypted ____ service"

[Sloppy]

For all values of ___, never pay for an encrypted ___ service. Whether it's mass storage, email, or whatever. All service providers who offer this kind of stuff, are snake oil sellers. What happened to Lavabit this year wasn't news; we already knew about CALEA and have known for twenty years.

Twenty years in the tech world is a long time and ought to have conditioned your thinking by now. Even well-meaning, loyal professional allies can be subverted. The popular example case is government pointing guns (a.k.a. "court orders") at peoples' heads, saying to share the secret and keep it a secret that it's being shared. But really, once you even allow for that to be a possibility, all sorts of other things are possible. Replace the gun with a software bug exploit, replace the government with some random script kiddie with pretty much any agenda that you can think of. Anything goes.

Crypto is something that is performed by your machine, always done by software that you can understand (i.e. not proprietary). You never think about additional crypto that somebody else may or may not be doing, or by software not under your control. That's why you use a storage service that doesn't advertise crypto, you use a plain IMAP provider (if you some weird reason you're not handling that yourself), etc. Any service that tries to lure you with "security" is probably lying, unless by "security" they mean certain areas that intersect with reliability, such as DoS resistance.

Do NOT store on cloud (unless you own the server)

[Xicor]

it is not a good idea to store on any cloud company's server. the NSA can compell any company in the US to give up the decryption key for pretty much anything. if you want to store your stuff on the internet, either make your own server and store on it, or find a company based in a country that does not listen to the NSA or any other spying conglomerate

encrypt it yourself

[Xicor]

another idea would be to encrypt it yourself BEFORE putting it on a cloud storage server. this way even if the NSA compells them to give up data... they cant get access to it without YOUR key.

senderdefender

[Anonymous Coward]

No one has mentioned it probably because it's in semi public beta, but senderdefender.com does pure html5 client side encryption for transfer, and the guy is building a full clientless alternative for storage.

Space Monkey?

[Anonymous Coward]

How about Space Monkey? Zero-knowledge, locally encrypted, backed up to a "cloud" composed of other Space Monkey devices instead of in expensive, NSA-vulnerable datacenters.

CrashPlan?

[Anonymous Coward]

I've been using CrashPlan [http://crashplan.com] for some time now. Very reasonable price for unlimited data in their cloud, client side 448bit encryption, backup to friend machines, mobile device clients, ... I have had to restore a few times and it went fine.

Jungledisk?

[khb]

https://www.jungledisk.com/

I suppose it all depends on ones level of paranoia and which risks you fear most. Having all the data securely encrypted but in private homes means a couple of natural disasters and the data is gone.

One can layer encryption on top of theirs (as folks propose above with Dropbox) for an extra level of complexity.

Re:Jungledisk?

[stub667]

Jungledisk was really great until Rackspace bought it and killed development.

Small (closed source) client running locally handling the encryption, caching and allowing mounts via webdav, fuse & something-windows. proof of concept open source client for the remote storage in case Jungledisk went tits up. Pay for your storage direct to Amazon S3. Linux, OSX, Windows clients. Supported both mounting remote storage or syncing local folders.

But RIP, thanks Rackspace. There have been murmurs on there blog that indicate things might be starting up again, but no mentions of Linux at all apart from when things won't work - the Linux client hasn't been updated in years and stopped working fully with Ubuntu around the same time (no GUI client, so configuration and installation practically impossible). I thought they would have just taken the large user base (at one point, I think they claimed their users in aggregate were the largest users of S3) and pushed them away from S3 into Rackspace, but the project just went dark from *years*.

Commercial vs OSS

[Anonymous Coward]

Posting anonymously since I have an interest in this company. A company called Intermedia released a product a few months ago called "SecuriSync". A brief review is here. The product uses end to end encryption and allows varying levels of control as that article will mention. I use it regularly, as do most of the people I work with. We share data with our overseas offices using this method because of the Encryption. Box has some of the same functionality, but not all of it.

As commercial products go, this one is very well done. No learning curve for users, low learning curve for administration. *snark* Hell, even our Windows admins have no issues managing and using the product.

There is an obvious (or should be obvious) problem with _any_ commercial product though. It seems that if you get to a certain size Government agencies may step in and make a company do things. See Lavabit dropping their encrypted email for an example of exerted pressure on companies that want to do well. For now, this product is fine and secure. If it grows, I can't say that the company will not have to give in to pressure or face cancelling the product. I hope it does not get to that point, but we see what happened to others that failed to give in (again see Lavabit).

Just say NO!

[Anonymous Coward]

Best to just say NO! to "cloud storage". Its just renting space on someone elses server. Too many technical problema and security issues.

Re:Just say NO!

[Skapare]

That's why people should make a backup of their online cloud storage.

Open season on the cloud

[sdinfoserv]

‘Encrypted Storage Provider’. What fantasy land are you from? The NSA has forced every single on line provider to hand over encryption keys. A few have refused (lookup lavabit) and have shut down / walked away from their businesses). Meaning there is no more encryption. Everything is copied, tracked, evaluated, and reviewed. Everything. The US government has effectively killed the notion of corporate AND personal ‘cloud’ storage for anyone concerned about security.

Re:Open season on the cloud

[Skapare]

Encrypt your own data yourself before handing it over to some online/cloud storage provider.

Re:Open season on the cloud

[sdinfoserv]

They why bother with a cloud? Purchase your own servers. Store your own stuff on encrypted storage devices. BTW.... SSL has been cracked.

Bittorrent Snc

[Anonymous Coward]

I've selcected bittorrent sync for myself. Seems to be more reliable than other "no-server" alternatives such as aerofs.

Rule #1: outside of the US

[johanw]

First demand would be that the company lies outside of the US and has no US representation the US can target. Currently I know only of Mega to fulfill those requirements. Added bonus is that Kim Dotcom, the owner, is now seriously pissed at the US government so he won't cooperate with them.

Re:Rule #1: outside of the US

[Anonymous Coward]

Another one is http://www.jottacloud.com/. The servers are physically located in Norway.

You don't

[MerlynDavis]

Anytime the data is out of your physical control, it's compromised...

If you want truly secure backups, then you need to control both ends of the backup, as well as everything in between. If there's one thing Edward Snowden has showed us, it's that someone is watching *everything* online...and encrypted data is just begging to be examined, stored & hacked.

spideroak is good

[Anonymous Coward]

been using spideroak. your keys stay with you. they store encrypted data for you. as safe as can get on the internet (which in the end is not so safe no matter what)

Tahoe-LAFS

[cykros]

Tahoe-LAFS (https://tahoe-lafs.org/trac/tahoe-lafs) may be exactly what you're looking for. Redundancy, privacy, AND it's DIY. Grab a few VPS's (and perhaps an actual box your control or two), and have your own encrypted, private cloud.

With how cheap VPS's are getting, this may very well be your best option.

Failing that, use Truecrypt inside a Dropbox or and go nuts.

use BitTorrent Sync on your own server

[twms2h]

Get BitTorrent Sync from http://labs.bittorrent.com/experiments/sync.html and set up your own server, either locally or "in the cloud" (which you control). There are clients for all major platforms, including Android, and it works well. Traffic is encrypted and storage is only on computers you control yourself.
There is one drawback, though: It's not open source so you have to trust BitTorrent Inc.

Mega

[Anonymous Coward]

Mega.co.nz

Don't lose your PW. Make it sufficiently complex, it is part of your key.

Copy + (TrueCrypt or GnuPG)

[Anonymous Coward]

Use Copy + TrueCrypt or Copy + GnuPG. If you haven't heard about copy, it is basically a dropbox service that is giving away 15GB free (20 GB if you use a referral link like this one https://copy.com?r=FJ0ixF )

nothing is permanent

[shokk]

No matter what you think of the Cloud, you have resilient cloud like Amazon that goes away sometimes, or you can have cloud like Everpix, that refused to give me my pix after they went to price model and told me “screw you” and is about to go away forever.

Nothing is permanent. Eventually some natural disaster is going to make a huge chunk of data away for services that are not geographically redundant.

See

[Anonymous Coward]

Safenet-inc, see ProtectV