Re: storing an explicit nonce - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: storing an explicit nonce
Date
Msg-id 202105272013.i2w442ojjpnv@alvherre.pgsql
Whole thread Raw
In response to Re: storing an explicit nonce  (Andres Freund <andres@anarazel.de>)
Responses Re: storing an explicit nonce
List pgsql-hackers
On 2021-May-27, Andres Freund wrote:

> On 2021-05-27 15:48:09 -0400, Robert Haas wrote:

> > Another case where this sort of thing might happen is a standby doing
> > whatever the master did. I suppose that could be avoided if the
> > standby always has its own encryption keys, but that forces a key
> > rotation when you create a standby, and it doesn't seem like a lot of
> > fun to insist on that. But the information leak seems minor.
> 
> Which leaks seem minor? The "hole" issues leak all the prior contents of
> the hole, without needing any complicated analysis of the data, because
> one plain text is known (zeroes).

Maybe that problem could be solved by having PageRepairFragmentation,
compactify_tuples et al always fill the hole with zeroes, in encrypted
databases.

-- 
Álvaro Herrera       Valdivia, Chile



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Next
From: Tom Lane
Date:
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?