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

[VolCh]

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

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

[AterCattus]

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

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

[VolCh]

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

[AterCattus]

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

[WebSpider]

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

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

[JC_Piligrim]

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

sleep(42)

:)

[Skull]

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

[iXCray]

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

[AlexanderYastrebov]

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

[Skull]

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

[AlexanderYastrebov]

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

[AlexanderYastrebov]

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

[elw00d]

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

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

wtf

[Foror]

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

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

[Foror]

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

[Foror]

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

[Master_Dante]

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