On Wed, Aug 7, 2019 at 05:13:31PM +0900, Masahiko Sawada wrote: > I understood. IIUC in your approach postgres processes encrypt WAL > records when inserting to the WAL buffer. So WAL data is encrypted > even on the WAL buffer. > > It works but I think the implementation might be complex; For example > using openssl, we would use EVP functions to encrypt data by > AES-256-CTR. We would need to make IV and pass it to them and these > functions however don't manage the counter value of nonce as long as I > didn't miss. That is, we need to calculate the correct counter value > for each encryption and pass it to EVP functions. Suppose we encrypt > 20 bytes of WAL. The first 16 bytes is encrypted with nonce of > (segment_number, 0) and the next 4 bytes is encrypted with nonce of > (segment_number, 1). After that suppose we encrypt 12 bytes of WAL. We > cannot use nonce of (segment_number, 2) but should use nonce of > (segment_number , 1). Therefore we would need 4 bytes padding and to > encrypt it and then to throw that 4 bytes away .
Since we want to have per-byte control over encryption, for both heap/index pages (skip LSN and CRC), and WAL (encrypt to the last byte), I assumed we would need to generate a bit stream of a specified size and do the XOR ourselves against the data. I assume ssh does this, so we would have to study the method. -- 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 +