[deleted]
[citation needed]
[deleted]
Wuala: Secure Cloud Storage
171–180 of 207 posts
Re: Wuala: Secure Cloud Storage
#172Earlier quoted context omitted.
Mobile API?
It's powered by the Tent protocol ( https://tent.io ) so by definition, yes. The library is also open for anyone who wants to implement their own alternative, compatible apps, and alternative compatible libraries could be implemented since it's all just specific (documented) types of Tent posts.
Is tent designed for large-scale file storage? I always thought of it as an app.net/twitter alternative.
Re: Wuala: Secure Cloud Storage
#173Seriously? Wuala is a service run by LaCie. LaCie is owned by Seagate, an American corporation. It doesn't matter where the servers are, because all the important decisions will be made in Cupertino, California. 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 long…
Why not just store a TrueCrypt volume(s) in Dropbox?
Because TrueCrypt is not exactly "free and open source" software either.
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]"""
Re: Wuala: Secure Cloud Storage
#174Seriously? Wuala is a service run by LaCie. LaCie is owned by Seagate, an American corporation. It doesn't matter where the servers are, because all the important decisions will be made in Cupertino, California. 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 long…
> is it worth the trouble if Wuala's clunky client takes 100 times longer than Dropbox to sync a file between two devices 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.
I have absolutely no intention to spread FUD about client-side encryption, and in fact I don't think Dropbox's speed advantage has anything to do with (lack of) encryption. Encryption shouldn't have any noticeable impact on sync speed, since modern CPUs can encrypt a file a hundred times over in the time it takes to upload/download it. I agree with you and suspect that it has more to do with crappy architecture.
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.
Re: Wuala: Secure Cloud Storage
#175Seriously? Wuala is a service run by LaCie. LaCie is owned by Seagate, an American corporation. It doesn't matter where the servers are, because all the important decisions will be made in Cupertino, California. 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 long…
BoxCryptor[1] has been my choice. I've been now using it on daily basis together with Dropbox and I'm satisfied. Boxcryptor works on the client side and stores the encrypted files on Dropbox folder as ordinary files. It is also possible to encrypt filenames. Boxcryptor comes from Germany.
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.
Re: Wuala: Secure Cloud Storage
#176Seriously? Wuala is a service run by LaCie. LaCie is owned by Seagate, an American corporation. It doesn't matter where the servers are, because all the important decisions will be made in Cupertino, California. 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 long…
BoxCryptor[1] has been my choice. I've been now using it on daily basis together with Dropbox and I'm satisfied. Boxcryptor works on the client side and stores the encrypted files on Dropbox folder as ordinary files. It is also possible to encrypt filenames. Boxcryptor comes from Germany. The only drawback I have encountered is that Dropbox limits the path names to 255 characters. With encrypted file/folder names thi…
Yeah, tried that too. Also tried CloudFogger [1], which has a similar feature.
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.
Re: Wuala: Secure Cloud Storage
#177Earlier quoted context omitted.
I like Boxcryptor since it encrypts each file individually rather than the whole volume. However, the file names are exposed.
encfs. Encrypts each file individually and file name are encrypted.
encfs sometimes generates very long path names, which runs against the 255-char limit that Dropbox imposes if you have any Windows computers linked to your account. Last time I tried it, the filenames were silently corrupted and much data was lost.
Re: Wuala: Secure Cloud Storage
#178Earlier quoted context omitted.
That's not true. Dropbox uses librsync so small changes of big files yields small diffs, thus TrueCrypt volumes work just fine with Dropbox.
Speaking out of ignorance here: But aren't TrueCrypt volumes completely changed when you add/remove something? I'm thinking similarly to a hash: The slightest modification changes it completely.
But aren't TrueCrypt volumes completely changed when you add/remove something?
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:
Re: Wuala: Secure Cloud Storage
#179Earlier quoted context omitted.
Hi Gianluca, What about when files/folders are shared? Is encryption dropped so anybody with a link can have access?
No, you can read everything regarding this matter here http://wualablog.blogspot.ch/2011/05/wualas-encryption-revis... . Regarding your question, you'll find your answer here http://www.wuala.com/blog/2011/04/wualas-encryption-for-dumm... (3. Sharing)
So basically the encryption key for the specific folder is in the shared url, and wuala servers decrypt the content to the user's browser.
If sharing is disabled then a new key is created and used locally to decrypt/encrypt directly from the client.
Thanks!
Re: Wuala: Secure Cloud Storage
#180"""Do you plan to open the source code? 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.
So.. an alternative, but not the solution we need.
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: