Hacker News Reader

Comment by shin_lao | Hacker News Reader

I might have misunderstood what you meant, but #1 is invalid.

If I can look at my data any time I want, I just need the key to it. Dropbox just gives me access to the encrypted stream.

Giving access to my data to someone else would therefore just be a question of sharing the key with that person, again, without Dropbox ever having access to this key.

Your killer argument is to me #3. If you don't trust a company, don't do business with it. It all comes down to this.

View on HN

One of the reasons Dropbox is successful is because anyone can use it. Even your mother. In fact, one of the reasons Drew was originally accepted into the YC program was because his sister was using it when he applied.

"If I can look at my data any time I want, I just need the key to it. Dropbox just gives me access to the encrypted stream."

In order for the data to be encrypted securely, you would need to generate a key on your own computer which Dropbox then uses to perform the encryption. (Tarsnap works this way.)

Forcing Drew's sister (or your mother) to generate a key would be bad for accessibility.

The authentication token can be generated and managed by the software. It would then be protected by the account password, if any (Windows and MacOS X offer this feature).

Doable, and even better, you can make that a 30 € / month corporate option. ;)

If the key file is stored on Dropbox servers, then Dropbox has access to all of your files. This defeats the original purpose (security).

If the key file is not stored on Dropbox servers, then you can't easily use Dropbox across several different computers. This defeats the other purpose (accessibility).

You can store a key escrow on the dropbox server protected by a password or a token. Just a matter of designing something secure and useable. Not easy, but possible.

When you forget your password you'll lose access to all of your data. Password recovery won't be possible if the key is password protected.

I believe most tech users understand that and accept the compromise when they are using an 'encrypted' system

But Dropbox isn't aimed at tech users.

That doesn't work, Dropbox/your favourite TLA will just wait for you to supply the password and then save the key. Trading off the inconveniences of good crypto (e.g. no web interface) for that little security isn't worth it.

The system suggested by shin_lao does not require that the password be passed back to Dropbox to retrieve the key.

If Dropbox wants to serve the files to a standard browser, it does need the decryption key. If I misunderstood and shin_loa wants to drop the web interface, why "key escrow" - why not directly derive the key from the passphrase?

Isn't one of the major cool things about dropbox that if your computer hard drive gets smashed (and thus the key is destroyed), you can still access your files somewhere else?

That's why you should always keep backups of your key somewhere. Even on paper in a safe deposit box.

We are talking here about Dropbox being simple to use for everyone and you start talking about keeping backups of keys. In safe deposit boxes, no less. Wow.

You don't need to worry about safe deposit boxes. Just don't be upset when you get a letter in the email from a law firm that's noticed some of the music in your dropbox has the same hashes as the music in someone else's dropbox.

The cloud is a scary place. Making it easy to use is not necessarily a good thing.

De-duplication is not really the topic of this discussion, is it?

Funny, when I visit my mom I use her computer for emergency bug fixes and I have my Dropbox installed on her computer. Every now and then I'll see a notification about a document being added to my DB so I checked and it turns out she's saving her documents there cause she "likes the name of the folder".

So yeah, mom's can definitely use it.

Tarsnap provides exactly the sort of service you're referring to, where they only store encrypted data and don't have a copy of the key.

I'm a big fan of that architecture, if only because it greatly reduces the payoff of a successful attack. When everything is stored unencrypted (or with a common master key), there's an absolutely massive payoff for the hacker who breaches the security.

Tarsnap is great and its author knows what he's doing but dropbox is many UA ahead in terms of useability and platform interoperability.

Dropbox is incredibly easy to use, that's where its power comes from. It's "secure enough" for casual use.

Additionally I believe you can't share data between users with tarsnap.

There is a market opportunity for a corporate-level secure data exchange infrastructure.

Tahoe-LAFS provides a storage service that is encrypted by the client, but the original uploader of the data is still able to delegate read-only or read-write access to others on a per-file or per-directory basis.

The overall design, including how it is possible to do secure delegation, is fairly well described in a paper from the 'Storage Security and Survivability 2008' workshop - http://tahoe-lafs.org/~zooko/lafs.pdf

> dropbox is many UA ahead in terms of useability and platform interoperability

That's besides the point. Tarsnap is more than useable enough for its target audience, which is why cperciva (rightfully) doesn't give a rat's ass about making it as user-friendly as Dropbox and its ilk.

The two issues are completely separate. Implementation of client-side encryption and user-friendliness are not mutually exclusive. Tarsnap is simply proof that client-side encryption is entirely within the realm of possibility for cloud-based data storage services.

Dropbox+ecryptfs is pretty usable, too.

Have fun decrypting AES in Javascript, and downloading the file through your browser. (edit: on your cell phone...)

Hint: downloading client-side generated files is not possible without assistance from Flash.

Downloading client-side generated files is possible using data-uri. However these are usually small; it would be very difficult to store a 1GB file in memory (in javascript) while you decrypted it and I doubt data-uris that large work across different browsers.

True, but there's no way to specify the filename and extension, so in practice you have to use Flash.

It depends on the browser. Safari 5 works, but Chrome doesn't, not sure about Firefox, and I suspect IE doesn't.

I use it on my torrent-conversion bookmarklet on http://hid.im.

Not quite true: http://jszip.stuartk.co.uk/

My Cellphone is as powerful as a 2002 state-of-the-art desktop machine. There are problems here, but this is not it.

Oh?

Resuming downloads, large downloads (can't decrypt and stream to the disk as it comes in), and handling any future changes to the encryption algorithm (say, asymmetric instead of symmetric)? How about that, as it's in JS / attached to the DOM, an injected script has access to it? Or the several gigabytes of memory it would take to store and decrypt a gigabyte download? It'd also likely end up being an even bigger battery drain than Flash.

It's a definite problem. It won't be for long, I think, but it most certainly is now.

Network latency and bandwidth is the new MHz.

Actually, I think that may have been the one after MHz. Now we're into how many cores something has.

Reply on news.ycombinator.com