On Wed, Jul 31, 2019 at 03:29:59PM +0900, Masahiko Sawada wrote: > Just to confirm, we have 21 bits left for nonce in CTR? We have LSN (8 > bytes), page-number (4 bytes) and counter (11 bits) in 16 bytes nonce > space. Even though we have 21 bits left we cannot store relfilenode to > the IV.
No. The nonce is the LSN and page number, the CTR counter (11 bits), and 21 extra bits. CTR needs a nonce for every 16-byte block, if you want to think of it that way. Even though there isn't space for the relfilenode in the nonce, We could use the relfilenode/tablespace/database id by mixing into a derived key, based on the master key, but as I stated in another email, we don't want do that unles we have to. > BTW I've received a review about the current design by some > cryptologists in our company. They recommended to use CTR rather than > CBC. The main reason is that in block cipher it's important to ensure > the uniqueness even for every input block to the block cipher. CBC is > hard to ensure that because the previous output is the next block's > input. Whereas in CTR, it encrypts each blocks separately with > key+nonce. Therefore if we can ensure the uniqueness of IV we can meet > that. Also it's not necessary to encrypt IV as it's okey to be > predictable. So I vote for CTR for at least for tables/indexes > encryption, there already might be consensus though. Yes, you are more likely to get duplicate nonce in CBC mode rather than the CTR mode we are proposing. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
