在选择诸如 等参数时plaintext_modulus，有什么好的策略吗？（除了猜测和检查，直到输出看起来正确）
特别是，我正在尝试IntegerEncoder使用 BFV。我（可能是错误的）理解是，plaintext_modulus不是被编码整数的模数，而是多项式表示中每个系数的模数。
当 B=2 时，这些系数看起来只是 0 或 1。但是，在应用了加法和乘法之类的操作之后，显然情况不再如此。有没有一种好的方法来确定系数的良好界限，以便挑选plaintext_modulus？
问问题
136 次
1 回答
1
我（可能是错误的）理解是 plaintext_modulus 不是被编码整数的模数，而是多项式表示中每个系数的模数。
这是使用时的正确思维方式IntegerEncoder。但是请注意，当使用BatchEncoder( PolyCRTBuilderin SEAL 2.*) 时，情况正好相反：明文向量中的每个槽都是一个整数模poly_modulus。
当 B=2 时，这些系数看起来只是 0 或 1。但是，在应用了加法和乘法之类的操作之后，显然情况不再如此。为了选择plaintext_modulus，有没有一种好方法可以确定系数的良好界限？
关键IntegerEncoder是新编码具有尽可能小的系数，延迟plain_modulus溢出并允许您使用更小的plain_modulus（意味着更小的噪声增长）。SEAL 2.* 有一个自动参数选择工具，它对噪声增长和明文系数增长执行启发式上限估计，并且基本上完全符合您的要求。不幸的是，这些估计是在每个操作的基础上执行的，导致早期操作中的高估在计算的后期阶段爆炸。因此，对于最简单的计算，估计并不是很严格，而且在许多情况下，该工具提供的参数过大。
为了估计乘法中的明文系数增长，让我们考虑两个多项式 p(x) 和 q(x)。显然，产品的度数正好等于 deg(p)+deg(q)——这部分很容易。如果 |P| 表示多项式 P 的无穷范数（最大系数的绝对值），则：
|p*q| <= min{deg(p)+1, deg(q)+1} * |p||q|。
实际上，SEAL 2.* 在这里更精确一些。它不使用度数，而是使用这些多项式中非零系数的数量。当多项式稀疏时，这会产生很大的不同，在这种情况下，交叉项的贡献要小得多，更好的界限是：
|p*q| <= min{#(non_zero_coeffs(p)), #(non_zero_coeffs(q))} * |p||q|。
Costache等人IntegerEncoder在https://eprint.iacr.org/2016/250中对类编码器中的系数增长进行了更深入的分析。，你可能想看看。
于 2018-10-26T19:01:02.330 回答