1. Yes, this is a fair problem. Currently common solution is this. You encrypt data with, say, AES, and AES content keys with your public key. Whenever you want

1. Yes, this is a fair problem. Currently common solution is this. You encrypt data with, say, AES, and AES content keys with your public key. Whenever you want to share, you (not cloud) re-encrypt all the content keys for all people you want to share with. This can be pretty computationally expensive. The way to solve this, mentioned in the article - proxy re-encryption. There are such algorithms which allow the cloud to re-encrypt data on your behalf, without knowing your keys. Compromised cloud would have only choice of executing or not executing re-encryption. 2. Same as (1). You either re-encrypt all the content keys on the client side, which could be an expensive process. Or you use proxy re-encryption to let the server re-encrypt data for your new key. 3. That I don't understand. Ok, attacker breaks into remote database. What can he do? When user logs in, he[user] doesn't ever say decryption key to the server. That was the whole point of this article :-)