On Thu, Jul 25, 2019 at 08:07:28PM -0400, Stephen Frost wrote: > > Yes, we need to see how we are going to do that for checksums and > > encryption and come up with a plan. > > This is already being done though- Andres has a patch posted already and > my recollection from a quick look at that is that it should work just > fine for enabling checksums as well as potentially moving a table to be > encrypted online- the main common bit being that we need a way to say > "OK, everything has been done but we need to flip this flag and make > sure that everyone knows that this is now all checksum'd or all > encrypted". The only thing there that I'm not sure about is that when > it comes to checksums, I believe the idea is that it's cluster-wide, > while with encryption that would only be true if we were trying to do > something like move the entire cluster from unencrypted to encrypted in > an online fashion (including WAL, CLOG, et al...) and if that's the case > then there's a bunch of other complicated bits, I believe, that we'd > have to work out, and I don't really think it's necessary or sensible to > worry about that right now. Those are problems we don't currently have > with checksums either- the WAL already has them and I don't think > anyone's trying to address the fact that other rather core pieces of > the system don't currently.
OK, > > > > > There seems to be a strong thrust on this thread to assume that a > > > > > database MUST go from ALL DECRYPTED to ALL ENCRYPTED in one shot (and > > > > > therefore we have to shut down the server to do it), but I don't get > > > > > why > > > > > that's the case, particularly if we support any kind of mixed setup > > > > > where there's some data that's encrypted and some that isn't, and > > > > > since > > > > > we're talking about using different keys for different things, it > > > > > seems > > > > > to me that we almost certainly should be able to easily say "well, > > > > > there's no key for this, so just don't go through the decrypt/encrypt > > > > > routines". > > > > > > > > No, we can't easily do different keys for different things since all the > > > > keys have to be online for crash recovery, so there isn't much value to > > > > having different keys since they always have to be online. > > > > > > Wasn't this already discussed? We should have a master key and then > > > additional keys for different tables, et al, which are encrypted with > > > the master key. Joe, I believe, covered all this quite well. > > > > Yes, I am disagreeing with that. I posted a 5-option email that went > > over the issue and explored the value in different keys. I am still > > unclear of the benefit since it doesn't fix the 68GB limit unless we do > > it per 1GB file, and we don't even know if that limit is per key or per > > key/IV combo. We can't move ahead until we decide that. > > I understand the 68G limit that you're referring to to be key/IV combo, > which means that a key per relation should be just fine. Yes, that is what I thought too. > Even if it was per key, and it means having a key per 1GB file, > that wouldn't change the point that I was making, so I'm not entirely > sure why it's being mentioned in this context. Because I thought we would use a single key for the entire cluster (heap/index/WAL), and only use another key for encryption key rotation. > I disagree with any approach that lacks a master key with additional > sub-keys, if that helps clarify things. We all know we need a passphrase that unlocks an encryption key. Are you saying we need per-object/table keys? Why, other than for key rotation? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
