Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
От | Stephen Frost |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Дата | |
Msg-id | 20190710184430.GT29202@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
|
Список | pgsql-hackers |
Greetings, * Bruce Momjian (bruce@momjian.us) wrote: > On Wed, Jul 10, 2019 at 12:38:02PM -0600, Ryan Lambert wrote: > > > > what is it that gets stored in the page for > > decryption use, the nonce or the IV derived from it? > > > > > > I believe storing the IV is preferable and still secure per [1]: "The IV need > > not be secret" > > > > Beyond needing the database oid, if every decrypt function has to regenerate > > the IV from the nonce that will affect performance. I don't know how expensive > > the forward hash is but it won't be free. > > Well, I think we have three options. We have 3 4-byte integers > (pg_class.oid, LSN, page-number) that could be concatenated to be the > IV, we could run those through a hash, or we could run them through the > encryption function with the secret. I didn't see where it was said that using a hash was a good idea in this context..? Encrypting it with the key looked like it was discussed as a viable option. I had understood that part of the point of using the table OID and page-number was also so that we didn't have to explicitly store the result, therefore requiring us to need less space on the page to make this happen. Thanks, Stephen
Вложения
В списке pgsql-hackers по дате отправления: