I have been thinking for days about that problem! The application is based on a student system management. I am implementing database encryption on a column level and The encryption occurs at the application level.

The administrator sets the columns that are to be encrypted in a win app I will make. Aes encryption is used to encrypt the columns. In the win app, I use RSA public key to encrypt the aes key, and store the encrypted key in the database. I then store the private key in a flash drive. The authorized user will use the private key file to decrypt the aes key and hence decrypt the columns.

My problem is this:

  1. Suppose I have more than one user who needs access to these sensitive columns, then my plan does not seem very productive because how can I store the private key to many flash drives at the same time, say 10 flash drives??

  2. Also, if i decide to add a user to access the columns, how to give him the private key? Or if I remove one user, thrn I should change the private key of all the rest of users.....

Please help! I have been thinking about that for days!

  • We're not here to do your homework.
    – ruief
    Commented Feb 24, 2013 at 20:47
  • 1
    @ruief I am asking for some advice and tips. I am not asking you to actually write the code for me. THAT would be to ask you to do my homework for me.
    – orange
    Commented Feb 24, 2013 at 23:52
  • And I already did a good part of research by reading on AES and finding out how to encrypt my keys etc.
    – orange
    Commented Feb 24, 2013 at 23:54

1 Answer 1


For the specific situation you are alluding to, using a symmetric key and RSA keys is the right path. Namely:

  • Data is encrypted with symmetric key K (with AES or some other algorithm which does the job).
  • Every user who should have access to the data has a RSA key pair. Each user has his own key pair, distinct from that of any other user. Let's call Pu the public key of user u (and Su the corresponding private key).
  • K is asymmetrically encrypted (RSA) with the public key of each user. This means that the database contains several values EPu(K) (encryption of K with the public key of user u).
  • When a user wants to access the data, he uses his own private key Su (from his flash drive) to decrypt his value: DSu(EPu(K)) = K. With K, the user can access the encrypted data.
  • When you want to add a new user v, you generate the new key pair for that user (Pv, Sv) with the private key stored on a new flash drive which you give to the user. You also encrypt K with Pv and add the new EPv(K) to the list of such values in the database.

Removing a user is tricky, because of a general fact: you cannot enforce forgetfulness. Any user who had access to the data at some point could have grabbed a copy of the whole (decrypted) data and still remember it. The best you can do is to make sure that the removed user will not have access to the new data added after the eviction of that user. There are thus two methods to revoke user u data access:

  • The fast but incomplete method is to simply remove EPu(K) from the list of stored values. This will be sufficient to deny subsequent access from user u if that user is honest and did not keep a backup of EPu(K) (or, simply, a backup of K).

  • The thorough method is to generate a new master key K', decrypt all the data, reencrypt it with K', and encrypt K' with the public keys of all users except u. The database will then contain EPv(K') for all users v except u. This effectively locks out user u from any new data element.

The system described above can accommodate smart cards in lieu of "flash drives". There is not need for any entity other than user u to actually access the private key of user u.

Note: all of the above is about controlling read access to the data. Controlling write access, detecting alterations, duplications or suppressions is another matter.

  • Thanks for the comment! I had thought of a key pair for each user but then I cant figure out how to store in the DB. I store the table name, column name to be encrypted and corresponding encrypted aes key in a table. Now, say The admin decides to encrypt a column and in the app, he will create the aes key, encrypt it with the user public key, store information in the db etc. The Aes key encrypts the data in the database and that encrypted data is stored bk. NOW, when another user is made to access the SAME column, the win app will be creating another AES key Again. Can u see the prob
    – orange
    Commented Feb 24, 2013 at 16:35
  • Tom's suggestion is that a new AES key isn't created in that situation. When granting another user access to the column, the admin decrypts his copy of K, re-encrypts it with the new user's public key, and stores that (with an identifier of the new user) in the database alongside the admin's encrypted copy of K. There is only one symmetric key, which is itself encrypted once for each authorised user.
    – Michael
    Commented Feb 25, 2013 at 21:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .