wuala.com
http://www.lacie.com/us/company/news/news.htm?id=10722
Now, client-side encryption is a much more interesting aspect of their service, but is it worth the trouble if Wuala's clunky client takes 100 times longer than Dropbox to sync a file between two devices? Ditto for SpiderOak, JungleDisk, and every other backup/sync solution that I've used so far that boasts client-side encryption. And it wasn't due to Dropbox's deduplication, either. Some of them just talked lazily with the server for several minutes before they even started to upload/download any files.
No, the crypto in TrueCrypt doesn't amplify the number of changed blocks. But it does disperse the changed blocks throughout the encrypted image, and this does result in higher bandwidth used during the sync (at least with DropBox). Here's an analysis I did a few years ago:
The underlying problem is that you're trusting closed client software from a third-party. Once that is running on your system, arguably it's game over as far as what Dropbox or its like can and can't do to you.
(If you trust them, ok. But when documents state that "they're next", many of us start to wonder. And again, this isn't just access to a server. Through their client software, this is access to your machine, that you've already granted.
Admittedly, I'm describing the typical Dropbox user scenario and not where the client is manually applying -- or not -- each update, and somehow supposedly gaining insight into the capabilities of each update/version before doing so. And I'm also ignoring various forms of restricting the access of the Dropbox client, although if they really want you, they and parties using them would have extensive resources to apply to breaking out of such constraints.)
Let me take the opportunity to also thank you for writing up your email best practices. I hope to implement them or something similar for myself.
One of the challenges for me in all this is keeping up including with the implementation details. It feels akin to swimming upstream, with the current outpacing me.
FYI this article suggests to use encfs for an encrypted folder in your dropbox, this comment https://news.ycombinator.com/item?id=5855465 suggests that this might not be a wise choice, so you might want to (re)consider that part.
http://en.wikipedia.org/wiki/Truecrypt#Reasonable_paranoia
"""It is challenging to create binaries from source code that match the official binaries bit-by-bit for purposes of verifying their integrity due to compiler options
...
There has been no known comprehensive review of the source code by a qualified cryptographer.[46][44] Thorough security code review and testing is hard, tedious, and painstaking work, and very few people have the skills to do it. There was, however, a functional evaluation of the deniability of hidden volumes in an earlier version of TrueCrypt by Schneier et al. that found security leaks.[47]"""
Is this some general FUD about encryption being slow, or an actual measurement?
Maybe all client-side encrypted solutions happen to be crappily implemented, but I don't think that client-side encryption would necessarily lead to something noticeably slower.
Anecdote: SpiderOak takes 5 minutes synchronizing metadata with the server if I start it on a laptop that I only use occasionally. That's how long it takes for the client to find out what files I changed in my other machines in the meantime, including all the files that have nothing to do with this particular machine. Nothing gets synched during this time, and the client sometimes consumes a whole CPU core for extended periods. It's very annoying when I just want to see a few files that I know I changed in another machine. I understand that the protocol needs to be different if all the encryption is done by the client, but this is just ridiculous. Wuala is no better in my experience, although YMMV depending on your use case and filesystem structure. (I have over 50GB of data in my SpiderOak account, made up of a quarter million files. At one point I had over 100GB stored in there, and it was a PITA to sync any files at all.)
As an interesting comparison, Microsoft SkyDrive performs just as terribly as SpiderOak does when you give it a few hundred folders with ~100K files to sync, despite the fact that it does no client-side encryption. It just sits idle for half an hour or more, scarcely utilizing any network resources. I have no idea what it's doing. Maybe it does sleep(random()); between each upload. In any case, encryption isn't making it slow. It's just bad app design, bad protocol design, and perhaps overloaded servers.
Dropbox, on the other hand, immediately begins to upload/download my files, and once it's done scanning any large folders, its speed is only limited by the bandwidth of my Internet connection. When I need to do a presentation, I can just work on the .pptx file in my Dropbox on my desktop PC, take my laptop to the conference room, and expect the .pptx to be there as soon as I wake my laptop. That's the meaning of convenience. By the same metric, none of Dropbox's commercial competitors (perhaps with the exception of Google Drive, which I don't use) are even close to convenient.
It's not really about the encryption directly; it's about the way the database design has to change to support zero knowledge (the server can no longer do the database work.) Things like garbage collection have to happen client side. Described in detail here: https://spideroak.com/blog/20091026143000-why-and-how-spider...
FYI, when SpiderOak first starts running, like any backup software, it has to scan your filesystem to see what may have changed while it was shutdown, and that can take a lot of IO and CPU if you have many folders and/or many small files (hundreds of thousands). (SpiderOak works with any folders you like, including externa/network drives, not just one folder like Dropbox.)
In a profile, basically none of this CPU time is spent in the crypto module, just mostly for unserializing the per-folder journal to compare state. SpiderOak does some optimizations with directory hashing to avoid having to open the journal to scan for specific changes in unchanged folders, but there are some situations where that optimization is defeated (such as if you remount a file system with changed gids, inode IDs, timestamps, etc.)
Anyway, once it's running, it uses the operating system facilities on Linux/Mac/Windows to notice changes automatically so rescanning the whole backup selection after startup is not usually necessary.
In any case, thanks for your interest in SpiderOak. :)
I have a quick question for you which might be of interest to others as well:
Why isn't SpiderOak open source yet?
I've read your FAQ answer[1] on this, however it doesn't really give a concrete explanation, besides "soon" and "licencing concerns" which is definitely disappointing.
I currently use my own, EncFS based sync solution, however I'd love to be able to use SpiderOak, or a third party open source application which supported syncing with SpiderOak (if you'd ever consider exposing an API/Protocol which allowed such.)
This is the only reason I'm not using your service currently, however I love the concept and hope you'll take it into consideration. It's likely I'm not the only one with similar concerns.
[1]: https://spideroak.com/faq/questions/35/why_isnt_spideroak_op...
Fortunately, I only need to start up SpiderOak once in a while, because nowadays I put my computers into hibernation instead of shutting them down and starting them up again. I also noticed that the more often I use SpiderOak, the less time it takes to start up, presumably because there's less delta to process. Also, as you said, once SpiderOak is up and running, it's relatively fast. Rest assured that the performance issues, although annoying, have not dissuaded me from renewing my SpiderOak Plus (100GB) account once again last month.
I also like the fact that SpiderOak's "Queue" and "Log" screens tell me exactly what it's doing at any given moment. Waiting becomes a lot more tolerable when I know what I'm waiting for. I hate backup tools that assume the user is too dumb to understand what's going on behind the scenes. Even Wuala's Upload/Download queue never seems to work properly.
Wuala is seriously slow and clunky piece of software. Period.
The only drawback I have encountered is that Dropbox limits the path names to 255 characters. With encrypted file/folder names this can become an issue especially with some Java projects.
I think this really gives me the best of both worlds. Security for the files I think need it and the Dropbox infrastructure for syncing files.
When it comes to performance, a layer of encryption on top of Dropbox is much better than any competing solution that has client-side encryption built into it, because you're still using Dropbox's awesome infrastructure and lightening-fast sync protocol.
But I ran into the same problem as you did. The 255-char limit sucks, and it's completely unnecessary because even Windows/NTFS allows you to use longer paths (up to 32KB) if you know which APIs to use. I suppose fixing this is not a priority for Dropbox because you normally don't run into it unless you use encryption, and Dropbox has no reason to encourage the use of encryption among their users.
I have no idea what the performance difference is (and clearly , neither do you), but the answer to your question is "yes". For some people, at least. It's a must-have feature for some people, not a nice-to-have-as-long-as-it-doesn't-inconvenience-me-too-much feature. Some people have data that they'd like to keep synced across systems that they simply can't keep in unencrypted form on a third-party server, no matter how much trust they have in the company that owns the service.
Of course, there are a bunch of different ways to keep your data secure and still have it be available to you on different systems, and non-open-sourced cloud storage with client-side encryption is still an imperfect solution, but it is a solution that is perfectly reasonable for many people.
Currently not. Opening the source code of Wuala would consume quite some time and effort, and commitment to maintain it. If you are a software engineer and would like to see how Wuala works, feel free to apply for a job at Wuala."""
ಠ_ಠ So.. an alternative, but not the solution we need.
A non-answer if I've ever seen one.
What about someone who applies for a job at Wuala, gets rejected, but still wants to look at the source code?
I don't think that I will be able to trust secure trough obscurity solution.
Unless you host the data yourself, if you don't trust Wuala there is no guarantee the binaries you use are built from the source code you have.
Technically if the client is not sending not encrypted data and encrypts without a foul, then nothing they can do on the server-side can cause leaking your data.
Through auto updates you can make sure that you get the backdoored version or you can have an exploit within the software to allow "silent" remote updates (good luck finding that).
So well... Either you do it end to end, or you trust the third party.
Furthermore, for the software to be able to even auto-update, it would have to be able to change its own binary. I don’t know how this particular piece of software works, but it is possible to run FUSE ‘drivers’ as a user on Linux, with the binary safely sitting in /usr/bin, hence removing any possibility to auto-update (if you don’t do shady tricks like placing an ‘updated’ binary somewhere and changing the user’s PATH – and even that could – in theory – be avoided by mounting all user-writeable things noexec).
> The package installs Wuala and registers our repository for further updates.
This is even more harmful that it sounds, as someone who has repo access (be it some evil staff member or, more possibly, inturder) may push not only malicious Wuala build, but any package with higher version number than in other repos (say, a linux-image-999.999 with a bundled rootkit) and if user was incautious it will be installed on system update.
Completely agree. We need 100% opensource client-side encryption tools.
And at least in this space (cloud backup), we already have it, thanks to HN's own cperciva:
First, this is how Wuala works: You as an user place a file in the client. The file gets encrypted (including using your password and username) and then gets uploaded and split into different pieces. We are currently using AES-256 for encryption (and RSA 2048 fpr signature and key exchange when sharing a folder and SHA-256 for integrity checks). The password does NOT get transmitted and there is nothing like a master key or similar. That means in worst ever case if someone would have access to our servers somehow, they'd get a piece of encrypted data which is not readable and not decryptable (not even for us as the provider.
Secondly, some people tend to confuse security with anonymity. Wuala is secure, but how about anonymity? We have your email address, your username and we know how much storage space you have. As you see, that is not anonymous, but has nothing to do with the security of your files.
Are we planning to open source the code? Eventually yes, but as we already stated, this takes a lot of time and effort. Oh and yes, we are nice guys. Not because we're Swiss, but in general :)
Some purported info about data protection for Switzerland:
http://www.dataprotection.ch/en/disclosing-personal-data.asp
> Restrictions on disclosure
The DPA does not permit the disclosure of sensitive data or personality profiles to third parties without lawful justification. The consent of the data subject can constitute a lawful justification. Breach of this prohibition is an offence if knowledge of the sensitive data has been gathered in the course of a professional activity requiring knowledge of such data and can be punished by a fine of up to CHF 10'000.--. If the fine is not paid, it can be replaced by imprisonment for up to 3 months.
And Wuala's own policy: http://www.wuala.com/en/about/privacy
> 6. Disclosure to third parties
Basically, your data is not transmitted to third parties. However, LaCie may release personal data if the law requires it to do so or in the good-faith belief that such action is necessary to comply with any laws or respond to a court order, subpoena, or search warrant or to protect LaCie's rights and interests. Furthermore, you expressly agree that LaCie can disclose personal data to identified third parties (e.g. owners of intellectual property rights) and/or government enforcement bodies in order to enforce the General terms and conditions, particularly in case of founded indications that the laws or the rights of a user or of third parties, particularly copyrights, other industrial property rights or personal rights, have been violated , insofar as such is necessary.
Isn't that one of those entirely vacuous sentences. Basically they have a disclaimer there that so long as it's in their interests to release it they can. So offer some money, "oh yes we're inclined to make money here's the data".
I'm still looking for a locally encrypted Dropbox-alternative. So if any of you are making one, please speak up :)
(Edit) I should specify that it was the user experience that made me give up on Wuala, and any proper Dropbox alternative would need to offer at least decent user experience. Looking forward to trying the alternatives you are suggesting :)
If you want to host it yourself there's Seafile but I haven't seen any in-depth review of it and it's Chinese-based (if that's a problem [for you]).
Bittorrent's Sync almost gets there, but isn't open source. I haven't really looked at it, but ownCloud might do what I want.
I'd like to know more about this. Working on a encrypted FOSS alternative to conventional storage would totally be a perfect side project
Then it also seems to do a full scan of teh entire folder each time it sync's, if you then have for example your iPhoto library (usually a few GBs) there, the sync process will consume lots of CPU and tend to be out of date across devices.
Wouldn't that be nice?
At this point: gpg keys shared among chains of trust. Need the file X? DHT consulted says the file is stored in accounts Y, Z and W (plus at your home - we don't want users to kill our files, right?). Take the file, decrypt it.
You can do this on Linux (and presumably OS X, as well) fairly easily.
On Windows, there is a single-developer port of EncFS, which from what I've heard works fairly well: http://members.ferrara.linux.it/freddy77/encfs.html
A quick search turns up a guide which (at first glance) seems fairly comprehensive on how to set this up if you're unfamiliar with the way EncFS works: http://www.howtogeek.com/121737/how-to-encrypt-cloud-storage...
With that said, if you're worried about any highly confidential data, potential for watermarking attacks or plausible deniability, this is not the right solution for you.
If you're looking for a way to protect your data from dragnet surveillance, your provider, or low-level law enforcement interception, this is a great drop-in solution.
I'd say the real world risk of this is (fairly) low, however if you're legitimately worried about it, you can use EncFS over a network share or FUSE file system, to your own systems. In which case you'd be using entirely open source software.
If you're that worried about security though, you'd probably be better off using a container based encryption method, anyway, as it wouldn't leak timestamps, file sizes and other data which could be sensitive. EncFS has some known issues with metadata leaking, but it's a decent solution for most general use cases.
Of course, just like web servers, the server implementation and hardware it runs on has a lot to do with it. One of our top development priorities is building a very robust, scalable self-hostable server implementation to power apps like file sync and even more demanding applications.
> Make sure Java [...] is installed.
:C
The only thing that one can be suspicious is whether they are transferring your key or not. But, at least they claim your data is safe and encrypted, while Dropbox, GDrive and similar services don't even pretend that they encrypt your data.
However, would still love to see an open source product like this that I can truly trust.
would it make you happier if they kept their services the same, but just pretended to introduce encryption? ;-)
> would it make you happier if they kept their services the same, but just pretended to introduce encryption? ;-)
No it wouldn't. What I wanted to say is that Wuala at least claims that they do client side encryption. I believe them, but someone else doesn't have to. So, data being safe with Wuala has probability between 0-100%, while data being safe with Dropbox has probability of 0.
It's an offline application that runs on your computer that is transparent to your actions. You just use the drive BC mounts instead of where Dropbox tells you to use, the rest automatic.
git annex initremote mycloudbox type=S3 encryption=my@gpg-email.com datacenter=EU
git annex copy --to=mycloudbox myfile
git annex whereis myfile
whereis myfile (2 copies)
(...) -- here
(...) -- mycloudbox
ok
They should have offered to replace your drive, but no more. Hardly unscrupulousness.
However, you should have backed up your stuff in more than one physical place and never assumed that the disk was entirely reliable.
Buy a quality drive enclosure and a quality hard disk, put them together yourself and make sure you have a half decent backup strategy.
Edit, 4 years 10 months. Lacie merge in 2010
Hard drives and other storage mediums fail all the time, this is not hyperbole, these devices are not designed for 100% ever. The companies work on the assumption that if they fail they will offer a replacement within warrenty, but expecting to get data recovery for free is not reasonable.
If I was you I would spend a thousand dollars on getting the data off and never making the mistake of keeping important data on 1 storage medium again. Whenever I meet someone who has all their precious data on 1 device like this I tell them that you might as well just throw all that data away now, thats how much you care about it.
Sorry if it hurts dude, just spend the money to have the platters recovered individually and never make the mistake again.
This isn't security, it's security by obscurity - in the best case, mind you.
Could you provide a link to those hints, please?
But “this is more than just a data center,” says one senior intelligence official who until recently was involved with the program. The mammoth Bluffdale center will have another important and far more secret role that until now has gone unrevealed. It is also critical, he says, for breaking codes. And code-breaking is crucial, because much of the data that the center will handle—financial information, stock transactions, business deals, foreign military and diplomatic secrets, legal documents, confidential personal communications—will be heavily encrypted. According to another top official also involved with the program, the NSA made an enormous breakthrough several years ago in its ability to cryptanalyze, or break, unfathomably complex encryption systems employed by not only governments around the world but also many average computer users in the US. The upshot, according to this official: “Everybody’s a target; everybody with communication is a target.”
In the end, IMHO, the only software which can be trusted is the FOSS. From this perspective Dropbox is good: the client is open source. Of course nothing is encrypted in there.
Still, FOSS solutions are indeed better from a security perspective.
On the first I was like "ops, said bullshit"... but actually it seems like it's GPL.
For anyone curious about the technology behind here is an early tech talk from one of the founders. It may be a little bit outdated now but still interesting: http://www.youtube.com/watch?v=3xKZ4KGkQY8
To secure my data, I just use BoxCryptor. It creates an encrypted volume within my Dropbox. It is free for non commercial use.
One advantage is that there's no third-party storage of data involved.
When push comes to shove, governments everywhere will have no qualms about invading people's privacies en masse.
Human nature is the same everywhere. Power corrupts everywhere.
When power is centralized corruption effects are worse, exactly like when software is centralized failure effects are worse. Distribution is the answer. Distribute power, in a way in which it cannot be exploited.
I'm not an expert in politics, but I guess that communism had this kind of principle, but it totally failed in implementing it.
No box is ever unbreakable, however, the chance of breaking it is much bigger if you have the locksmith holding on to the box.
I've talked a little bit about this in my humble blog post not too long ago about a simplistic view of security in the cloud: http://vuongnguyen.com/personal-business-cloud-security.html.
-V.
Cryptree: A folder tree structure for cryptographic file systems - http://boga.googlecode.com/svn/trunk/res/Docs/wuala-cryptree...
(No, I'm not connected to Wuala in any way, I don't even use the service myself, but as an alternative to Dropbox I think its a good one.)
-- a company with no connections to the United States. Ideally, it should be privately owned by a foreign individual known for strong privacy views and who has promised never to sell.
-- local encryption
-- open source ("trust but verify")
-- actually works
Wuala, from the comments here, meets only one of those four requirements.
It's a Swiss company, owned by LaCie (French) which is again owned by Seagate (US). So I would say that's half a point.
Data is en-/decrypted locally. There's a reason they don't have a web interface, but require you to use the client.
It's indeed not open source. Would be nice if it was.
And it actually does work. There's room for improvement (isn't there always?), but in my experience it's working well.
In fact, they opened a DC in Canada and not the U.S. and one can guess why.
Because it's culturally closer, I'd guess. OVH is a French company, and their Canadian data center is just outside of Montreal.
It's not Wuala's fault, but forcing me to put java back on my desktop is a big hurdle. It's going to take an absolutely amazing piece of software to make me deal with that horrendous bug-ridden security hole again.
But I don't see how the desktop runtime is a security hole (you're running binaries you trust outside a sandbox) and I very much doubt it's any more buggy than your average Python, Ruby, Node.js, etc. runtime. Or, for that matter, your average native library.
Straight up unix filesystem (ZFS) so you can point duplicity[2] (or anything else) at it.
If you need something like dropbox, we are NOT for you.
We have special rates for HN folks. Email us.
Another annoyance is that you cannot change the size of a drive after you create it [1] and it doesn't shrink to fit the data either.
> The ciphertext block size used by TrueCrypt is 16 bytes (i.e., 128 bits).
Meaning one bitflip should only sync 16 bytes since dropbox only transmits deltas. Of course this now depends on dropbox' delta sync implementation.
From a quick google search [1]:
> For what it's worth, Dropbox claims to create hashes on every 4MB of each file. That way, if you change a contiguous 2MB of a 100MB file, it will likely only need to upload 4MB (or 8MB if you cross into a second 4MB block) to re-sync the file.
So worst case if a bitflip happens to change a truecrypt block that doesn't align with dropbox' chunks you're looking at around 8MiB. That's still quite an amout for a bitflip but i think it's feasible with todays connection speeds.
[0] http://www.truecrypt.org/faq
[1] http://serverfault.com/questions/52861/how-does-dropbox-vers...
Although this won't help if you get a rootkit in an update, since the source is closed.