Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, May 25, 2021 at 05:04:50PM -0400, Stephen Frost wrote: > > > Now, if we want to consult some security experts and have them tell us > > > the hint bit visibility is not a problem, we could get by without using a > > > new nonce for hint bit changes, and in that case it doesn't matter if we > > > have a separate LSN or custom nonce --- it doesn't get changed for hint > > > bit changes. > > > > I do think it's reasonable to consider having hint bits not included in > > the encrypted part of the page and therefore remove the need to produce > > a new nonce for each hint bit change. Naturally, there's always an > > increased risk when any data in the system isn't encrypted but given > > the other parts of the system which aren't being encrypted as part of > > this effort it hardly seems like a significant increase of overall risk. > > I don't believe that any of the auditors and security teams I've > > discussed TDE with would have issue with hint bits not being encrypted- > > the principle concern has always been the primary data. > > OK, this is good to know. I know the never-reuse rule, so it is good to > know it can be relaxed for certain data without causing problems in > other places. Should I modify my patch to do this?
Err, to be clear, I was saying that we could exclude the hint bits *entirely* from what's being encrypted and I don't think that would be a huge issue. We still absolutely need to continue to implement a never-reuse rule when it comes to nonces and making sure that we don't encrypt different sets of data with the same key+nonce, it's just that if we exclude the hint bits from encryption then we don't need to worry about making sure to use a different nonce each time the hint bits change- because they're no longer relevant. > FYI, technically, the hint bit is still encrypted, but could _flip_ in > the encrypted file if changed, so that's why we say it is visible. If > we used a block cipher instead of a streaming one (CTR), this might not > work because the earlier blocks can be based in the output of later > blocks. No, in what I'm talking about, the hint bits would be entirely excluded and therefore not encrypted. I don't think we should keep the hint bits as part of what's encrypted but not increase the nonce, that's dangerous imv. > > Naturally, the more we are able to encrypt and the more we can do to > > provide data integrity validation, may open up the possibility for PG to > > be used in even more places, which argues for having some way of making > > these choices be options which a user could decide at initdb time, or at > > least contemplating a road map to where we could offer users the option > > to have other parts of the system be encrypted and ideally have data > > integrity checks, but I don't think we necessarily have to solve > > everything right now in that regard- just having TDE in some form will > > open up quite a few new possibilities for v15, even if it doesn't > > include data integrity validation beyond our existing checksums and > > doesn't encrypt hint bits. > > I am thinking full-file system encryption should still be used by people > needing that. I am concerned that if we add too many > restrictions/additions on this feature, it will not be very useful. I disagree in the long term but I'm fine with paring down what we specifically work to address for v15. Thanks, Stephen
signature.asc
Description: PGP signature
