Encrypt, encrypt, encrypt. If possible, use ecryptfs or TrueCrypt or some other non-transparent encryption mechanism on files that you back up to remote sites so that you know they are always safely encrypted and don't have to think about it (just copy the lower-level, encrypted container). Both ecryptfs (with filename encryption) and TrueCrypt can back up encrypted versions of your files without even giving away filenames, so RIAA can't go acking for MP3s. Of course, manually using gpg and specifying an unrelated output filename works too.
If you're uploading anything remotely important to a third-party service, you should encrypt all of it beforehand. As we see time and time again, it can be really surprising how easy it is for an insider, a random script kiddie, or in this case, a company with a posse of anxious lawyers to grab your data. You need to encrypt that data before it ever leaves your disk for persistent storage on someone else's infrastructure. Encrypt encrypt encrypt.
100% agree. Encrypt. Not because of what you are afraid today, but for what might happen in the future. You can't even begin to imagine the ways our privacy will be violated tomorrow.
All file locker services should offer a check-box or something by default, before you upload your files, to encrypt them with your own key. That should cover a lot more people than it would if everyone had to do everything by themselves.
They save a lot of costs by deduplicating copies of files, and it makes file renames/moves/shares really easy for them. Therefore, they wouldn't have the incentive to destroy that advantage: That's one of the major scale advantages they get for covering so many users.
With that said, they could offer that "by default" to premium users who already pay for the service to simplify their lives and keep their more profitable customers happy.
What are everyone's views on that, from Dropbox's perspective?
They save a lot of costs by deduplicating copies of files, and it makes file renames/moves/shares really easy for them. Therefore, they wouldn't have the incentive to destroy that advantage: That's one of the major scale advantages they get for covering so many users.
I posted this elsewhere in the thread:
That's not true. As is, in a lot of crypto problems, there are powerful workarounds that require a lot of work. See here for one idea: http://news.ycombinator.com/item?id=2461713
Please also see the further discussions. Crypto gives us powerful tools to mitigate several attacks with minimal compromise on functionality. Unfortunately there are legal ways that are more powerful.
This is why I've left some sort of server-side encryption out of the storage product I'm designing. I mean, I'm just using webdav, so it should be easy enough for you to bring your own client with encryption support; something you already trust.
The main benefit of encryption in these situations is that you have to trust your provider a whole lot less... If I get compromised through a OS hole? if you are encrypted, you are covered. If I get compromised through a physical attack, governmental or otherwise? if you are encrypted, you are covered.
If I do the encryption for you, I give away a bunch of those benefits. If I'm completely compromised, you should assume that any keys I have access to are also compromised.
I think giving up "deduplication" is completely reasonable in this regard; the competitive landscape right now is that "cloud backup" costs about 10x what I think it ought to cost for backups (In part due to the fact that many 'cloud backup' services are built to be fast enough to serve webpages; If you let me have 'backup system' level performance, I can do it a whole lot cheaper, but also in part due to the fact that s3 sets the price here, and S3 is still charging "pretty good for 2007" prices.)
I think the suggestion was that a client integrate encryption functionality locally, generating and using a key that exists only on a user's computer (or, alternatively, is backed up with AES (or similar) using a passphrase the service doesn't know). You don't have to have access to the key.
A really cool application would be one that allowed you to contact your home computer from the web and use that to decrypt stuff transparently on its way to your final destination, then you could still offer web-accessible decrypted files any time the user's main computer was powered on.
>I think the suggestion was that a client integrate encryption functionality locally, generating and using a key that exists only on a user's computer (or, alternatively, is backed up with AES (or similar) using a passphrase the service doesn't know). You don't have to have access to the key.
yeah. That's also what I am suggesting. but you don't need the provider's help to do that. it's easy enough to encrypt a davfs mount locally on your own box; the provider just needs to support some standard (like webdav.) Then it's up to the user to figure out what client they trust to encrypt the data before it's uploaded.
My point is that if the providers control the encryption (e.g. by providing a proprietary client that has access to the key) you have a lot less protection than if you do the encryption independent of your provider.
Comments
Encrypt, encrypt, encrypt. If possible, use ecryptfs or TrueCrypt or some other non-transparent encryption mechanism on files that you back up to remote sites so that you know they are always safely encrypted and don't have to think about it (just copy the lower-level, encrypted container). Both ecryptfs (with filename encryption) and TrueCrypt can back up encrypted versions of your files without even giving away filenames, so RIAA can't go acking for MP3s. Of course, manually using gpg and specifying an unrelated output filename works too.
If you're uploading anything remotely important to a third-party service, you should encrypt all of it beforehand. As we see time and time again, it can be really surprising how easy it is for an insider, a random script kiddie, or in this case, a company with a posse of anxious lawyers to grab your data. You need to encrypt that data before it ever leaves your disk for persistent storage on someone else's infrastructure. Encrypt encrypt encrypt.
100% agree. Encrypt. Not because of what you are afraid today, but for what might happen in the future. You can't even begin to imagine the ways our privacy will be violated tomorrow.
All file locker services should offer a check-box or something by default, before you upload your files, to encrypt them with your own key. That should cover a lot more people than it would if everyone had to do everything by themselves.
Let's take Dropbox for example.
They save a lot of costs by deduplicating copies of files, and it makes file renames/moves/shares really easy for them. Therefore, they wouldn't have the incentive to destroy that advantage: That's one of the major scale advantages they get for covering so many users.
With that said, they could offer that "by default" to premium users who already pay for the service to simplify their lives and keep their more profitable customers happy.
What are everyone's views on that, from Dropbox's perspective?
They save a lot of costs by deduplicating copies of files, and it makes file renames/moves/shares really easy for them. Therefore, they wouldn't have the incentive to destroy that advantage: That's one of the major scale advantages they get for covering so many users.
I posted this elsewhere in the thread: That's not true. As is, in a lot of crypto problems, there are powerful workarounds that require a lot of work. See here for one idea: http://news.ycombinator.com/item?id=2461713
Please also see the further discussions. Crypto gives us powerful tools to mitigate several attacks with minimal compromise on functionality. Unfortunately there are legal ways that are more powerful.
That idea doesn't work. It doesn't stop a third-party from seeing who has copies of a file.
Call me paranoid but I would not even consider that as an alternative to doing the encryption on my own.
This is why I've left some sort of server-side encryption out of the storage product I'm designing. I mean, I'm just using webdav, so it should be easy enough for you to bring your own client with encryption support; something you already trust.
The main benefit of encryption in these situations is that you have to trust your provider a whole lot less... If I get compromised through a OS hole? if you are encrypted, you are covered. If I get compromised through a physical attack, governmental or otherwise? if you are encrypted, you are covered.
If I do the encryption for you, I give away a bunch of those benefits. If I'm completely compromised, you should assume that any keys I have access to are also compromised.
I think giving up "deduplication" is completely reasonable in this regard; the competitive landscape right now is that "cloud backup" costs about 10x what I think it ought to cost for backups (In part due to the fact that many 'cloud backup' services are built to be fast enough to serve webpages; If you let me have 'backup system' level performance, I can do it a whole lot cheaper, but also in part due to the fact that s3 sets the price here, and S3 is still charging "pretty good for 2007" prices.)
I think the suggestion was that a client integrate encryption functionality locally, generating and using a key that exists only on a user's computer (or, alternatively, is backed up with AES (or similar) using a passphrase the service doesn't know). You don't have to have access to the key.
A really cool application would be one that allowed you to contact your home computer from the web and use that to decrypt stuff transparently on its way to your final destination, then you could still offer web-accessible decrypted files any time the user's main computer was powered on.
>I think the suggestion was that a client integrate encryption functionality locally, generating and using a key that exists only on a user's computer (or, alternatively, is backed up with AES (or similar) using a passphrase the service doesn't know). You don't have to have access to the key.
yeah. That's also what I am suggesting. but you don't need the provider's help to do that. it's easy enough to encrypt a davfs mount locally on your own box; the provider just needs to support some standard (like webdav.) Then it's up to the user to figure out what client they trust to encrypt the data before it's uploaded.
My point is that if the providers control the encryption (e.g. by providing a proprietary client that has access to the key) you have a lot less protection than if you do the encryption independent of your provider.
This should not be a checkbox, but it should be the default. And that's exactly what Wuala is doing.
Wake me up when Wuala open sources their client.
For just doing security reviews, I don't think open source should be a requirement; just available, published source.