Greetings, * Joe Conway (m...@joeconway.com) wrote: > On 7/9/19 5:42 PM, Tomas Vondra wrote: > > There are two basic ways to construct nonces - CSPRNG and sequences, and > > then a combination of both, i.e. one part is generated from a sequence > > and one randomly. > > > > FWIW not sure using OIDs as nonces directly is a good idea, as those are > > inherently low entropy data - how often do you see databases with OIDs > > above 1M or so? Probably not very often, and in most cases those are > > databases where those OIDs are for OIDs and large objects, so irrelevant > > for this purpose. I might be wrong but having a 96-bit nonce with maybe > > just 32bits of entrophy seems suspicious. > > > > That does not mean we can't use the OIDs at all, but maybe hashing them > > into a single 4B value, and then picking the remaining 8B randomly. > > Also, we have a "natural" sequence in the database - LSNs, maybe that > > would be a good source of nonces too? > > I think you missed the quoted part (upthread) from the NIST document: > > "There are two recommended methods for generating unpredictable IVs. > The first method is to apply the forward cipher function, under the > same key that is used for the encryption of the plaintext, to a > nonce. The nonce must be a data block that is unique to each > execution of the encryption operation. For example, the nonce may be > a counter, as described in Appendix B, or a message number. The > second method is to generate a random data block using a > FIPS-approved random number generator." > > That first method says a counter as input produces an acceptably > unpredictable IV as long as it is unique to each encryption operation. > If each page is going to be an "encryption operation", so as long as our > input nonce is unique for a given key, we should be ok. If the input > nonce is tableoid+pagenum and the key is different per database (at > least, hopefully different per tablespace too), we should be good to go, > at least from what I can see.
What I think Tomas is getting at here is that we don't write a page only once. A nonce of tableoid+pagenum will only be unique the first time we write out that page. Seems unlikely that we're only going to be writing these pages once though- what we need is a nonce that's unique for *every write* of the 8k page, isn't it? As every write of the page is going to be encrypting something new. With sufficient randomness, we can at least be more likely to have a unique nonce for each 8K write. Including the LSN seems like it'd be a possible alternative. Thanks, Stephen
signature.asc
Description: PGP signature