public key cryptography implementation

Question

I have been using the PHP mcrypt module for encrypting sensitive data at my company. This has been working well. However, I have been requested to create a new master password which should be able to decrypt any data. The problem is that this master password would have to be hardcoded in a script file. Please correct me if I am wrong but the only secure way seems to be to hardcode a public key in the script and use it to encrypt data while keep the private key secure and use it to decrypt only when needed.

mcrypt does not seem to have an implementation for such a scheme. Does anybody know of a library (PHP module or pure PHP) which would do this?

Answer 1

I suggest taking a look at the PHP OpenSSL bindings, and in particular the openssl_public_encrypt() function. You could indeed embed a master public key into the script, and have the script encrypt each user's AES key with this public key. Keep the corresponding master private key in the company safe.

Should you need the master decrypt function, you would pull the encrypted user key, decrypt it with the master private key and then decrypt the original data.

Answer 2

There's a PECL extension for that. http://us2.php.net/manual/en/book.gnupg.php

You can also use gnupg command line tool from php, if it doesn't have to be very fast: http://devzone.zend.com/article/1265

I haven't tried either method.

Answer 3

I don't see how that would work. Any two-way encryption function is only going to decrypt when fed the specific password used to encrypt (unless you're the NSA and you put back doors in the algorithms). You can't have two passwords decrypt the same file (unless there are hash collisions, but that's not something you can make happen easily).

As far as storing your master password in the program, it would be much better to store it in a separate file the program reads in, so you can use tighter OS-level security on that file.

Keep in mind mcrypt is not public key cryptography. With public key cryptography, you might be able to do what you want, though. For instance, with PGP/GPG, you can encrypt a file such that three different users can decrypt it using their private keys, without knowing each other's private keys. So you can have a virtual user with the master password that can decrypt everything.

Another option would be to hold two copies of all encrypted data; one encrypted with the user's password, and one encrypted with the master password.

Answer 4

Just to be sure of your requirement of this master password,

1. Is it expected to be used only as a 'encrypt this' command that will 'seal' something
   which can then only be opened by someone knowing the private key in question? Or,
   • Is it something you expect to open any encryption done in the enterprise?
   • I just want to be sure your phrasing is not to be interpreted in this second way
   • your phrase 'decrypt any data' sounds dangerous
     (and not-feasible/practical with asymmetric key encryption)

---

Update based on the comment.

• You are planning for two copies of the data each encrypted with different keys
  • one copy is to be encrypted with the master public key
    • can be decrypted with anyone having the master private key
      the master private key must then be secured (public key is not critical)
  • the second copy is to be encrypted with the Rijndael 256 key
• purpose is to allow the master to decrypt the data whenever required
  particularly, in the absence of the individual who encrypted it

This approach will work for, easy access of the data by the individual with the Rijndael key,
without need for intervention by the master private key owner.
And, when the master private key owner is trusted with the secrecy of the data.

Your scheme will need to update the master copy (deleting the older one and re-encrypting a new one) every time the user updates their copy.

---

However, if the user data is trusted with the master (as is clearly the case here),

• an easier approach would be to issue the Rijndael key from the master
• The master could keep it encrypted with the master-public key itself
• The data can then be encrypted with just the issued Rijndael key
  • it will always be accessible with the master-private key
    which can open the user's Rijndael key

If the user needs to sign the data, that can be accomplished separately in the process.
It will save you from keeping double copies and maintaining them.

---

To sign the data, the user could have a a key pair generated by them.

• Before encrypting the data with the Rijndael private-key
• the master-public key encrypted with the user-private-key can be appended to it
• the user-public key shared with the master (at least)
  will be sufficient to authenticate that the user has provided the data
• In a worst-case scenario, if the user is unavailable and the key confirmation fails,
  the master may be trusted on the authenticity of the data -- which can still be decrypted