Bruce, Joe, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 09:55:10AM -0700, Joe Conway wrote: > > > That way, if the user wants to store the key in an unencrypted text > > > file, they can set the encryption_key_command = 'cat /not/very/secure' > > > and call it a day. If they want to prompt the user on the console or > > > request the key from an HSM or get it in any other way, they just have > > > to write the appropriate shell script. We just provide mechanism, not > > > policy, and the user can adopt any policy they like, from an extremely > > > insecure policy to one suitable for Fort Knox. > > > > Agreed, but as Bruce alluded to, we want this to be a master key, which > > is in turn used to encrypt the actual key, or keys, that are used to > > encrypt the data. The actual data encryption keys could be very long > > randomly generated binary, and there could be more than one of them > > (e.g. one per tablespace) in a file which is encrypted with the master > > key. This is more secure and allows, for example the master key to be > > changed without having to decrypt/re-encrypt the entire database. > > Yes, thank you. Also, you can make multiple RSA-encrypted copies of the > symetric key, one for each role you want to view the data. And good > point on the ability to change the RSA key/password without having to > reencrypt the data.
There's nothing in this proposal that prevents the user from using a very long randomly generated binary key. We aren't talking about prompting the user for a password unless that's what they decide the shell script should do, unless the user decides to do that and if they do then that's their choice. Let us, please, stop stressing over the right way to do key management as part of this discussion about providing encryption. The two are different things and we do not need to solve both at once. Further, yes, we will definitely want to get to a point where we can encrypt subsets of the system in different ways, but that doesn't have to be done in the first implementation either. Thanks! Stephen
signature.asc
Description: Digital signature
