Re: storing an explicit nonce

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Subject: Re: storing an explicit nonce
Date: 2021-05-25 21:22:43
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


* Bruce Momjian (bruce(at)momjian(dot)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

> > 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.



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2021-05-25 21:23:04 Re: storing an explicit nonce
Previous Message Bruce Momjian 2021-05-25 21:17:25 Re: storing an explicit nonce