Re: storing an explicit nonce

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>

To: Bruce Momjian <bruce@momjian.us>

Cc: Ants Aasma <ants@cybertec.at>, Sasasu <i@sasa.su>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2021-10-07T18:52:07Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Rethink method for assigning OIDs to the template0 and postgres DBs.
- 2cb1272445d2 15.0 landed
pg_upgrade: Preserve database OIDs.
- aa01051418f1 15.0 landed
pg_upgrade: Preserve relfilenodes and tablespace OIDs.
- 9a974cbcba00 15.0 landed
Fix for new Boolean node
- cf925936ecc0 15.0 cited
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
Add macro RelationIsPermanent() to report relation permanence
- 95d77149c535 14.0 landed
Enhance nbtree index tuple deletion.
- d168b666823b 14.0 cited

Greetings,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Thu, Oct  7, 2021 at 09:38:45PM +0300, Ants Aasma wrote:
> > On Wed, 6 Oct 2021 at 23:08, Bruce Momjian <bruce@momjian.us> wrote:
> > 
> >     Yes, I would prefer we don't use the LSN.  I only mentioned it since
> >     Ants Aasma mentioned LSN use above.
> > 
> > 
> > Is there a particular reason why you would prefer not to use LSN? I suggested
> > it because in my view having a variable tweak is still better than not having
> > it even if we deem the risks of XTS tweak reuse not important for our use case.
> > The comment was made under the assumption that requiring wal_log_hints for
> > encryption is acceptable.
> 
> Well, using the LSN means we have to store the LSN unencrypted, and that
> means we have to carve out a 16-byte block on the page that is not
> encrypted.

With XTS this isn't actually the case though, is it..?  Part of the
point of XTS is that the last block doesn't have to be a full 16 bytes.
What you're saying is true for XEX, but that's also why XEX isn't used
for FDE in a lot of cases, because disk sectors aren't typically
divisible by 16.

https://en.wikipedia.org/wiki/Disk_encryption_theory

Assuming that's correct, and I don't see any reason to doubt it, then
perhaps it would make sense to have the LSN be unencrypted and include
it in the tweak as that would limit the risk from re-use of the same
tweak over time.

Thanks,

Stephen