Во-первых, обратите внимание, что BFV традиционно формулируется в терминах арифметика схемы, а не логические.
Например, исходная статья имеет пространство сообщений вида $R_t := \mathbb{Z}_t[x] / (\Phi_n(x))$, куда $\Phi_n$ это $n$й циклотомический полином (когда $n$ это степень двойки это просто $х^п+1$).
Это относительно важно, поскольку фундаментальные строительные блоки арифметических схем нет ИЛИ и И, но (мод. $р$ вариант) XOR и AND, который немного отличается.
Что касается ваших проблем с умножением BFV, я думаю, что вы немного неправильно читаете спецификацию BFV.
Обычно (скажем, в исходный документ) пространство сообщений указано как $R_t$, которое, как упоминалось ранее, является кольцом многочленов (когда $n$ является степенью 2) $\bмод х^n+1$.
Итак, чтобы наша схема шифрования была полностью гомоморфной, нам нужно, чтобы мы могли выполнять сложение и умножение пространства сообщений по шифротекстам.
Это умножение пространства сообщения равно $\bмод х^n+1$ (и $\bмод т$, но что угодно), как вы указали.
Это означает, что арифметика $\bмод х^n+1$ это то, что математически требуется для того, чтобы схема была полностью гомоморфной, поэтому ожидается, что продукт будет такой формы, и это не проблема.
Конечно, разработчики приложений могут не захотеть использовать эту «забавную арифметику».
Это то, что дизайнеры библиотек должны решить позже.
Например, один из способов "исправить" это (что довольно наивно --- я предполагаю, что есть лучшие решения) состоит в том, чтобы кодировать сообщения только в постоянные члены полиномов.
Должно быть относительно просто увидеть, что это «забавное умножение» становится стандартным умножением, когда оно ограничено постоянными полиномами.
Есть и другие вещи, которые можно было бы сделать, например, можно было бы разрешить многочлены вида $m(x) = m_0+m_1x$ если вы знаете, что мультипликативная глубина схемы, которую вы оцениваете, не превышает $\log_2 п$, или в более общем смысле $m(x) = \sum_{i =0}^p m_i x^i$ если мультипликативная глубина не более $\log_{1+p} п$.
Это просто потому, что с этой границей глубины нельзя получить многочлен степени $\geq п$, поэтому тот факт, что умножение может «зацикливаться», не имеет значения.
Конечно, я уверен, что есть более умные идеи о том, что можно сделать, чтобы эмулировать «стандартную» арифметику с «забавной» арифметикой, которую мы получаем, но это действительно ортогонально пониманию BFV.
Это также стоит отметить, что ваш комментарий
но это нужно по коэффициентам и по многочлену, а не по самим полиномам
похоже, вы ищете идею каноническое вложение.
В частности, примерно десять лет назад было замечено, что если нам нужен тип данных, подобный массиву, $[a_0,\dots,a_n]$ с которыми можно выполнять (по слотам) арифметические операции, то коэффициенты полиномов действительно являются довольно плохим выбором.
Это связано с тем, что (среди прочего) естественная операция умножения многочленов не приводит к умножению лежащих в основе коэффициентов, а свертка их.
В частности, есть такое
$$(a_0+a_1x+a_2x^2)(b_0+b_1x+b_2x^2) = a_0b_0+(a_0b_1+b_0a_1)x + (a_0b_2+a_1b_1+a_2b_0)x^2+(a_1b_2+a_2b_1) x^3+a_2b_2x ^4$$
В частности, никто не восстанавливает продукт $a_1b_1$.
Это можно исправить, (по существу) обратившись к версии преобразования Фурье, поскольку преобразование Фурье обычно можно записать как изоморфизм
$$\mathcal{F} : (R, +,\times)\to (R, +,\ast)$$
например он «меняет местами» свертки с (по коэффициенту) умножением.
Это означает, что если мы вместо этого закодируем сообщение в «каноническом вложении» (или, что то же самое, мы закодируем «преобразование Фурье» сообщения), то свертки станут поэлементным умножением (в нашем пространстве сообщений).
Однако я не верю, что первоначальная статья BFV делает это, что в зависимости от того, что вы читаете для спецификации BFV, может привести к путанице.
Но я считаю, что это относительно распространенная оптимизация, и ее можно рассматривать как «просто» другую кодировку сообщений (есть и другие преимущества использования канонического встраивания, так что вы захотите повторно проанализировать протокол с точки зрения этого).
