[FEATURE REQUEST] Encrypted indexes over encrypted data
| От | Danylo Hlynskyi |
|---|---|
| Тема | [FEATURE REQUEST] Encrypted indexes over encrypted data |
| Дата | |
| Msg-id | CANZg+ye_fYz06igvCjAK3O9a9NaQXU2CGiZt3NR4-eprdfbxQA@mail.gmail.com обсуждение исходный текст |
| Ответы |
Re: [FEATURE REQUEST] Encrypted indexes over encrypted data
Re: [FEATURE REQUEST] Encrypted indexes over encrypted data |
| Список | pgsql-hackers |
Hi! Haven't found discussions on possible ways to encrypt indexes. Let's start!
The problem==========
Blind indexing also isn't a good enough option.
Obviously we don't want create expression-based indexes, that perform decryption during index build. This will store plaintexts inside index buffers, and decryption key will be included in database dump.
We don't trust full-disk-encryption or any other transparent encryption, because of possible SQL injections.
========
- perform encryption of column
- add decrypting expression-based index with decryption key
- limit ways on disclosing index internals. Ideally if no one except admin can do that========
- data column is encrypted
- index is decrypted by construction, but each it's block is encrypted, even in memory.
- lookups over index do lazy index buffer decrypt and close buffers ASAP
- make every query that has to touch encrypted column or encrypted index require decryption key. This means, SELECT, DELETE, UPDATE, INSERT, VACUUM, CLUSTER, CREATE INDEX, pg_dump, pg_restore all should have decryption key supplied in order to be executed. This also means, that autovacuum daemon can't work.
What do you think about both solutions? Is it hard to implement soluition 2?
В списке pgsql-hackers по дате отправления: