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
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.