On Mon, Mar 16, 2020 at 04:13:21PM +0900, Masahiko Sawada wrote: > On Thu, 12 Mar 2020 at 08:13, Bruce Momjian > <bruce.momj...@enterprisedb.com> wrote: > > > > On Fri, Mar 6, 2020 at 03:31:00PM +0900, Masahiko Sawada wrote: > > > On Fri, 6 Mar 2020 at 15:25, Moon, Insung <tsukiwamoon.pg...@gmail.com> > > > wrote: > > > > > > > > Dear Sawada-san > > > > > > > > I don't know if my environment or email system is weird, but the V5 > > > > patch file is only include simply a changed list. > > > > and previous V4 patch file size was 64kb, but the v5 patch file size > > > > was 2kb. > > > > Can you check it? > > > > > > > > > > Thank you! I'd attached wrong file. > > > > Looking at this thread, I wanted to make a few comments: > > > > Everyone seems to think pgcrypto need some maintenance. Who would like > > to take on that task? > > > > This feature does require openssl since all the encryption/decryption > > happen via openssl function calls. > > > > Three are three levels of encrypt here: > > > > 1. The master key generated during initdb > > > > 2. The passphrase to unlock the master key at boot time. Is that > > optional or required? > > The passphrase is required if the internal kms is enabled during > initdb. Currently hashing the passphrase is also required but it could > be optional. Even if we make hashing optional, we still require > openssl to wrap and unwrap.
I think openssl should be required for any of this --- that is what I was asking. > > Could the wrap functions expose the master encryption key by passing in > > empty string or null? > > Currently the wrap function returns NULL if null is passed, and > doesn't expose the master encryption key even if empty string is > passed because we add random IV for each wrapping. OK, good, makes sense, but you see why I am asking? We never want the master key to be visible. > > I wonder if we should create a derived key from > > the master key to use for pg_wrap/pg_unwrap, maybe by appending a fixed > > string to all strings supplied to these functions. We could create > > another derived key for use in block-level encryption, so we are sure > > the two key spaces would never overlap. > > Currently the master key is 32 bytes but you mean to add fixed string > to the master key to derive a new key? Yes, that was my idea --- make a separate keyspace for wrap/unwrap and block-level encryption. > > pgcryptokey shows a method for creating a secret between client and > > server using SQL that does not expose the secret in the server logs: > > > > https://momjian.us/download/pgcryptokey/ > > > > I assume we will create a 256-bit key for the master key, but give users > > an option of 128-bit vs 256-bit keys for block-level encryption. > > 256-bit keys are considered necessary for security against future > > quantum computing attacks. > > 256-bit keys are more weaker than 128-bit key in terms of quantum > computing attacks? No, I was saying we are using 256-bits for the master key and might allow 128 or 256 keys for block encryption. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
