4 ms·
I see a few problems here, or perhaps I didn't get it at all: 1. What happens with data shared among a dynamic group of users? A temporary password could be sa
by nudpiedo 11y ago
I see a few problems here, or perhaps I didn't get it at all:
1. What happens with data shared among a dynamic group of users? A temporary password could be saved and then re-encrypted for each one of them?
2. If a suer changes its password or certificate, all its records of the databse should be updated? In a cloud service or backup that could be expensive (unless a all the information and password travels back to the user and it is reencrypted)
3. In case an attacker breaks into the remote system or database: game over. He installs custom code there and waits that the user logs in again. Or exploits the client doing a personalized MITM for the DB.
- michwill 11y ago1. 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 :-)