Комментарии 29
Скажите, пожалуйста, чем в вашей статье различаются алгорифм и алгоритм?
Проблемы с линейной алгеброй начинаются, когда нужно построить обратимые матрицы с нужными свойствами —
1. Легко вычислимые. (ибо должно быть сильно дешевле построить шифрующие матрицы, чем решить систему локально)
2. Сложно угадываемые (ибо криптграфия, все дела)
3. Хорошо обусловленные (если вы переводами туда-сюда увеличиваете ошибку хотя бы в 100 раз, вся эта кухня на реально нужных задачах оказывается, опять же, уже не нужна). Или надо говорить о публичном нахождении хорошего приближения с дальнейшей локальной доводкой до нужной точности каким-нибудь итерационным методом.
1. Легко вычислимые. (ибо должно быть сильно дешевле построить шифрующие матрицы, чем решить систему локально)
2. Сложно угадываемые (ибо криптграфия, все дела)
3. Хорошо обусловленные (если вы переводами туда-сюда увеличиваете ошибку хотя бы в 100 раз, вся эта кухня на реально нужных задачах оказывается, опять же, уже не нужна). Или надо говорить о публичном нахождении хорошего приближения с дальнейшей локальной доводкой до нужной точности каким-нибудь итерационным методом.
да.
Рассматривайте этот текст просто как рассуждения на тему.
В тексте же нет программных кодов, а про матрицы я тоже упоминаю что это не более чем кольцо с делителями нуля.
Рассматривайте этот текст просто как рассуждения на тему.
В тексте же нет программных кодов, а про матрицы я тоже упоминаю что это не более чем кольцо с делителями нуля.
да.
Рассматривайте этот текст просто как рассуждения на тему.
В тексте же нет программных кодов, а про матрицы я тоже упоминаю что это не более чем кольцо с делителями нуля.
Рассматривайте этот текст просто как рассуждения на тему.
В тексте же нет программных кодов, а про матрицы я тоже упоминаю что это не более чем кольцо с делителями нуля.
не нужно вам всё кольцо, возьмите только мультипликативную группу.
проблема, как написали выше, в построении обратимых матриц. надо переложить эту задачу на внешний вычислитель.
предложение: построить в облаке 2n матриц и обратных к ним и взять произведение n из них.
проблема, как написали выше, в построении обратимых матриц. надо переложить эту задачу на внешний вычислитель.
предложение: построить в облаке 2n матриц и обратных к ним и взять произведение n из них.
надо переложить эту задачу на внешний вычислитель.
да
построить в облаке 2n матриц и обратных
только надо явно указывать свойства каждой — а то напихают всё из одного класса.
как в ресторане — если закажешь просто пожрать — принесут суп из картошки, рагу из картошки, компот из картошки и десерт из картошки.
А вы знакомы с работой "CryptDB: Protecting Confidentiality with Encrypted Query Processing"? Там предложен несколько другой подход, решающий ту же проблему, и мне он представляется весьма перспективным, потому что не ведет к увеличению требуемой вычислительной мощности (но возможно с некоторым снижением криптостойкости, что пока еще не проанализировано экспертами в области криптоанализа).
глянул. что увидел за 5 минут — очередной велосипед по превращению реляционной базы в шифрованную реляционную базу путём добавления ещё одного программного слоя.
у oracle с давних времён шифрование строк таблиц встроено в систему управления базы, но большинство программистов или не знают об этих фичах, а если знают то намеренно не пользуются поскольку стоимость разработки ПО возрастает на порядки.
ведь кроме задачи хранения более важной является система распределения прав.
если несмотря на шифрование данных в таблицах все пользователи продолжают иметь равные права по доступу к данным то проще поместить базу в защищённый периметр — на шифруемый диск в серверной с ограниченным доступом и убедится что из вне общение с устройством возможно только по чётко описанным протоколам и никак иначе.
если имеется ввиду размещение базы в публичном датацентре — для ЛЮБЫХ поситетелей веб-сайтов…
в общем как обычно вся необходимая информация для полного доступа к «шифрованной» базе данных окажется на том же сервере где размещён apache.
да и вопрос хранения данных+их связей — не тема моей публикации.
у oracle с давних времён шифрование строк таблиц встроено в систему управления базы, но большинство программистов или не знают об этих фичах, а если знают то намеренно не пользуются поскольку стоимость разработки ПО возрастает на порядки.
ведь кроме задачи хранения более важной является система распределения прав.
если несмотря на шифрование данных в таблицах все пользователи продолжают иметь равные права по доступу к данным то проще поместить базу в защищённый периметр — на шифруемый диск в серверной с ограниченным доступом и убедится что из вне общение с устройством возможно только по чётко описанным протоколам и никак иначе.
если имеется ввиду размещение базы в публичном датацентре — для ЛЮБЫХ поситетелей веб-сайтов…
в общем как обычно вся необходимая информация для полного доступа к «шифрованной» базе данных окажется на том же сервере где размещён apache.
да и вопрос хранения данных+их связей — не тема моей публикации.
В статье предлагается шифрование на клиентском ключе при охранении возможности исполнять запросы на сервере, при условии, что сервер НЕ знает клиентского ключа (эта проблема актуальна для публичных облаков, когда клиент не доверяет провайдеру), то есть решается задача, обозначенная в теме Вашего поста.
Что же касается Oracle — то там речь идет о шифровании на ключе, известным серверу, что НЕ решает проблему недоверия к провайдеру.
Что же касается Oracle — то там речь идет о шифровании на ключе, известным серверу, что НЕ решает проблему недоверия к провайдеру.
Что же касается Oracle — то там есть всё.
если вам знакома только иерархическая модель разделения прав — то все вопросы к царю.
если вам знакома только иерархическая модель разделения прав — то все вопросы к царю.
что известно двоим — известно свинье (с) Миллер
ну так приведите ссылку на какое-нибудь описание того, о чем вы говорите — как сервер Oracle выполняет скажем поиск по таблице, зашифрованной на клиентском ключе, не зная клиентского ключа, — просто мне такого вида шифрования найти не удалось.
а какую версию вы ПОКУПАЛИ?
а картинку ключей от квартиры где деньги лежат в своём профиле опубликовать не надо?
похвастаться — смотрите какие красыва ключики.
если сервер НЕ знает клиентского ключа
то и ЛЮБОЙ клиент НЕ знает клиентского ключа
тогда о какой выдаче данных идёт речь? если никто ничего не знает?
Значит кто-то должен знать — и скорее всего вся необходимая информация для полного доступа к «шифрованной» базе данных окажется на том же сервере где размещён apache.
можно постараться заныкать подальше — но при более детальном обыске найдётся всё.
то и ЛЮБОЙ клиент НЕ знает клиентского ключа
тогда о какой выдаче данных идёт речь? если никто ничего не знает?
Значит кто-то должен знать — и скорее всего вся необходимая информация для полного доступа к «шифрованной» базе данных окажется на том же сервере где размещён apache.
можно постараться заныкать подальше — но при более детальном обыске найдётся всё.
к тому же в этой статье — сразу в начале нарисован код программы которая формирует вычисляемое поле (расшифрованием данных) — видимо для сортировки или чего-то там для обработки запросом SQL.
дальше можно не читать.
дальше можно не читать.
тому же в этой статье — сразу в начале нарисован код программы которая формирует вычисляемое поле (расшифрованием данных)
вы определитесь сразу — вам надо ключ от квартиры где деньги лежат или деньги из квартиры?
Правильно ли Вы выбираете вершки или корешки — как в русской сказке?
Настоящий «хакер» это ведь тот кто ключи подбирает — так ведь в кино толкуют.
Странно, что ни разу в статье не упомянуто гомоморфное шифрование
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обработка приватных данных на публичных вычислительных сетях