Sign up ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I want to manage authorization, as 3rd-party permissions, through asymmetric cryptography.

I'm concerned about how it is possible to share access of encrypted data with N entities, be able to revoke any of them at anytime, and do this securely.

I've thought about a cryptography function that I'm asking here some help to build.

Let's imagine I have a public data base encrypted with my public Key.

I want:

  • to share some data from my encrypted DB(my email address for example) to 3 different entities (applications)
  • these 3 applications and only these to be able to read the data
  • to be able as a user to revoke their access to this data at any time.

I have a private/public key and these applications' owners too have a private/public key on the network.

I use a function to encrypt my email with my public key as:


At this point, only I with my private Key can read the data.

If I give access to a 3rd-party application to it, then I would re-encrypt my email with a new function, using my public key and the application's, so both my private key and the application private key are solution and can decrypt the data:

Encrypt(Email(MyPublicKey, AppPublicKey))

So, now, only me and the application could read the data with our private key because each of our private keys would be a solution of this encryption algorithm.

If I add a 2nd application access to this data, I would then re-encrypt the data through a new function:

Encrypt(Email(MyPublicKey, AppPublicKey, 2ndAppPublicKey)) 

Now the 2nd application has the same access as me and the first application to this data.

Then if I want to revoke the 1st application's access, I would re-encrypt the data excluding the 1st application private key as solution of the function as:

Encrypt(Email(MyPublicKey, 2ndAppPublicKey)) 

So, the 1st application cannot access to the data anymore as its private Key is not solution anymore of the encryption function.

Is it a known cryptographic scheme (like custom shared secret)? Does such mathematical function exist? What it would look like? Maybe there is a simpler solution I didn't see...

share|improve this question
If someone once had access to the data he could simply store the data and there is nothing you can do if the data stays the same after revocation. But if the data changes, you may prevent future access to the new version of the data. You may look into lazy revocation and key rotation, e.g., here. – DrLecter Aug 30 '14 at 21:42
Yes of course the application can store it, as long as you have decided as user to let the application access it there is no problem (Like todays connect with Facebook or Connect with Google for instance). and Yes I want to prevent future access to data and updates of it like today we do with OAuth protocol on the web but for encrypted data. Thanks for the link. I will check it out. – Janus Aug 30 '14 at 22:49

1 Answer 1

This is simple to do by combining symmetric and asymmetric encryption.

For example:

  1. Generate data encryption key $s$.
  2. Encrypt the data $d$ using symmetric algorithm $A$: $A_s(d)$.
  3. Encrypt the symmetric key with the relevant parties public keys: $E_i(s)$.

The key can be per data field, or shared by various fields with equivalent permission requirements. When authorized requests access to the data, they would receive the encrypted symmetric key, be able to decrypt it and thus the data itself.

When you revoke access you have two options:

  1. Only delete the encrypted symmetric key corresponding to that party.
  2. Re-encrypt everything under a new symmetric key.

In the latter case you also prevent someone who has looked at the data earlier (and saved the symmetric key) from being able to decrypt the current version later. However, it can require more computation if the data is large.

As a compromise you could mark the data for re-encryption when next modified, under the assumption that since they had access they could already know the current value and must only be prevented from knowing future values.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.