Hacker News Reader

Comment by joejohnson | Hacker News Reader

There are many other issues with adding encryption to an existing service. Take Dropbox as an example. If Dropbox allowed each user to manage their own private/public key pair, then Dropbox wouldn't be able to see any of your data, and this couldn't use de-duplication. This means they need to actually allocate 2GB for every free user; no longer could they count on multiple users uploading the same files. Dropbox would have no way of knowing. Additionally, every minor change to a file would result in the entire file needing to be re-uploaded. The "previous versions" of each file would need to be re-worked, etc.

There are lots of technical issues with just slapping some crypto on to an existing service. User management of passwords/keys seems trivial compared to these problems.

View on HN

As far as I know, you could do delta uploads with encrypted files. It should not be any different if the file itself is encrypted. For the same reason you can e.g. use rsync delta syncs with encrypted files...

There should not be any similarities between an encrypted file and the same file encrypted again after some changes are made to the file. Even if you just change one character in a text file.

I'm sure the rync delta transfer algorithm still works fine with encrypted files, but the changes for encrypted files are going to be calculated as 100% so you're not going to save anything.

You could do the delta on the client side before you do the encryption. That's what Arq does.

I took this to mean that since the user side has full access to the plain text, the user client could calculate a delta, then encrypt it and upload just the encrypted delta.

You'd still need to pull it all down and apply the deltas each time you put it somewhere new, but it would work. Possibly with a 'full version' on some longer schedule. As a bonus, you'd get automatic history, which Dropbox stores anyway.

It's still got issues, no doubt, but it could be done, no?

What you describe is nearly exactly how an encrypted backup service called tarsnap works. Basically, it provides de-duplicated, compressed backups to the Amazon S3 cloud using local key files. The difference here is that it deals with data in blocks, not explicit deltas. This means you have no concept of 'history', and separate archives on the service have no strict dependencies on each other (they merely reference certain blocks that have been uploaded). It uses a cli-only interface inspired from tar, and is very handy for cron backups of important data.

There is also a project called ddar, which is designed to provide merely the de-duplication of tarsnap so you can setup your own repository (tarsnap only works with its service).

This is nonsense. Block ciphers do exist.

Yes they do, though I don't think that was what he was referring to.

You might be thinking of a hash. Hashes have a cascading effect where a single bit change in the source file has a "waterfall" effect during the hashing where the output is drastically different from the hash of the unmodified input.

I don't think this is necessarily the case with all encryption mechanisms.

Bitcasa says they have a patented algorithm with both client side encryption and de-duplication. Here's related Quora: http://www.quora.com/Bitcasa/How-can-Bitcasa-possibly-achiev...

Probably something along the lines of E(data, H(data)), I'm guessing.

I'd be very surprised if this were patentable. The same basic technique was mentioned offhand in literature as early as 2003 (http://static.usenix.org/events/hotos03/tech/full_papers/mis...), and I suspect the idea's even older.

That kind of model, of necessity, leaks information about the files you are uploading, which is a major negative. It is now possible to tell if you've uploaded the same document as somebody else.

I'd love to know how they are doing it, though. I'm not sure I believe there is a way to do it that doesn't allow Bitcasa to read the file (at least not one using well-researched encryption technologies). It seems like they are likely using your key as a key encryption key for the actual key to the file, but for that to work, they have to be able to tell you the real encryption key, which means they have access to the contents.

I'd love to be proven wrong, though, because we could use it. :)

We don't know how much space Dropbox saves by having the dedupe feature. For all we know it could be something as small as 5%, or even less.

I would pay DropBox premium for this feature.

You and about 5,000 other people. Not a big market, unfortunately.

It may not be a big market that the masses are clamoring for, but it will soon be similar to services encrypting passwords in the database. The outside world shouldn't be expected to know about the existence of rainbow tables and the futility of md5-hashes. The educated, however, know what to demand, will expect their services to offer it, and will leave lacking-services for support-services - and in their exodus the masses inevitably follow (e.g. Hotmail -> GMail)

> The educated, however, know what to demand, will expect their services to offer it, and will leave lacking-services for support-services - and in their exodus the masses inevitably follow (e.g. Hotmail -> GMail)

That's not how it works.

People didn't leave Hotmail because the "educated" left, they left it because Google gave several GBs for free, the interface was simpler, the search better and MS was out of fashion.

If you're not a large market you don't get a service, or you only get niche vendors to cater to you. You can bypass this by setting trends for the "uneducated" (whatever that means), else we will all be using Lisp Machines or Smalltalk environments.

Educated/uneducated may not be the right terms, but it is possible to have hindsight just by understanding the landscape.

Privacy is becoming a large problem in the internet and encryption will likely be part of the solution. Without encryption, the ownership of data is on the service provider instead of the person.

Privacy is a feature just like free storage. One day, privacy can be available to the masses just like storage is today. (also think back how many people actually wanted or needed multiple gb of free storage for their emails until one was provided by a service like gmail)

I think you are right. The only thing holding back cryptography from being widely adopted is the lack of a service that makes strong cryptography super easy to setup and use. I know this isn't a trivial task, but it's not impossible to implement strong crypto in a user-friendly way.

This is wrong. SOX compliant fortune 500 companies can't legally use dropbox due to confidentiality requirements. Adding encryption would fix the confidentiality issues.

The BIGGEST deepest pockets would pay handsomely for this.

FYI, SpiderOak has always supported zero knowledge encryption, and recently launched an enterprise product. https://www.computerworld.com/s/article/9226176/SpiderOak_la...

JungleDisk has too

How would you verify that they never got your encryption key? You installed their software on your computer. How can you be sure it never sent your key to their server?

The same way you can be sure that any of the hundreds or thousands of other programs installed on your computer are not keylogging and sending your passphrases and plans for world domination to the NSA, Bilderberg Group, and the Russian mob.

That is to say, you can't be sure. However, Dropbox is a company in good legal standing, and they have a lot to lose if they offered client side encryption and then leaked the passphrase.

Spideroak (definitely) and Backblaze (I think?) already have client software which offers client side encryption. Whether you trust them is up to you.

I would too. I would pay maybe $100+ a year for this, even for only 4GB or whatever I currently have on Dropbox. But maybe this still wouldn't be profitable to develop if only a small group of paranoid users would buy it.

10$ a month is not a lot of money. But, why not just use Dropbox on locally encrypted files?

Because then the web interface is worthless and you have to decrypt the files on every machine you sync with Dropbox

Check SpiderOak - sounds like exactly what you want. https://spideroak.com/

I'm launching a product shortly that offers exactly this feature to Dropbox (or Google Drive, SkyDrive, ...). It's a native OSX and Windows app that keeps the keys on the users' computer and transparently encrypts and decrypts files before they're sent to your cloud storage provider.

The product is in beta right now but I'd love some more people to try it out. If you sign up at http://safeboxapp.com, you'll get a download link to try it out.

Just signed up for it.

How does it compare to BoxCryptor where you can also access your files using EncFS?

Unlike BoxCryptor, it's not based on an encrypted volume. Instead, files and directories in a designated folder are individually encrypted (much like Dropbox).

Wow, I had the exact same idea around a month or two ago, but didn't have time to execute.

Please tell me you are sending out invites today.

Reply on news.ycombinator.com