On Wed, Oct 9, 2019 at 3:57 PM Antonin Houska <a...@cybertec.at> wrote: > > Moon, Insung <tsukiwamoon.pg...@gmail.com> wrote: > > > On Wed, Oct 9, 2019 at 2:42 PM Antonin Houska <a...@cybertec.at> wrote: > > > > > > Moon, Insung <tsukiwamoon.pg...@gmail.com> wrote: > > > > > > > I also tried to generate IV using PID (32bit) + tempCounter (64bit) at > > > > first, but in the worst-case PID and tempCounter are used in the same > > > > values. > > > > Therefore, the uniqueness of the encryption key was considered without > > > > considering the uniqueness of the IV value. > > > > > > If you consider 64bit counter insufficient (here it seems that tempCounter > > > counts the 1GB segments), then we can't even use LSN as the IV for > > > relation > > > pages. > > > > The worst-case here is not a lack of tempCounter, but a problem that > > occurs when PID is reused after a certain period. > > Of course, it is very unlikely to be a problem because it is a > > temporary file, but since the file name can know the PID and > > tempFileCounter, if you accumulate some data, the same key and the > > same IV will be used to encrypt other data. So I thought there could > > be a problem. > > ok > > > > > First, it generates a hash value randomly for the file, and uses the > > > > hash value and KEK (or MDEK) to derive and use the key with > > > > HMAC-SHA256. > > > > In this case, there is no need to store the encryption key separately > > > > if it is not necessary to keep it in a separate IV file or memory. > > > > (IV is a hash value of 64 bits and a counter of 32 bits.) > > > > > > You seem to miss the fact that user of buffile.c can seek in the file and > > > rewrite arbitrary part. Thus you'd have to generate a new key for the part > > > being changed. > > > > That's right. I wanted to ask this too. > > Is it possible to overwrite the data already written in the actual > > buffile.c? > > Such a problem seems to become a problem when BufFileWRite function is > > called, and BufFileSeek function is called, and BufFileRead is called. > > In other words, the file is not written in units of 8kb, but the file > > is changed in the pos, and some data is read in another pos. > > 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. 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. Regards, -- Masahiko Sawada
