Ask Slashdot: Which Encrypted Cloud Storage Provider? 200
An anonymous reader writes "Almost three years ago, I started looking for a cloud storage service. Encryption and the "zero-knowledge" concept were not concerns. Frankly, after two weeks testing services, it boiled down to one service I used for almost 2 years. It was perfect — in the technical sense — because it simply works as advertised and is one of the cheapest for 500GB. But this year, I decided changing that service for another one, that would encrypt my files before leaving my machine. Some of these services call themselves 'zero-knowledge' services, because (as they claim) clear text does not leave your host: they only receive encrypted data — keys or passwords are not sent. I did all testing I could, with the free bit of their services, and then, chose one of them. After a while, when the load got higher (more files, more folders, more GB...), my horror story began. I started experiencing sync problems of all sorts. In fact, I have paid for and tested another service and both had the same issues with sync. Worse, one of them could not even handle restoring files correctly. I had to restore from my local backup more than once and I ended up losing files for real.
In your experience, which service (or services) are really able to handle more than a hundred files, in sync within 5+ hosts, without messing up (deleting, renaming, duplicating) files and folders?"
Ooh I know this one (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Re:Ooh I know this one (Score:5, Insightful)
Cloud is not a technical term. It's a business term.
Re: (Score:2)
Actually, it's a meteorological term...but who's counting?
Re: (Score:2)
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: (Score:3, Insightful)
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: (Score:3)
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 matte
Re: (Score:3)
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, a
Copy (Score:1)
Re: (Score:3, Interesting)
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/ [krebsonsecurity.com]
Re: (Score:2)
I'm curious, how would zero knowledge go with partial syncs?
Have a box live somewhere (Score:1)
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. (Score:5, Insightful)
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. (Score:5, Informative)
Indeed. Mostly give up the idea of having the host encrypt files for you. You never know if they have a backdoor of some sort. Find/write software (I use Arq) to encrypt files and then send the encrypted files to a host like Amazon S3. It's really the only way for the host to have the "zero-knowledge" you desire.
Re: (Score:2)
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: (Score:2)
Re:Give it up. (Score:4, Informative)
<plug>Or, better yet, use rsyncrypto [lingnu.com].</plug>
The advantage is that the incremental diffs don't accumolate on your computer, making your entire archive volatile (lose one rdiff, lose everything after that point). You just sync like you always do.
Theoretically, rsyncrypto is less secure. I am, of course, far from being objective about this point, but I believe this is not a practical weakness for most people, even with the renewed (justified) paranoia. Then again, the tradeoffs are clearly discussed on the project's site, so you are free to draw your own conclusions on the matter.
Shachar
Re: (Score:3)
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 identica
Re: (Score:2, Interesting)
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. (Score:4, Informative)
Uhm, that property is exactly what you DON'T want in an encryption algorithm. There's a reason we don't use ECB mode. And if you rely on compression for security, you're doing something wrong. Anyway, if you just want to be able to diff encrypted files, what's wrong with counter mode? No need to invent a new mode, right?
I also don't understand why RSA is needed here. What's the point of asymmetric crypto when there's only one party involved?
1. Rsyncrypto is very very very far from ECB. I am hard pressed (but open to counter examples) to find a real life file that exhibits cypher text repetitions due to plain text repetitions. This is not the case with ECB, as clearly evident from the ECB wikipedia page.
2. Your statement about compression is strange. It is quite customary to compress before encrypting. Partly because compressing after encrypting makes no sense at all, but also because compression increases the bit entropy of the data, making known plain text attacks harder. It is true that rsyncrypto is more sensitive to such things than other algorithms. It is this little thing I like to call a "trade off". Anticipating your objection, ECB with compression is better than ECB without, but still pretty horrible. You will get repetitions the length of the compression blocks. Like I said above, this is not the case with rsyncrypto.
3. RSA is needed because you do not want to encrypt all files involved using the same symmetric key, but you also don't want the secret your backup depends on to need constant updating. With this scheme, you only need to reliably and securely store one key (the RSA key), but each file is encrypted with a different key.
Counter mode is horrible for this application, for two reasons:
First, any change to the file that adds or removes even a single byte causes the entire cypher text to change from that point on. This makes it quite rsync unfriendly indeed. This is not the case with rsyncrypto.
The more horrible reason, however, is that counter mode has zero resilience to key reuse. A simple XOR of the cypher texts from two encryption passes will cancel out the encryption, key and all, and leave you with a XOR of the plain texts.
Shachar
Re:Give it up. (Score:4, Informative)
Eh, one-time pad has exactly that property: if you use the same key to encrypt similar files, you get similar output. And nobody complains about one-time pad. ;)
That's not a one-time pad if you use it more than one time. It's extremely insecure to use a one-time pad twice. An attacker can XOR both ciphertexts to remove the keystream and be left with the XOR of both plaintexts. From there, they just have to figure out one of the plaintexts, and they can decrypt the matching parts from the other.
Re: (Score:2)
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 thin
Re: (Score:2)
I have posted an answer to AC below (in this comment [slashdot.org]). 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 t
Re: (Score:2)
> 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 ke
Re: (Score:2)
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 [slashdot.org], 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 effor
Re: (Score:2)
> 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 t
Re: (Score:2)
> 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
Re: (Score:2)
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: (Score:2)
Could we take this offline (e.g. IM)? Discussing this way seems highly counterproductive.
Re: (Score:2)
Email me.
Shachar
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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 :)
Re: (Score:3)
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: (Score:2)
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: (Score:2)
Knowing plaintext and ciphertext does not make retrieving the key easier for real cryptosystems.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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. ecry
Re: (Score:2)
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: (Score:2)
Re:Give it up. (Score:4, Informative)
I'll go you one better than rsnapshot (and make no mistake, I think rsnapshot was an absolutely wonderful idea and a superb invention).
Just use rsync to a zfs backup point. Take a zfs snapshot after each backup, or not; your call. Make zfs snapshots whenever you feel like it. There is no undue performance or storage problem with many, many snapshots. You could make one snapshot a day and have a simple cron job that deletes all the snapshots older than the last couple of weeks, except retains all the Sundays for a couple of months, all the first Sunday of the months for a couple of years, and all the first Sunday of the years forever. That would leave you with about 50 snapshots plus 1 for every year, which is very light. Or suit yourself with your own schedule.
Zfs snapshots are essentially instantaneous to make, and very quick to delete. Every single snapshot is a directly addressable representation of the entire store: every file. The differential mechanics are all handled by zfs internally. It's as if you are making a full (not differential) backup every day and somehow finding and financing a small city to store them all in. But your actual storage is only differentially larger than a single backup. OK, so far that's essentially what rsnapshot does, with a bunch of code.
The advantage over rsnapshot is efficiency and simplicity. All those zillions of hard links behind rsnapshot's strategy are time consuming to create and delete.
Obviously, either way you do have to be reasonably smart about database files, sparse files and open files.
BTW, rsyncing an encrypted fs to a remote, well, err, it doesn't really work. Because normal encryption turns small localized file deltas into completely different file contents, turning every rsync in which a lot of large files are modestly changed into a huge data transfer. You can use rsyncrypto to try to work around this, at the cost of some of the security of the encryption.
Re: (Score:3)
+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 LON
Re: (Score:2)
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: (Score:3)
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 sim
Re: (Score:2)
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: (Score:2)
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 binar
Why Pay Somebody Else? (Score:4, Informative)
It's pretty secure, you can share files with others, it's available for all major OSes (including iOS and Android), you don't have to mess with any 3rd parties seeing your data... what more do you want?
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
"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?
Re: (Score:2)
"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, co
Roll your own - but choose the right SW (Score:3, Interesting)
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: (Score:3)
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 o
Re: (Score:3)
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 [branchable.com]
None of them. (Score:5, Insightful)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
EncFS might just do what you and I need!
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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,
Re: (Score:2)
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 othe
Focus on your local encryption method first (Score:5, Interesting)
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 [bitbucket.org] 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: (Score:2)
TarSnap (Score:5, Interesting)
tarsnap.com. Not very user-friendly, but it does what it says on the tin.
Go with what works (Score:2)
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.
DIY (Score:2)
What's the point? (Score:2)
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.
filecloud (Score:2)
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 (Score:5, Informative)
I use Truecrypt's encrypted drive containers in my local Dropbox folder. The file sync'd to Dropbox is encrypted when the sync occurs, so that is all they ever see. Because Dropbox does a binary diff of the file and only uploads the differences which makes syncing large encrypted files feasible.
I've seen some chatter that Truecrypt may have been compromised - Bruce Schneier and Snowden use it so I'll trust in their judgement.
Re: (Score:2)
That's a pretty good idea, actually. I think I'll go this route myself as well.
Re: (Score:2)
Seafile (Score:4, Informative)
I use it for several months now and it is both fast and reliable (much more than the owncloud versions I tested previously). It handles my whole pictures collection (about 90GB) very easily. You can install your own Seafile server (there's even a raspberry pi version), or buy storage space from them. Clients are multiplatform (Windows, Mac, Linux, Android, iPhone/iPad).
Re: (Score:2)
I've been using Seafile since April [patshead.com] 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
We need the security community... (Score:2)
Genie9 with Amazon Glacier Storge? (Score:2)
Have you tried this?
http://blog.genie9.com/index.php/tag/amazon-s3/ [genie9.com]
Cheap to check-in, expensive to check out, not super fast, but you get what you pay for.
Never pay for an "encrypted ____ service" (Score:2)
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
Do NOT store on cloud (unless you own the server) (Score:2)
encrypt it yourself (Score:2)
Jungledisk? (Score:2)
https://www.jungledisk.com/ [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.
Open season on the cloud (Score:2)
Re: (Score:2)
Encrypt your own data yourself before handing it over to some online/cloud storage provider.
Rule #1: outside of the US (Score:2)
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.
use BitTorrent Sync on your own server (Score:2)
Get BitTorrent Sync from http://labs.bittorrent.com/experiments/sync.html [bittorrent.com] 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.
nothing is permanent (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
However you don't know when this is happening. So cannot assess and manage you
Re: (Score:2)
Re: (Score:2)
Because people want automated off-site backups (a good idea), and not everyone has the knowledge to administer a remote hosted server?
Re: (Score:2)
Re: (Score:2)
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 knowle
Re: (Score:2)
That's why people should make a backup of their online cloud storage.
Re: (Score:2)
Re: (Score:2)