alizar Dec 20 2011 at 16:21

CryptDB: обработка информации в БД без её дешифрования

2 min

4.8K

SQL*

+32

Comments 17

VolCh Dec 20 2011 at 16:59

Я правильно понял основную фичу — администратор ресурса при всём желании не может получить доступ к данным, только клиенты, обладающие соответствующими ключами? Или всё же происходит полная расшифровка и в какой-то момент времени в памяти будут расшифрованные данные, а дальше дело техники?

Просто заморозили один SaaS проект из-за персональных данных третьих лиц. Хранить в открытом виде недопустимо вообще, расшифровывать на сервере для выборки и сортировки нежелательно, выдавать таблицу клиенту, чтоб он сам расшифровывал нереально.

AterCattus Dec 20 2011 at 18:42

>>Это реализовано за счёт «луковичного» многоступенчатого шифрования, когда данные зашифрованы в несколько слоёв разными алгоритмами.
>>На нижнем слое используются самые надёжные алгоритмы, а операции в верхних слоях возможны без расшифровки нижних слоёв.

Расшифровывается только столько, сколько нужно для выполнения конкретных действий (операции проводятся над частично шифрованными данными).
А чтобы получить исходные данные — нужно поломать все уровни шифрования.

VolCh Dec 20 2011 at 19:26

На рисунках не очень понятно для JOIN или текстового поиска нужно расшифровывать или нет.

AterCattus Dec 20 2011 at 19:41

Судя по картинкам, для JOIN нужно выполнить три стадии декодирования.

WebSpider Dec 20 2011 at 17:10

… скорость операций по сравнению с обычной СУБД возрастала примерно в триллион раз.

Может всё же падала?

JC_Piligrim Dec 21 2011 at 01:01

Нет, возрастала. Но инженеры приложили неимоверные интеллектуальные усилия, и все-таки смогли побороть и эту проблему:

sleep(42)

:)

Skull Dec 20 2011 at 17:57

Сочуствую разработчикам, которым прийдется применять эту БД в крупном проекте. Скорость отладки упадет раза в 2, даже если написать какой-то класс для дебага.

iXCray Dec 20 2011 at 18:25

Профессионализм разработчиков определит успех, сочувствовать не нужно ;-)

AlexanderYastrebov Dec 20 2011 at 19:31

Сделают зеркало в виде обычной БД или зеркалирование открытых данных в ней же для отладки.

Skull Dec 20 2011 at 20:00

А зачем вообще что-то шифровать если рядом обычная БД MySQL или колонки с незашифрованными данными?

AlexanderYastrebov Dec 20 2011 at 20:02

ниже ответил, промахнулся

AlexanderYastrebov Dec 20 2011 at 20:02

Будет отладочный режим, чтобы разработчик мог посмотреть на сырые данные. На бою зеркала не будет естественно.

elw00d Dec 20 2011 at 21:47

Подход, реализованный в CryptDB, называется полным гомоморфным шифрованием. Первую полностью гомоморфную модель для СУБД предложил в 2009 году криптограф из IBM Research Крейг Джентри (Craig Gentry), она является гомоморфной для операций умножения и сложения одновременно, что даёт возможность выразить любую математическую функцию. Правда, была одна проблема: скорость операций по сравнению с обычной СУБД возрастала примерно в триллион раз.

С другой стороны, CryptDB уменьшает скорость большинства операций в базе данных БД SQL всего на 15-26% по сравнению с MySQL.

wtf

Foror Dec 21 2011 at 09:31

Предположим у нас есть два сервера, первый стоит у меня под боком, второй в далеком облаке какого-нибудь Микрогугла. На втором сервере работает CryptDB, к которой идут запросы с первого сервера. Позволяет CryptDB делать так, что данные на втором сервере будут всегда в зашифрованном виде, во время запросов с первого? Но при передачи зашифрованного результата на первый сервер, он сможет расшифровать их.

Возможно такая схема работы с CryptDB?

Foror Dec 21 2011 at 09:34

>На втором сервере работает CryptDB, к которой идут запросы с первого сервера
При этом запросы с первого сервера также идут в зашифрованном виде

Foror Dec 21 2011 at 09:40

Или для каких операций это возможно, пока пробежался по научной работе, вижу, что для like операции такое можно сделать.

Master_Dante Nov 28 2017 at 03:25

Можете привести простой пример как вы сделали сравнение на гомоморфной крипте. Ведь для банальной сортировки нужно сравнивать данные. Больше меньше например.