Re: Transparent Data Encryption (TDE) and encrypted files
От | Antonin Houska |
---|---|
Тема | Re: Transparent Data Encryption (TDE) and encrypted files |
Дата | |
Msg-id | 76481.1571035369@antos обсуждение исходный текст |
Ответ на | Re: Transparent Data Encryption (TDE) and encrypted files (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Transparent Data Encryption (TDE) and encrypted files
|
Список | pgsql-hackers |
Masahiko Sawada <sawada.mshk@gmail.com> wrote: > On Wed, Oct 9, 2019 at 3:57 PM Antonin Houska <ah@cybertec.at> wrote: > > > > Moon, Insung <tsukiwamoon.pgsql@gmail.com> wrote: > > > > v04-0011-Make-buffile.c-aware-of-encryption.patch in [1] changes buffile.c so > > that data is read and written in 8kB blocks if encryption is enabled. In order > > to record the IV per block, the computation of the buffer position within the > > file would have to be adjusted somehow. I can check it soon but not in the > > next few days. > > As far as I read the patch the nonce consists of pid, counter and > block number where the counter is the number incremented each time of > creating a BufFile. Therefore it could happen to rewrite the buffer > data with the same nonce and key, which is bad. This patch was written before the requirement on non-repeating IV was raiesed, and it does not use the AES-CTR mode. I mentioned it here because it reads / writes data in 8kB blocks. > So I think we can have the rewrite counter of the block in the each 8k > block header. And then the nonce consists of block number within a > segment file (4 bytes), temp file counter (8 bytes), rewrite counter > (2 bytes) and CTR mode counter (2 bytes). And then if we have a > single-use encryption key per backend processes I guess we can > guarantee the uniqueness of the combination of key and nonce. Since the segment size is 1 GB, the segment cosists of 2^17 blocks, so 4 bytes will not be utilized. As for the "CTR mode counter", consider that it gets incremented once per 16 bytes of input. So even if BLCKSZ is 32 kB, we need no more than 11 bits for this counter. If these two parts become smaller, we can perhaps increase the size of the "rewrite counter". -- Antonin Houska Web: https://www.cybertec-postgresql.com
В списке pgsql-hackers по дате отправления: