Just to be sure of your requirement of this master password,
- 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