Может ли PostgreSQL выполнить запрос к зашифрованным записям?

#sql #postgresql #encryption

#sql #postgresql #шифрование

Вопрос:

Допустим, у меня есть целый столбец в зашифрованной таблице, в таблице также есть незашифрованные столбцы, такие как идентификаторы, и у меня есть ключ шифрования для всего столбца, и я использовал функцию encrypt() СУБД с AES для его хранения.

Мне интересно, можно ли в любом случае выполнить что-то вроде

 SELECT * FROM table1 WHERE decrypt(col1, 'fooz', 'aes') = 'aValue'

Я уже пробовал это в PostgreSQL, и приведенный выше синтаксис не поддерживается. Если нет способа сделать это, каковы обходные пути?

Я изучил возможность дешифрования во временную таблицу, а затем выполнил запрос и отбросил его, но это кажется крайне неэффективным, а также небезопасным, потому что есть вероятность, что расшифрованная таблица может остаться на диске

1. Отвечая на мой собственный вопрос: ВЫБЕРИТЕ * ИЗ таблицы1, ГДЕ decrypt(col1::bytea,’fooz’,’aes’) = ‘AValue’; для расшифровки требуется явное приведение типов.

2. Пожалуйста, обратите внимание, что я хотел бы иметь возможность выполнять общий запрос в зашифрованных столбцах данных. Поэтому я предложил использовать decrypt() . Использование col1=encrypt() слишком ограничено. Например, я могу запросить, ГДЕ col1> 10.

Ответ №1:

Псевдокод

 SELECT * FROM table1 WHERE col1 = encrypt('avalue','fooz','aes');

Или более конкретно:

Реальный код

 SELECT * FROM table1
WHERE col1 = pgp_sym_encrypt('avalue', 'apasswordwithsomeentropy'
                            ,'compress-algo=1, cipher-algo=aes256');

http://www.postgresql.org/docs/8.3/static/pgcrypto.html

1. Не могли бы вы использовать индексированную функцию, чтобы ваши поиски не были медленными? Или это откроет данные, которые вы пытаетесь скрыть в индексе?

2. @StarShip3000, ты можешь, но на самом деле это не имеет смысла, потому что это сделает вставки очень медленными, потому что PostgreSQL придется выполнять шифрование дважды при вставке (один раз для вставки и один раз для индекса), и вы сэкономите 0 времени на выборе.

3. Я не понимаю, почему вы не сэкономили бы время на выборе, если вы можете использовать индекс для decrypt(col1, ‘fooz’, ‘aes’) = ‘AValue’. Конечно, индекс замедлит вставку и обновление, но часто это цена, которую вы готовы заплатить за более быстрое получение ваших данных.

4. @StarShip3000, для сохранения 1 строки decrypt(col1) в индексе сэкономит время. Однако для 10 000 строк приведенный выше код должен будет выполнить шифрование только один раз, так что вы экономите на O (1) стоимости. Поэтому по мере увеличения количества рассматриваемых строк ваша экономия снижается. Кроме того, и это еще более важно. Если вы сделаете select * from user where username = ? and password = encrypt.... уникальный индекс для имени пользователя, индекс для пароля станет ненужным. Таким образом, время, которое, по вашему мнению, вы экономите, не тратится.

5. @StarShip3000, с нетерпением жду 9.2. IMO если вы шифруете, вы шифруете, у вас нет незашифрованных данных где-нибудь в бэк-офисе. Я думаю, что это доставит мне всевозможные юридические и этические проблемы. Представьте, что вы объясняете клиенту, как произошла утечка его зашифрованных данных, потому что вы решили хранить незашифрованные данные в индексе.