On Mon, Oct 14, 2019 at 3:42 PM Antonin Houska <a...@cybertec.at> wrote: > > Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > On Wed, Oct 9, 2019 at 3:57 PM Antonin Houska <a...@cybertec.at> wrote: > > > > > > Moon, Insung <tsukiwamoon.pg...@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".
Yeah I designed it to make implementation easier but we can increase the size of the rewrite counter to 3 bytes while the block number uses 3 bytes. Regards, -- Masahiko Sawada
