What's disappointing about SpiderOak is the inability to do two-way sharing of your data - so it's not really usable in a corporate setting.
Oh, you're saying it wouldn't be possible with client-side encryption? I say it should be, using a mix of symmetric and asymmetric encryption:
- have all data of a repository encrypted using a symmetric key, at first known only by the repository owner.
- the symmetric key gets sent on the cloud host's server, encrypted using the owner's public key.
- every new device or share with a new user will require a previous user (in this case the owner) to decrypt the symmetric key using his private key and encrypt it using a new public key that the new user / device has sent together with its access request.
- the cloud host simply grows a table of encrypted symmetric keys, with one entry per device/user, besides the actual encrypted data. note that the cloud host still can never decrypt the data, as long as the private keys never get sent around.
It's coming! Existing SpiderOak accounts all contain a 3072 bit RSA keypair, which is reserved for this future purpose. But it's not as simple as it seems. Things like garbage collection, and space accounting, and various race conditions between parties become the hard parts.
In any case, it's on the way, and it's entirely open, built with Crypton.io, our new open source framework for building zero knowledge applications. (Which we'll eventually port the main SpiderOak desktop app to use.) For details https://crypton.io/ and https://www.youtube.com/watch?v=pn9DAwggza0 (...and to be clear, the threat model is intended for for HTML5 desktop and mobile apps, not browser Javascript.)
Oh, you're saying it wouldn't be possible with client-side encryption? I say it should be, using a mix of symmetric and asymmetric encryption:
- have all data of a repository encrypted using a symmetric key, at first known only by the repository owner.
- the symmetric key gets sent on the cloud host's server, encrypted using the owner's public key.
- every new device or share with a new user will require a previous user (in this case the owner) to decrypt the symmetric key using his private key and encrypt it using a new public key that the new user / device has sent together with its access request.
- the cloud host simply grows a table of encrypted symmetric keys, with one entry per device/user, besides the actual encrypted data. note that the cloud host still can never decrypt the data, as long as the private keys never get sent around.