I'm trying to create application-layer encryption for user data in my database, using password derivation function. But there is a problem, that there must be an admin user, who can access all user's encryption keys, for password reset functionality and some other things. I don't like the fact that all encryption system security can be broken with just one admin password. I've asked for an advice here How can I improve the application administrator's encryption keys security inside database

I was advised to compile an admin encryption key not from a password but from another source (admin computer system information, for example), so it can't be brute-forced, and then pass it to the database server.

It is a good approach, however, this complicates admin mobility and system recovery in an event of key loss, and these requirements are mandatory to accomplish.

So, I come up with this idea:

  1. Give my admin PKI certificate (RSA 2048 bit for example)
  2. Get some static string ("password" for example)
  3. Make a digital sign out of this static string using the certificate's private key
  4. Send this digital signature to the database server, and use it there as an encryption key.

At first glance, I don't see any great flaws with this approach, but I couldn't find that someone has done anything similar before, so I want to ask you to help me to validate my vision.

  • I'm not sure how you will use digital signature for encryption key but with digital signature comes another problem, security of private key which is used for signing the string.
    – saurabh
    Oct 13, 2021 at 8:11
  • @saurabh The digital signature itself is a bunch of bytes, padded to constant length, so I don't see any problem with using it as an encryption key. In our case ensuring the security of the private key is much easier because we can delegate this to the admin operation system Keystore/hardware token etc. But I still fear that I might not have foreseen some big issues with this approach, because I can't find anything approving my point of view over the internet. Oct 13, 2021 at 13:18
  • So, what is your plan? Superuser logs in, creates digital signature every time for recovery? If this is the case, why not just use the concept of DEK and KEK. Generate encryption key(DEK) and encrypt the user RSA key with it. Generate KEK which will encrypt the encryption key(DEK) and store KEK in key store or hardware token. Each time when superuser need to recover the account, use KEK to decrypt the encryption key(DEK) and provide to database for recovery.
    – saurabh
    Oct 14, 2021 at 12:27
  • My initial plan was to perform encryption/decryption on the application server, and in this case, I had to derive KEK on that application server somehow. I've read a couple of articles since posting this question, and now I tend to think that this is not the right approach, and I must seek the right encryption scheme in the field of end-to-end encryption. this way, I think I can achieve two things: 1) even with physical app server compromise it will never hold decrypted user data; 2) We can use hardware tokens for encrypt/decrypt operations in the client app. Oct 14, 2021 at 16:53
  • And with using digital signatures as keys, I completely foresaw the fact, that it will not be the same each time I will try to sign the same text Oct 14, 2021 at 16:55


You must log in to answer this question.

Browse other questions tagged .