Sharing encryption key via intermediary without the intermediary having access to the content

amlwwalker

2/6/24, 6:26 PM

Please bear with me... I want to store some data in an untrusted location (a server). I will want to share this with other people. I encrypt the data with AES encryption and a 20 character password. Then, if I know the RSA public key of the people I want to share the data with, I encrypt the password with their public key and upload those to the server also for them to retrieve and access the data at a later date. This much I have and is reasonably straight forward for me to implement.

My question comes when I do not know the public keys of recipients and I don't want to have to manually handle the encryption of the password to share with them each and every time.

One option is I allow the server to know the password and encrypt it for new recipients as and when, however I do not want the server knowing the password either.

I realise as writing this I might be asking for 'magic', however is there any encryption mechanism in which the server can encrypt the password for the recipient, without actually ever seeing the password in plaintext. I.e can it encrypt for a new recipient based off of an already encrypted version of the password (for say another recipient). I'm wondering if I can do something like (and it won't be this but...) encrypt the ciphertext with the new key and XOR the ciphertext with the previous key it was encrypted with, in effect "swapping" the keys.

Or perhaps a homomorphic encryption mechanism could be used, where by the server can "do stuff" to the data all while not knowing what the data actually is. I am wondering if HE could be used to then allow a server to manage who can decrypt the data, but not be able to see the data itself....

0 + 9

aes

homomorphic-encryption

Amit

2/7/24, 3:14 PM

The following line of thought may help you: given that you don't know the public keys of the parties you want to entrust with the information, what other information do you have about them? For example, how do they access the server? I am assuming they already have some kind of credentials to do that. Then, perhaps you can derive from those credentials, and possibly in combination with additional info, the keys you need to encrypt the other necessary keys / passwords which are required to decrypt the information. (It is also a matter of creating the best "key hierarchy" for the case at hand).

Eugene Styer

2/7/24, 10:07 PM

Would it be acceptable for the server to know everyone's public key?

amlwwalker

2/8/24, 12:28 PM

I think so yes @EugeneStyer - although their accounts may be created after the initial password is created/uploaded/stored. So the encryption for them could/would happen at a later date. Amit - I would be happy to use any mechanism to safely pass them the information, whether thats a public key or some other mechanism, what i'm struggling with is how to give it to them given i dont trust the server with the plaintext...

amlwwalker

2/9/24, 1:28 PM

@Amit apologies, I can know the public keys, i just may not know the public keys when i first encrypt the secret. So when I have an encrypted version of the secret on the server, that the server can't read, but I want it to be able to share with "future" public keys im wondering about if there is any mechanism that can offer such a thing. Hence why i thought there may be something in the homomorphic encryption world as it allows the server to act on encrypted data while not knowing the plaintext

Amit

2/9/24, 1:36 PM

@amlwwalker This problem is usually solved by creating an authorization layer, e.g. the user doesn't connect directly to the server but via a client. The client only sees the parts of data he is authorized to see, hence has access to the encryption keys he is authorized to use. It seems to me your difficulty stems from all users always having a kind of "root" access to the server

amlwwalker

2/9/24, 1:39 PM

@Amit so the server is merely a relay server. I encrypt and upload a message to the server and then at a later date, i want to specify users who can read that message. The server then handles sharing the message with those users who have yet, but will, share their public keys. They can then decrypt offline. I now don't want to be involved in the process of getting them the message and leave that to the relay server which gives the users the ability to read the message, all the while, the server never can read the message.

Amit

2/9/24, 1:47 PM

@amlwwalker Yes well, if you can't entrust the server with the data keys he won't be able to encrypt them under the user's public keys of course, once these become known. So something akin to homomorphic encryption seems the only way - I don't have enough knowledge about that subject.

Amit

2/9/24, 3:46 PM

... You need to note however that if the server can perform the magic of re-encrypting the data under a new key without decrypting it, it will also by definition be able to re-encrypt it with its own invented key :) You see homomorphic encryption talks about manipulating encrypted data, but re-encryption, while also being a manipulation, is not reasonable to require because ability to re-encrypt will always translate to an ability to decrypt. I would suggest you to reconsider the entire design, starting with challenging the assumption that you can't trust the server.

Amit

2/9/24, 3:53 PM

For example perhaps you can separate the data from the data keys: One server will have access only to the data keys, and can re-encrypt them whenever it needs to, but it won't have the encrypted data. A separate server will only contain the encrypted data, without access to the keys it can't decrypt it. So now the two servers need to collude in order to decrypt the data. (In effect it is similar to separating the authorization layer and the data storage to separate servers that hopefully can't see each other).

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Sharing encryption key via intermediary without the intermediary having access to the content

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.