|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Stephen Frost <sfrost(at)snowman(dot)net>|
|Cc:||Bruce Momjian <bruce(at)momjian(dot)us>, 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>, 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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2021-05-25 17:04:50 -0400, Stephen Frost wrote:
> 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.
Huh. How are you going to track that efficiently? Do you want to mask
them out before writing? As far as I understand you can't just
re-encrypt a page with the same nonce, but different contents, without
leaking information that you can't have leaked, even if the differences
are not of a secret nature.
I don't think hint bits are the only way to end up with needing to
re-write a page with slightly different content, but the same LSN,
during recovery, after a crash.
I think it's just not going to fly to use LSNs as nonces, and that it's
not worth butchering all kinds of aspect of the system to make it appear
|Next Message||Andres Freund||2021-05-25 23:35:42||Re: storing an explicit nonce|
|Previous Message||Andres Freund||2021-05-25 23:19:36||Re: storing an explicit nonce|