Утечка через Гомоморфные Операции Зашифрованного текста
Рассмотрим две стороны, а именно, P_0 и P_1. P_0 и P_1 имеют открытые тексты p_a и p_b соответственно.
P_0 шифрует p_a, чтобы получить c_a = Enc(p_a)
с его открытым ключом, и отправляет его в P_1.
P_1 выполняет multiply_plain(c_a, p_b, c)
, с последующим sub_plain_inplace(c, p_R)
(где p_R - это произвольный открытый многочлен, чтобы скрыть произведение a и b), а затем отправляет c в P_0.
Может ли шум в c показать некоторую информацию о p_b до P_0, несмотря на то, что продукт маскируется p_R?
Если да, то как я могу избежать этой утечки? Есть ли способ добавить случайный шум к c, чтобы заглушить влияние p_b на шум в c?
Есть ли в SEAL функция для шифрования с использованием шума из большего интервала? Если есть, то, возможно, я могу зашифровать p_R с дополнительным шумом, чтобы заглушить удар.
1 ответ
Да, шум теоретически может раскрыть информацию о входных данных для продукта, даже после добавления к нему нового шифрования. Схемы гомоморфного шифрования обычно не предназначены для обеспечения конфиденциальности ввода в таких протоколах MPC. Мне не ясно, насколько выполнимой была бы эта "атака" в реальных сценариях применения (за исключением патологических случаев).
Чтобы избежать этой проблемы и получить полу-честную защиту для протоколов, которые вы, возможно, захотите построить из схемы BFV, вы действительно можете делать то, что предлагали: зашумить шум, добавив шифрование с искусственно большим шумом. Это было использовано, например, здесь (раздел 5.2), чтобы доказать безопасность протокола. См. Также лемму 1 в этой статье.
Более привлекательный подход, основанный на начальной загрузке, описан в этой статье Ducas и Stehle. Поскольку начальная загрузка как в BGV, так и в BFV крайне ограничена (и не реализована в SEAL), я не считаю этот подход практичным, за исключением, возможно, некоторых очень редких сценариев.