Re: storing an explicit nonce

Greetings,

* Bruce Momjian (bruce@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