Шифрование вложенной карты маленьких строк с одним и тем же симметричным ключом
Допустим, я создаю веб-приложение, в котором пользователи могут создавать вложенное дерево строк (с конфиденциальной информацией). Эти строки, предположительно, довольно короткие. Я хочу зашифровать ключи и значения в этом дереве перед сохранением. Все значения в дереве будут зашифрованы на стороне клиента с использованием симметричного ключа, предоставленного пользователем. Точно так же они будут расшифрованы на стороне клиента при чтении.
Дерево сохраняется в базе данных Mongo.
Я не могу решить, следует ли сериализовать дерево и зашифровать его целой строкой или нужно ли шифровать значения по отдельности, учитывая, что все данные в дереве будут зашифрованы с использованием одного и того же ключа.
Какие плюсы и минусы того или другого?
Из того, что я могу сказать, AES использует размер блока 128 битов, что означает, что любая строка может расти до 15 символов при кодировании, что говорит в пользу кодирования сериализованной строки (если вы хотите избежать издержек)
Примечание. Хотя веб-приложение будет использовать как HTTPS, так и белый список IP-адресов и многофакторную аутентификацию, я хочу приложить усилия для предотвращения взлома данных в случае кражи базы данных Mongo. Вот для чего я здесь. Совет или мысли о том, как этого добиться, приветствуется.
Обновить
Кроме того, я также хочу, чтобы мой сервис внушал доверие. Отправка данных в открытом виде (хотя и через HTTPS) означает, что пользователь должен доверять мне, чтобы я зашифровал его перед сохранением. Шифрование на стороне клиента позволяет мне подчеркнуть, что я не знаю (или должен знать), что я экономлю.
2 ответа
Я не могу придумать причину, по которой эти подходы были бы разными с точки зрения безопасности реальных строк (при условии, что они оба реализованы правильно). Индивидуальное шифрование строк, очевидно, означает, что структура дерева не будет секретной, но я не уверен, беспокоит ли вас это или нет. Например, если вы шифруете каждую строку отдельно, кто-то, увидев шифротексты, может узнать, сколько ключей в дереве, и он также может узнать что-нибудь о длине каждого ключа и его значении. Если вы зашифруете дерево как весь сериализованный большой двоичный объект, то тот, кто увидит зашифрованный текст, может примерно сказать, сколько данных в дереве, но ничего не говорит о длине или количестве отдельных ключей / значений.
Что касается накладных расходов, то, как вы упомянули, будет учитываться отступ. Большим источником затрат на хранение являются IV: если вы используете режим блочного шифра, такой как CTR, вам нужно использовать отдельный IV для каждого зашифрованного текста. Это означает, что если вы шифруете каждую строку отдельно, вам необходимо сохранить IV для каждой строки. Если вы шифруете все сериализованное дерево, то вам просто нужно сохранить один IV для этого одного зашифрованного текста.
Перед тем, как реализовать это в Javascript, вы должны убедиться, что вы действительно добились реального улучшения безопасности от выполнения шифрования на стороне клиента. Эта статья является классической: http://www.matasano.com/articles/javascript-cryptography/ Важно помнить, что сервер предоставляет код шифрования Javascript, поэтому шифрование данных на клиенте не защищает его от сервер. Если ваша главная задача - украденная база данных, вы можете добиться такой же защиты, просто зашифровав данные на сервере перед их вставкой в базу данных.
Прежде всего, я не эксперт по безопасности;-)
Я не могу решить, следует ли сериализовать дерево и зашифровать его целой строкой или нужно ли шифровать значения по отдельности, учитывая, что все данные в дереве будут зашифрованы с использованием одного и того же ключа.
Я бы сказал, что сначала нужно сериализовать дерево и зашифровать результат, который имеет самый большой недостаток.
В успешном взломе шифрования огромную роль играет знание определенных символов, которые довольно часто встречаются в оригинальном тексте - например, букв e и n на английском языке, - и проведение статистического анализа на основе зашифрованного текста.
Теперь допустим, что вы используете, например, JSON для сериализации вашего дерева на стороне клиента перед его шифрованием. Как злоумышленник, я бы легко это знал, так как могу анализировать ваш клиентский сценарий на досуге. Так что я также уже знаю, что "буквы" {, }, [, ],: и "будут иметь высокий процент встречаемости в каждом" тексте ", который вы шифруете… и что первая буква каждого текста будет либо {или [ (в зависимости от того, является ли ваше дерево объектом или массивом) - это уже довольно много потенциально очень полезных знаний о текстах, которые шифруются вашим приложением.