XPIR : Private Information Retrieval for Everyone论文阅读笔记

---

论文链接：https://www.sciendo.com/article/10.1515/popets-2016-0010.

嗅探（Sniffers）是一种网络流量数据分析的手段，常见于网络安全领域使用，也有用于业务分析领域，一般是指使用嗅探器对数据流的数据截获与分组分析（Packet analysis）。嗅探所使用的工具即为“嗅探工具”，正式的叫法为“数据包分析器”，还有别称为“嗅探器”、“抓包工具”。

摘要

       私有信息检索（PIR）方案是一种协议，其中用户从数据库检索记录，同时向数据库管理员隐藏记录。PIR可以使用相互信任的复制数据库、可信硬件或加密技术来实现。在本文中，我们将重点讨论后一种设置，即单数据库计算私有信息检索（cPIR）。经典的cPIR协议要求数据库服务器以非常低的速度对所有数据库内容执行算法，这会影响它们的使用。在[1]中，考虑到当时现实的某些假设，Sion和Carbunar表明cPIR方案不可行，而且很可能永远不会可行。时至今日，这一结论已被研究人员和从业者广泛接受。利用基于格的密码学引入的范式转换，我们证明了Sion和Carbunar的结论不再有效：cPIR具有实用价值。这是在不损害安全性的情况下实现的，使用标准crytosystems和保守的参数选择。

---

1 介绍

       同态加密在密码学史上走了一条奇怪的道路。自公钥密码术诞生之初，它就被视为一个圣杯，能够提供最不可思议和最强大的应用。然而，即使最近基于格的加密技术取得了突破，同态加密在实践中几乎从未使用过。在同态加密的潜在应用中，最古老、最具代表性的是单数据库计算私有信息检索。有了这样一个协议，用户可以从数据库中检索n个记录，而不必向数据库管理员透露是哪一个记录（安全性来自计算硬度假设）。获得这种隐私的一个简单方法是下载整个数据库，并忽略客户不感兴趣的元素。私有信息检索（PIR）方案旨在为用户提供与下载整个数据库相同的保密性（关于所请求元素的选择），同时具有次线性通信成本。PIR于1995年由Chor、Goldreich、Kushilevitz和苏丹引入[2]。他们提出了一套通过复制数据库实现PIR的方案，只要部分数据库副本不与用户串通，就可以为用户提供信息论安全性。但是，请注意，PIR方案不能确保数据库的机密性：用户可以使用PIR方案检索多个数据库元素，而数据库不知道它。确保用户在每个查询中检索单个数据库元素的PIR方案称为对称PIR（或SPIR）方案。从PIR到SPIR存在泛型转换，但这超出了本文的范围（见[3]）。在从数据库检索单比特元素时，评估了初始PIR方案的性能。从数据库检索多位元素时，会评估所有最新协议[4–6]。这种设置最初被称为私有块检索[2]，但现在这两个术语可以互换使用。保密协议（如[7]）的全有或全无公开只是多位SPIR协议。在本文中，我们主要研究不需要复制数据库的PIR方案，其安全性基于密码算法的计算安全性，通常称为单数据库计算私有信息检索（cPIR）方案。这将用计算安全性假设取代具有不共谋的副本的假设。然而，这是有代价的。

1.1 cPIR中的性能问题

       计算私有信息检索方案的一个主要问题是，它们的计算成本很高。为了回答查询，数据库必须处理其所有条目。如果协议不处理某些条目，数据库将了解到用户对它们不感兴趣。这将向数据库显示用户感兴趣的条目的部分信息，因此，它不像下载整个数据库并在本地检索所需条目那样私密。因此，响应cPIR查询的服务器的计算成本与数据库大小成线性关系。更准确地说，在[8]中，Lipmaa证明了使用一个特定的表示，这个下界是稍微次线性的（在$O(n/log(log(n)$中）。此外，大多数方案在数据库中的每比特成本非常高，这是对大模数的乘法。这限制了用户共享的数据库大小和吞吐量，从而限制了它们在许多数据库以及其他应用程序（如专用关键字搜索[9]）中的使用。在2007年的NDSS中，Sion和Carbunar发表了一篇关于cPIR实用性的论文[1]。他们表明，现有的基于数论的cPIR协议并不实用，发送整个数据库总是比计算cPIR回复更快。事实上，基于基础数论加密方案的安全性，很难将1024位RSA模作为系数，因此不能指望cPIR方案以每秒超过1兆比特的速度处理数据库。通过当前大多数互联网连接发送整个数据库至少快一个数量级（在局域网中通常快两个数量级）。他们还认为，只要计算能力和带宽演化的一般规律不变，这种性能差距就会继续存在。

       焦点问题,与[1]一样，我们讨论了cPIR的实际使用问题。我们使用的主要性能指标是客户端私下检索元素所需的时间，假设一个或多个客户端正在使用商品CPU查询服务器，并且可以以各种速度（xDSL、FTTH等）与服务器交换数据。我们认为，客户端准备支付一个显著的开销隐私，并比较所需的时间使用不同的方法（琐碎的完整数据库下载，基于数量的CPIR，基于格的CPIR）。

1.2 相关工作

       由于数论方法无法提供有效的cPIR方案，人们探索了一些替代方案[4-6]，但所有这些方案都基于非标准问题，并且都被打破了[10-14]。Aguilar等人[5]和Trostle及Parrish[6]的方案代表了高效私人信息检索的最新技术，允许在高端CPU上达到每秒数百兆比特的处理速度，在GPU上达到每秒1千兆比特的处理速度[15]。这些作品总共被引用了约80次，并已被用作主要和近期场馆的基本构件（或基准），如Usenix Security[16]（2011年）、NDSS[17,18]（2013年、2014年）和PETs[19–22]（2010年、2012年、2014年）。本文提出了一种潜在的替代方案，具有一些附加功能：安全性基于标准问题RingLWE[23]，具有保守的参数选择；平均CPU上的每秒处理吞吐量为千兆；以及一个自动优化器，以简化非专家的使用。该方案列表的一个值得注意的例外是Gasarch和Yerukhimovich[24]的cPIR方案，它依赖于基于格的标准加密方案[25]。然而，这种底层加密方案有一个非常大的扩展因子（大的密文只编码几位），这会影响cPIR方案的效率。

       cPIR的替代方案，不经意RAM（ORAM）协议用于私下访问（和写入）数据库，可以有效地处理很多TB的数据库。然而，ORAM和PIR协议用于不同的应用，不能互换。实际上，在ORAM设置中，数据库内容是用户外包的加密数据。ORAM不能直接用于从公共数据库（PIR的范例）私下下载元素，例如访问Netflix的电影数据库。在ORAM中，服务器中的数据是加密的，用户必须知道该密钥才能访问数据并隐藏其访问模式。使用PIR，不需要共享秘密，即每个用户都有一个独立的密钥，其目的只是隐藏自己的选择。因此，ORAM能够处理更大的数据库，但只能用于个人或组共享密钥设置（例如，用于云中的加密和共享文件系统）。可以使用硬件模块将ORAM协议转换为PIR协议（例如参见[26]）。当使用受信任的硬件模块是一个可接受的约束条件时，此类协议允许客户端发送表达性查询（可由模块解释），以定义要检索的元素，并且开销非常低。
       除了使用受信任的硬件模块，还可以使用复制数据库构建高效的PIR协议，如Chor、Goldreich、Kushilevitz和Sudan[27]以及Olumofin和Goldberg[28]所示。如果复制数据库而不与服务器串通是一个可接受的约束，那么这种协议允许以非常小的计算和通信开销私下检索数据。

       Devet和Goldberg[22]最近的一项有趣的工作是联合使用复制数据库PIR和cPIR来实现高性能结果，而不会在数据库合谋时损害安全性。本文要求复制数据库，因此与我们的设置非常不同。提议的协议使用Aguilar等人的cPIR方案[5]作为构建块，用我们的协议替换它将导致性能提升，并提供其构造的安全实例。

       仅考虑计算或通信成本的工程。在不经意传输设置[29]中，目标是在不考虑通信效率的情况下限制用户和数据库的计算成本。整个数据库连同一些额外的信息一起被加密发送到客户端，另外一个好处是服务器可以保证客户端每次查询只能检索一个元素的信息。

       一些cPIR协议只关注通信效率，而不考虑计算成本。在[30]中，从渐近的角度来看，基于完全同态方案建立了一个通信高效的cPIR协议。我们使用的底层加密方案只是[30]中的一个附加同态构建块，但我们的目标是让用户检索元素的速度比在现实环境中下载整个数据库的简单解决方案更快。这意味着要考虑计算和通信限制。

       在[31]中，给出了一个基于完全同态加密的方案的实现。该方案的贡献在于通信开销，在某些情况下（检索多个数据库元素时），通信开销非常小。虽然考虑了计算成本，但本文并未给出这方面的贡献，即数据库最多以20Kbits/s的速度处理，这低于基于数论的经典cPIR方案的处理吞吐量。如前所述，在大多数设置中，可以以更高的吞吐量发送整个数据库，从而可以更快地私下检索元素。

       最后，Kiayias等人在[32]中提出了一种新的基于数论同态加密方案的cPIR方案。通信性能非常有趣，但计算性能仍然是一个问题。将这些工作应用于基于格的加密方案将具有重大的实践和理论意义。

1.3 贡献和路线图

       首先也是最重要的是，本文表明，cPIR是一个在各种设置下都可用的原语，具有标准的安全性假设和保守的参数选择。第4节专门用来证明这一论断。这与Sion和Carbunar[1]的主要结果相矛盾，后者是关于cPIR可用性的参考。对Sion和Carbunar的分析仍然正确，但由于基于晶格的同态加密方案的出现，他们的一个主要假设（即cPIR将基于数论方案）不再需要成立。

       其次，我们提供了一个高效且可用的环LWE cPIR实现。从一个基本的角度来看，我们的贡献是证明应答生成所需的RingLWE操作从预处理中广泛受益，使用了充分已知的技术（类似快速傅立叶变换的表示）并引入了新的技术（牛顿商预计算）。从实用的角度来看，我们提供的实现在商品CPU上提供了数千兆位的处理吞吐量，以及一个自动调整系统（硬件\网络\应用\安全性）的优化器。

       在第2节中，我们介绍了读者应该熟悉的基本工具，以便理解本文的其余部分：同态加密，它允许计算过度加密的数据；获取私有信息检索协议的目标和经典方法；cPIR的一个特殊设置叫做私有关键字搜索，在这个设置中，我们不是像通常在cPIR中那样通过索引检索元素，而是根据元素关联的关键字检索元素。在第3节中，我们首先概述了我们的协议并描述了优化过程，然后介绍了我们基于快速环LWE的cPIR、提出的算法优化以及基本操作的性能结果：查询生成（加密）、数据库导入、回复生成和回复提取（解密）。在第4节中，我们将对我们的库进行更高级别的性能分析。本节的目的有两个：展示我们的库在各种环境下的行为，并证明在大多数情况下，cPIR比普通PIR更好，这与Sion和Carbunar[1]的主要结果相矛盾。论文的主体部分以结论结尾。

---

2 基础工具

2.1 同态加密

       加法同态加密方案由四种算法定义：生成密钥(KeyGen)；加密功能(Enc)；解密函数(Dec)；加法输入两个密文${\alpha }_1，{\alpha }_2$和相应的明文$d{b}_1，\cdot \cdot \cdot ，d{b}_n$，并输出一个密文$\alpha$和相应的明文$d{b}_1+\dots +d{b}_n$；以及吸收，其将一些数据$db$和一个密文$m$作为输入，并输出一个密文$m\ast db$。如果$m=0$，$db$被擦除，如果$m=1$，$db$被吸收。(and Absorb which takes as input some data $db$ and a ciphertext of $m$ and outputs a ciphertext of$ m ∗ db$. If $m=0$, $db$ is erased, and if $m=1$it is absorbed.这是最后一句话的原文，这个Absorb的翻译不是很理解，如果有更好的解释请在评论区留言或私信我，谢谢！)

       从安全性的角度来看，必须对选择的明文攻击实现不可区分性，这与同态加密方案可以实现的最高安全性相对应（参见[33]）。正如Goldwasser和Micali[34]所证明的那样，该属性为密文保密提供了强有力的保障。

       我们使用[30]中提出的基于环LWE的同态加密方案。为了证明我们的一些绩效结果，我们在下面对其进行了描述。如[30]中所述，我们给出了对称方案，然后解释了如何导出非对称方案。

注：$Z_q$表示模$q$的相对整数集。如果$S$是集合$x\leftarrow S$代表来自$S$的均匀样本，用于分布$\chi ，x\leftarrow \chi$代表遵循该分布的样本。$R_q=Z_q[X]/<X^N+1>$表示系数大于$Z_q$的多项式，这样在每次运算后，它们都会被除法模$X^N+1$约化。请注意，我们使用大写N表示多项式次数（这是一种不同寻常的表示法），以区分多项式次数与我们将在cPIR协议中处理的数据库中的元素数量。除非另有规定，否则所有标量运算都是$modq$。对于两个多项式$a，b\in R_q$，$a+b$是通过将它们的系数相加得到的多项式,$a\ast b$是通常的多项式乘法减去$mod(X_N+1)$，$a\otimes b$是将其系数按坐标相乘得到的多项式。

       SKE.ParamGen将安全参数k和最大添加数ha作为输入，并输出一组参数。出于性能原因，我们强制此函数的输出 N ∈ { 1024 、 2048 、 4096 } N∈ \left\{1024、2048、4096 \right\} N∈{1024、2048、4096}和$q$是60位或30位素数的倍数，因此每个素数与$1$模$2N$全等，以便能够使用NTT（参见第3.2.2节）。此函数按照[35]的方法生成参数 。

       该方案正是[28]中提出的公钥加密方案。如果标准格问题Ring-L WE是硬的（定理3和引理4，见[28]），它确保了对选择明文攻击的不可区分性。Ring-LWE的硬度是用于构建基于晶格的密码系统的主要假设之一，自其在Eurocrypt’10上发表以来，它可能已经成为最标准和最常用的一种。

       由于方案是随机的，密文必须大于明文。我们注意到$F>1$相关的扩展因子（密文位大小除以明文位大小）。作为参考，下面的图1给出了基于环LWE的加密方案的不同参数的一些明文和密文大小。

fig.1 我们的Ring-L WE加密方案的参数集。密文由两个多项式组成。第一个参数定义每个多项式的系数数，第二个参数定义每个系数的位数（存储在64位寄存器中）。从这些值可以很容易地推断出密文的大小。只有当密文中包含足够的噪声，并且噪声发生器与此安全性匹配时，才能达到最大的理论安全性。如果我们想做很多求和运算，明文大小会慢慢（对数）减小。同样，膨胀系数也非常接近其最佳值。 <\font>

2.2 隐私信息检索

cPIR协议的基本安全模型的属性是确保不可区分性（即语义安全性）。
定义1（cPIR协议）A （单数据库）计算隐私信息检索协议（Computationally-Private Information Retrieval Protocol ）是一种概率多项式时间（PPT）算法$\Gamma$，对于输入$k$，输出多项式时间随机算法$Q(\cdot ，\cdot )$(查询生成器）和两种多项式时间确定性算法$R(\cdot ，\cdot )$（回复生成器）和$X(\cdot ，\cdot )$（回复解码器）的描述，具有以下两个属性：（正确性）对于任意数量的元素$n$、索引$i$和数据库内容 { d b 1 ， … ， d b n } \left\{db_1，…，db_n\right\} {db1​，…，dbn​}，以及任意 ( q ， s ) ← Q ( i ， n ) ， X ( R ( Q ， { d b 1 ， … ， d b n } ) ， s ) (q，s)← Q(i，n)，X(R(Q，\left\{db_1，…，db_n\right\})，s) (q，s)←Q(i，n)，X(R(Q，{db1​，…，dbn​})，s)输出$d{b}_i$。（隐私）对于任何正整数$n>i_1>i_2$，任何多项式时间$A$，在$k,ϵ$中存在一个可忽略函数（即渐近小于任何逆多项式），例如，$Pr(A(\alpha ，i_1，i_2，P_{p}ir)=i|Q\leftarrow \Gamma [k]；(\alpha ，s)\leftarrow Q(i，n))<1/2+ϵ(k)$ $i$在 { i 1 ， i 2 } \left\{i1，i2 \right\} {i1，i2}中随机选择，$P_{pir}$是关于PIR协议的所有公共信息的集合。

       在本文中，我们使用一个简单的cPIR协议，其基本思想是[27]中的一个，使用[7]中多位数据库元素的性能改进（但不考虑[7]中提出的确保对称隐私的零知识证明），如下所述。它可以与任何附加同态加密方案一起使用。该协议可正式描述如下：

       安全性是通过一个不可区分的游戏来定义的：实际上，攻击者无法区分对任意两个数据库元素的查询。当用于cPIR协议时，针对明文攻击的不可区分加密方案使用标准的混合参数（有关正式定义和证明，请参见[7]），确保对数据库中两个不同元素的两个查询不可区分。

       使用这种简单的方法，查询大小是密文大小的$n$倍，回复大约是$l\times F$，$F$是所用加密方案的扩展因子。为了减少查询大小，可以按大小为$\alpha$的组对它们进行聚合，并获得一个包含大小为$l\times \alpha$的 $[n/\alpha ]$元素的数据库。也可以递归使用该协议。由于空间限制，该算法的递归版本见附录。在实践中，递归将一个名为$dimension$的整数$d$作为参数，并产生一个方案，在该方案中，客户端只需要发送$d\times n^{1/d}$查询元素（密文），并且回复的大小（大致）为$F^d\times l$。例如，如果$F=2$，并且我们有一个包含一百万个元素的数据库，那么可以：发送一个106个密文的查询，并获得扩展因子为2的数据库元素（$d=1$，无递归）；发送一个$2\times 1000$密文的查询，得到扩展因子为$4(d=2)$的数据库元素；发送一个$3\times 100$密文的查询，得到扩展因子为$8(d=3)$的数据库元素等

       读者可以参考[7]对这些技术进行更详细的描述，以及正确性的证明。可以对数据库的拆分方式做出不同的选择，并更改每个级别上使用的加密参数，以提高递归的性能。对于这个过程的完整描述、概括和优化，读者可以参考[36]，其中提出了许多有趣的变体。在我们的库中，我们决定坚持递归的基本方法，尽管开发其他优化（如[32,36]中提出的优化）会很有趣。

2.3 隐私检索

       私有关键字搜索[37]的基本思想是，数据库可以通过使用关键字对元素进行分组来排列元素。通过这种技术，用户可以使用cPIR协议获得与给定关键字匹配的所有数据库元素。在这种情况下，查询大小与可能的关键字D（字典大小）的数量成正比，服务器的计算成本可能会发生变化，因为与多个关键字关联的数据库条目将在每个关键字前面复制一次。因此，计算成本将是数据库大小乘以数据库元素匹配的关键字的平均数量。

       也可以使用它根据专用标准过滤流数据[38]。其想法是为每个消息传递建立基于短暂关键字的数据库。这些数据库到处都有空元素，除了传递的消息匹配的关键字前面。因此，处理数据包的计算成本是它的大小乘以它匹配的关键字数（空元素不需要处理）。使用这种方法，可以构建一个过滤器，当消息与关键字不匹配时，为每个传递的消息输出零加密，当消息与关键字不匹配时，输出消息加密。

       在第4节中，我们使用这种方法在千兆链路上构建一个嗅探器，它只对与给定IP地址对应的消息感兴趣。在此嗅探器中，流式消息是网络上的数据包，关键字是局域网中使用的一组IP地址，数据包与对应于其源地址和目标地址的IP关键字相匹配。嗅探器的代码包括一个选择正在观察的IP的cPIR查询，因此即使分析嗅探器的代码，也不可能知道哪个是IP地址，因为所选的关键字隐藏在cPIR查询中。重要提示：处理输入后，过滤器始终输出密文，无法区分有用的输出和零加密。如果我们存储所有这些结果，我们不会比一个基于PIR的简单等价物（它将存储所有未加密的输入数据）更好。使用cPIR的主要兴趣在于，可以压缩输出，以便压缩零加密，并保留有用的输出，即使不知道哪些输出有用。这些技术超出了本文的范围（关于这一主题的最新建议，请参见[39]），但与只存储关键字匹配数据的未加密过滤器相比，高效过滤器的开销很小。

---

3 Proposed protocol（不知道如何翻译）

3.1 概述和自动优化

       下文概述了拟议的协议。如果服务器强制执行一组给定的PIR参数（聚合和递归深度）和加密参数，我们就说我们处于服务器驱动模式。在这种情况下，只执行协议的步骤1（服务器驱动模式下的条件跳转）、4（元素选择）和5（检索）。相反，如果我们处于客户机驱动模式，客户机将进行优化，以确定给定设置和输入约束的最佳参数（步骤2-3），并使用它们（步骤4-5）。默认情况下，我们假设已经找到了最佳参数，并且我们处于服务器驱动模式。

       本协议中运行的算法具有自解释的名称，但为了完整性，附录中对其进行了非正式描述。

       在XPIR中有一组预定义的加密方案：无加密（带完整数据库下载的简单PIR）、Paillier[40]和Ring LWE（见第2.1节）。每个加密方案都有一个预定义的安全参数列表，从80位到256位不等（遵循NIST关于Paillier基于因式分解的加密和[35]关于基于格的方案的建议）。

       默认情况下，优化的目标函数是检索的往返时间，使用自解释变量名，由函数$max（queryGenerationTime，querysendingtime）+max（replyGenerationTime，replysendingTime，replydencryptionTime）$给出。这是因为查询生成和发送是管道化的，然后服务器等待，直到完成查询和回复生成，发送和解密是管道化的。我们已经预先定义了一些其他目标函数，比如最小资源（取所有值之和）和一个称为云成本（cloud cost）的加权等价物（它为每个CPU毫秒提供一个美元值，为每个传输的位提供一个美元值，并给出操作成本）。可以在命令行上选择目标函数。

3.2 Fast Ring-L WE based cPIR

       我们对性能的贡献集中在两点：高效的NTT-CRT（见第3.2.1节）表示和相关转换；以及对查询元素使用牛顿商（见第3.2.2节）。

       其思想是，查询生成、回复生成和回复提取中的大部分计算开销来自多项式乘法。例如，对于应答生成，计算成本主要集中在第2.2节中描述的基本cPIR协议的吸收阶段。通过我们的RingLWE方案，这个阶段可以写如下。

       对于从$1$到$ceil（l/l_0)$的$j$，计算$R_j=({\sum }_{i=1}^{n}d{b}_{i,j}\ast q_{i,1},{\sum }_{i=1}^{n}d{b}_{i,j}\ast q_{i,2})$，注意$q_{i,1},q_{i,2}$两个构成查询元素的多项式，以及$R_q$中的所有累加以及乘积（多项式减去模$X^n+1$和系数模$q$）。

       在NTT-CRT表示法中，将两个多项式相乘的计算量从$O(n^2\times lo{g}^{2}q)$传递到$O(n\times logq)$。这种表示法并不新鲜，我们的贡献在于性能，因为获得NTT-CRT表示法所需的时间除以因数10，计算该表示法中多项式乘积所需的时间除以因数2到3。

       我们不知道在基于格的密码学中使用预先计算的牛顿系数。其思想是，当两个多项式相乘时，相关的标量积必须减少$modq$，这大大增加了这些基本运算的计算成本。在回复生成算法中，产品的形式总是“将一些数据转换为多项式”乘以“查询元素”。因此，查询元素用于许多乘法运算。对于重复使用的乘法（如查询标量），预先计算的牛顿商允许使用两个整数乘法和一个条件减法（从而消除了代价高昂的除法），用特定的模乘算法取代通常的“乘除模”。

3.2.1 The NTT-CRT representation and transforms

       在XPIR中，我们使用混合NTT-CRT表示法来降低计算成本：多项式的数论变换（NTT）[41]和整数的中国余数定理（CRT）。我们将XPIR的一部分称为NTTOOLS，它允许在这个表示上应用转换和高效计算。Halevi和Shoup[42]的同态加密库实现了Brakerski、Gentry和Vaikuntanathan[43]的加密方案。他们提供了一个称为双CRT的对象，该对象提供NTT和多项式的CRT表示，就像NTTTools一样。我们将在本节中与这项工作进行比较。

       使用NTT和CRT来加速多项式乘法并不是什么新鲜事，本文将不再详细介绍，我们将只关注它们的使用带来的影响。例如，读者可参考[42]。使用NTT表示法可以计算多项式乘法，其线性代价为N，而不是普通算法的二次。将多项式转换为NTT形式并返回可以以准线性速度$(O(Nlog(N)))$完成。CRT表示法确保乘法代价在$log(p)$中也是线性的，而不是普通算法的二次。将一个整数转换为CRT表示并返回，在$log(p)$中有一个二次代价。

       图2说明了预处理性能（对应于将数据导入NTT-CRT形式多项式）和处理性能（对应于融合乘法和加法（FMA）操作）。数据分割和CRT（如果完成）操作非常快，预处理中的主要性能瓶颈是计算多项式环中的NTT。测试对应于第4节中使用的同一台笔记本电脑，使用其所有多线程内核。

fig.2 对于不同的加密参数，MSI GT60笔记本电脑上的PIR预处理、处理时间和吞吐量，核心为i7-3630QM 2.67GHz。输入大小是图1中给出的最大纯文本大小。多项式的预处理对应于NTT和CRT变换，这是数据库导入期间的主要操作。逆变换给出了类似的结果。处理对应于一个融合的乘法和加法（FMA），这是应答生成过程中的主要操作。此操作的吞吐量将因内存饱和而发生很大变化：在此设置中，如果每个操作的所有操作数和结果都发生变化，则相对于给定值，处理时间将乘以3。在这里，我们使用了与PIR方案相同的内存传输：对于给定的线程，大多数时候只有一个操作数是变化的。根据输入数据给出吞吐量：在每个多项式（输入大小）的预处理中，处理位；在处理过程中，必须处理两个多项式来处理（输入大小）位。

       对cPIR效果的影响这些值会影响cPIR回复的生成。预处理对应于数据库元素导入和回复生成处理。启动服务器时，数据库元素可以以大约5Gbits/s的速度以NTT-CRT形式导入RAM，在应答生成阶段，数据库的处理速度约为20Gbits/s。如果数据很快就过时（例如IPTV流），主要的瓶颈是将数据转换成NTT-CRT格式，而导入阶段的处理速度约为5Gbits/s。出于比较目的，使用基于配对的cPIR，同一台计算机能够以1Mbit/s的速度处理数据库（2048位的模数提供112位的安全性）。同样，出于比较目的，在普通PIR（即完整数据库下载）中，处理一个位对应于将其发送到客户端，因此数据库以可用下载吞吐量（例如100Mbit/s FTTH线）进行处理。因此，普通PIR通常比基于Paillier的cPIR更快，但比我们的Ring-L WE实现更慢。

       与[42]的比较[42]中提出的双CRT对象比NTTTools复杂得多，具有完全同态加密所需的许多补充函数，并且与多项式次数一样更灵活。另一方面，我们简单的设置允许一些有趣的选择。首先，我们使用Harvey的NTT算法[44]，该算法非常快，但要求多项式度数为二的幂。可能构成模块的素数是静态定义的，支持各种编译时优化。双CRT是在NTL上构建的，而NTL又是在GMP上构建的，而我们构建的库没有使用任何外部库，这导致了性能的大幅提高。

       HElib假设用户定义了他需要做的同态计算，然后一个例程为他定义了一个完整的上下文。尤其是用户不能选择只使用一个或两个素数，因此我们必须调整代码以进行类似的测试。

       如图3所示，使用NTTTools可以显著提高多项式乘法的性能（在x2和x3之间）。对于预计算，间隙更大（x10）。这样做的原因是我们选择将多项式次数限制为二的幂，这就开启了nice算法的使用，比如[44]中的算法。

fig 3 使用双CRT和NTT工具进行预处理（NTT和CRT）和处理（乘法和加法）次数。在双CRT中，模数大小必须是44的倍数（这允许他们进行双精度浮点运算以减少模数）。我们选择的模尺寸尽可能接近。测试是在一台MSI GT60笔记本电脑的单核（因为双CRT显示openmp存在分段故障）上进行的，该笔记本电脑的核心是i7-3630QM 2.67GHz。NTTTools（x10）的预处理速度快得多，这主要是由于Harvey的NTT算法（这是可用的，因为我们将自己的多项式次数限制为二次幂）。在加工过程中，差距较小（x2和x3之间），但NTTOOLS的性能仍然更好。

       最后，NTTTools的内存使用率要低得多，这并不奇怪，因为我们所处的环境更简单。对于1024次和60位系数的多项式，NTTTools中的内存占用默认为8KB，是预先计算商的两倍。由于某些数据（如FHE上下文）是共享的，使用双CRT很难评估内存占用，但对于大量双CRT对象，内存使用量以每对象40KB的速度线性增加。

       因此，对于那些在理想设置或简单同态运算上寻求快速基本多项式计算的人来说，NTTTools和我们在此基础上开发的方案将成为双CRT的有趣替代品。那些寻求更高级操作的人应该使用双CRT。

fig 4 不同参数的乘法时间（见图3），在MSI GT60笔记本电脑的单核上，以秒为单位，内核为i7-3630QM 2.67GHz。请注意，双CRT在没有商预计算的情况下具有更好的性能。这是因为选择了44位模，允许基于浮点和舍入的模乘。通过商预计算，我们可以使用NTTTools获得x2到x3更好的性能。如果没有商，预计算性能将非常糟糕，因为我们不能像DoubleCRT对44位模那样使用浮点运算，但在我们的协议中，我们总是设法拥有这样的商。

3.2.2 Pre-computing Newton Coefficients（牛顿系数的预计算 ）

       XPIR中的基本标量运算是以60位整数为模完成的。要将两个60位整数与给定的$p$相乘，一个选项是使用$64\times 64$到$128$位的乘法（这不是通常64位指令中的基本运算，但成本合理），然后检索除法的剩余部分。由于乘积在$128$位变量中，这种整数除法的成本非常高。在[44]中，David Harvey认为当同一个乘法器被多次使用时，Shoup是一种非常有趣的模乘方法。

        其思想是为多次使用的特定操作数预先计算牛顿商。因此，我们为给定的$y$计算$y/p$的缩放近似值。这是在我们的设置中通过将$y$放入一个$128$位变量中，将其乘以$264$（使用移位运算符<<）并将代价高昂的整数除以$p$来完成的。这将给我们$y_0$，$y/p$的前$64$位（乘以$264$）。其思想是，乘法（整数除法）中代价高昂的运算预先计算一次，然后，当我们需要进行乘法$xy(mod(p))$时，我们将使用一种特殊算法，将$x，y，y_0$作为输入，从而以较小的代价得到结果。算法非常简单。

1. $q=x{y}^{{}^{\prime }}/2^{64}$
2. $r=xy-qp$ mod $2^{64}$
3. $ifr>p:r=r-p$

        这种算法只需要两个整数乘法，一个移位和一个条件减法，与通常需要的整数除法相比，这是非常快的。当然，如果只使用$y$一次，则没有增益，因为在普通算法中多进行一次整数乘法，并且在预计算期间进行整数除法。然而，如果在许多乘法中使用$y$，则加速比相当大。正确性在[44]中得到了证明。

        NTTTools提供函数来预先计算多项式算法所需的数据。当此类数据可用时，多项式乘法以$2n$（正常）整数乘法而不是$n$模乘法进行。当然，应用程序的性能取决于使用相同操作数的频率。我们在NTTTools上构建的加密方案只需要进行两次多项式乘法加密，一次多项式乘法解密，始终使用相同的乘法器：密钥和公钥。在cPIR协议中，应答是通过不断将数据库元素块与查询元素相乘来生成的。在大多数设置中，每个查询元素都会被不同的块乘以很多次。密钥和查询都使用预计算机制。在实践中，我们的代码中没有一个乘法不经过这个过程，几乎在每种情况下，预计算都要摊销几十倍或数百倍。

3.2.3 加解密性能

        请注意，从安全角度来看，我们在本节中提出的修改所产生的同态加密方案相当于第2.1节中描述的方案，因为所有修改对于攻击者来说都是公开和可逆的。

        其基本思想是，通过将通常描述输入（密钥、随机性、消息）的多项式转换为NTT-CRT表示，对其进行预处理。通过这种转换，可以通过协调乘法和加法来完成加密和解密操作，从而获得非常高的性能结果。

        描述每种算法是如何通过使用NTT-CRT表示法进行转换的，没有什么意义，也非常简单。只有两点很重要。首先，每次加密方案算法中都有一个统一的多项式，我们不需要改变表示形式。实际上，NTT、CRT和逆NTT、逆CRT是一对一的函数，它们将有限空间映射到自身，因此是其域的置换。因此，采用统一元素并将表示形式更改为NTT-CRT与仅采用统一元素完全相同。第二，每次有一个乘积需要计算时，这两个项中的一项是长寿命的（秘密密钥、公钥或常数）。因此，总是可以使用预先计算的牛顿商进行快速模乘。

        考虑到这两个概念，很容易看出加密只需要计算三个NTTCRT转换和一些基本操作。这是特别正确的，因为我们所做的所有算术运算都是基于坐标的，并且使用CRT表示，允许通过基本指令集处理数字。对于解密来说，情况并非如此。乍一看，解密中成本最高的操作将是反向NTT。是的，如果我们使用60位的模，但不是更大的模。事实上，需要注意的是，除了在解密函数中分离噪声和消息之外，所有算术运算都使用基本指令集。如果我们使用多个模，为了分离噪声和信息，我们需要得到非CRT表示中每个坐标的值（在CRT表示中没有简单的欧氏除法）。这是通过将CRT元组的元素乘以我们所说的提升系数来实现的。此操作在不减少模的情况下完成，并且需要对数2 q位元素进行几次乘法。对于这个操作，我们需要使用多精度库。实际上，一旦我们开始使用这样的库，解密成本就会乘以系数10。图5显示了这种演变。

fig.5在核心为i7-3630QM 2.67GHz的MSI GT60笔记本电脑上，多项式次数4096和可变模数大小的加密和解密时间。请注意，加密成本在模数大小以及相关密文和明文的大小上呈线性增加。解密成本的大幅增长来自严格高于60位的模使用GMP。

        这是我们在我们反对的NTTL上使用GMP的唯一一点（通过使用NTTTools的poly2mpz函数）。实际上，这会导致非常显著的性能下降。然而，请注意，对于60位的模，性能出人意料地高。我们能够以700Mbits/s的速度生成查询，并以5Gbits/s的速度解密传入的回复。这与多项式次数无关，因为加密和解密的成本在其中呈线性增加，但密文和明文的大小也是如此。实际上，笔记本电脑可以在所有设置下使用单个内核以最大可用带宽发送查询、接收和解密。由于模数为120位，加密可以以850Mbits/s的速度生成查询，但解密会受到CRT提升的影响，回复“只能”以710Mbits/s的速度解密。

        实际上，对于非常大的模（例如480位），或者如果我们使用特殊设置，例如通过千兆线路连接，解密只是瓶颈。然而，由于查询大小的原因，优化器通常会选择小模块（最多120位）。事实上，对于超过120位的模，查询大小的增加（必须在有限的带宽线上发送）会给往返时间（或所花费的总资源）增加比回复扩展因子或cPIR回复生成吞吐量更多的时间。

4 性能和用例

        在本节中，我们使用两个指标分析XPIR的性能：延迟和用户感知吞吐量。延迟度量是从客户机开始生成cPIR查询到完成解密回复的往返时间。用户感知吞吐量是指解密后用户能够获得请求元素的吞吐量（以比特/秒为单位）。

        我们将考虑数据库的两种设置：静态数据库，其中可以对数据库元素进行预处理；以及内容短暂（电视流、传感器数据等）且无法提前预处理的动态数据库。如第3.2.1节所示，预处理以5Gbps（对于高端笔记本电脑）到10Gbps（对于高端服务器）的速度为每个元件独立执行。因此，如果某个元素的使用寿命远大于其转换时间（例如，对于10Gbit电影为1-2秒），并且该元素在第一个cPIR事务中将被使用，那么该数据库被认为是静态的。

        用例：为了说明我们的库的多功能性，我们通过结合动态/静态设置和吞吐量/延迟目标的四个用例来强调性能值。对于高吞吐量应用程序，我们使用一个类似Netflix的服务器（相对静态的数据）和一个嗅探器，嗅探器融合他感兴趣的内容（动态数据）。对于低延迟应用程序，我们使用匹配。类似com的在线约会数据库服务器（相对静态数据）和股市信息服务（动态数据）。请注意，为快速cPIR协议寻找最佳应用超出了本文的范围。 选择所展示的用例是因为它们为cPIR提供了压力设置，而不是因为cPIR是在这些设置中解决隐私问题的唯一或最佳选择。我们的目标是证明cPIR优于普通PIR，并且在对客户端获得的吞吐量有很大限制的大型数据库中使用它是可行的。

4.1 实验环境

        为了证明我们的库对许多应用程序都是可用的，我们在几乎所有的设置中都使用了商品硬件。我们的cPIR服务器运行在一台MSI GT60笔记本电脑上，其核心是i7-3630QM 2.67GHz（移动设备），以及8GB的DDR3 RAM。由于我们的库能够非常快速地处理数据库内容，因此数据存储介质会极大地影响性能，尤其是在预处理这些数据的情况下。在我们的评估中，我们使用了两种介质：RAM（100Gbit/s访问）或OCZ Vertex 460 SSD（4Gbit/s访问）。SSD的连续读取速度足以为服务器提供所有动态数据设置。如果数据是静态的，我们能够以比普通SSD磁盘更快的速度处理数据。如果数据库在RAM中，这当然不是问题，但在某些应用程序中，例如Netflix之类的服务器，数据库很大，不适合RAM。我们将在相关章节中讨论这个问题。FTTH和ADSL线路是通过在客户端和服务器中引入适当的等待定时器来模拟的，实际上，这两个服务器通过千兆线路连接。

        安全性：在我们的大多数性能结果中，优化器发现，我们的Ring-L方案的最佳参数是（2048,120）或（1024,60）。根据第2.1节中介绍的参数生成，前一组参数能够提供91位的安全性，后一组参数能够提供97位的安全性。为了为我们的方案生成随机性，我们使用Salsa20/20[45]（Salsa20/20能够提供多达256位的安全性），因此，即使Ring-L的一组参数在理论上能够提供更多的安全性，256也是一个上限（这是通常考虑的标准最大安全性）。

        在基于格的加密技术中，安全性可以非常好地扩展。对于常数模，安全性（在攻击者操作中）随多项式次数呈指数增加，计算成本仅（几乎）线性增加。例如，如果我们使用参数（4096，120）（而不是（2048，120）），理论安全性可以达到335位。同样，在我们的实现中，安全性限制为256位。在这种高安全性设置中，查询生成、回复预计算、回复生成和回复解密的成本仅增加了2倍（更准确地说，预计算为2.18，其余为2）。有了这些参数，每个密文可以包含更多的数据（几乎两次），因此安全性的提高成本很低。我们将在第一个图中显示高安全性（4096，120）参数集的成本，然后让优化器选择最佳参数，最低安全性设置为91位，以便能够使用（2048，120）参数，这些参数是密文大小、回复生成吞吐量和安全性之间的良好折衷。Paillier本节中给出的结果对应于具有Ring-L WE和平凡PIR的cPIR（以显示cPIR对完整数据库下载的兴趣）。使用Paillier的性能总是较差，因此不会出现在不同的图形上。

4.2 在静态数据库上的高吞吐量

        高吞吐量的应用（即需要高用户感知的接收吞吐量的应用）只有在数据库元素足够大的情况下才有意义，如果它们非常小并且被快速发送，我们认为基本问题是在第4.4节中将要研究的等待时间。因此，我们只考虑从10MbT和UP到文件的数据库。我们的实验结果表明，当文件大小在该范围内时，用户感知的吞吐量与文件大小无关，因此，此图中的行适用于任何大于或等于10Mbit的文件大小。

fig 6 用户在MSI GT60笔记本电脑上感知的XPIR流式静态数据吞吐量，其核心为i7-3630QM 2.67GHz。100Mbits/s FTTH线（粗黑线）上的微小PIR比cPIR慢10到200倍。红色填充线（91位安全性）和绿色虚线（256位安全性）在不进行递归时提供吞吐量（即数据库作为一维数组处理），蓝色虚线具有一个递归级别（即数据库作为二维数组处理）。水平线对应于以1024p（2Mbps）、720p 60Hz（800Kbps）和720p 30Hz（400Kbps）观看电影或收听128Kbps音频文件所需的吞吐量。当RAM带宽饱和时，使用更好处理器（例如十核Xeon E7-4870）的服务器上的性能大约是该级别的两倍并达到上限。

        图6显示了在实验设置的笔记本电脑上使用我们的库获得的用户感知吞吐量。红线显示未执行递归时的性能（即当查询大小与n成正比时）。这条线是使用吞吐量的最佳参数（由优化器给出）获得的：无递归、无聚合，以及带参数的环L WE加密（2048,120）。有了这些参数，密文大小（以及查询元素大小）为500位，加密的扩展因子为F’5。因此，为了以用户感知的2Mbits/s吞吐量获得一个元素，实际上将使用10Mbits/s的带宽。从吞吐量的角度来看，这个设置是最有利的，但是当元素数n增加时，查询大小可能会成为一个问题，如图7所示。请注意，这条线非常接近由15/n Gbps定义的直线（更准确地说，对于较大的n值，值从$19/n$ Gbps缓慢漂移到$14/n$ Gbps）。

fig 7 用户开始接收流式数据之前的初始延迟（主要是由于查询生成和到服务器的传输时间）。轻微的PIR没有初始延迟。细线用于ADSL，粗线用于FTTH。颜色和线条样式与图6中相同的设置相关联。结果显示，延迟在维度1中的$n$和维度2中的$\sqrt{n}$呈线性增长，主要的瓶颈是可用的上传带宽。

        在更高的安全性设置（256位安全性）中，绿线显示与红线相同的结果。如前所述，这对处理几乎没有影响，但会将每个密文的大小和查询大小增加一倍（如图7所示）。请注意，刻度是对数的，因此，即使与红线的差异非常小，在该设置中，性能也会差大约10%。

        蓝线显示了一个递归级别的性能（即，当数据库被视为二维数据库时）$\sqrt{n}\times \sqrt{n}$数组和查询大小与2成正比$\sqrt{n}$） 。对于小型数据库来说，递归会导致巨大的计算开销，因为第一次处理数据库会产生大小为F$\sqrt{n}$的中间数据库， 在得到最终答复之前，我们必须再次进行处理。在我们的实现中，处理这个数据库的成本大约是通常成本的十倍。如果$\sqrt{n}$>>这个中间数据库上的10F计算可以忽略不计，因为它相对于初始数据库来说足够小。实际上，该图显示，递归级别的开销随着n的增长而逐渐消失。

        初始延迟：即使获得最佳用户感知吞吐量是应用程序的目标，一个重要参数是用户在开始接收请求流之前必须等待的时间。图7强调了对包含许多元素的数据库使用递归级别的好处。当n≥ 1000，正如我们所看到的，这意味着在这种情况下几乎没有计算开销。在FTTH线路上，延迟将低于10秒（如果我们使用d=2表示n）≥ 1000). ADSL线路的上传带宽有限，因此延迟范围为5到500秒。因此，在这种情况下，一定要使用一级递归，即使这意味着应答生成的开销很大。对于少量元素，FTTH线路的奇怪行为来自这样一个事实：我们使用TCP套接字来传输查询，对于非常小的时间值，缓冲和窗口设置会造成阻碍。如果需要，可以调整低级别套接字或使用UDP来实现更线性的行为。

        **Netflix用例：**Netflix电影数据库由10万部电影组成（根据Netflix的维基百科页面，更准确地说是在2009年组成），这些电影存储为静态文件，因此可以进行预处理以提高性能。H.265高效视频编码（HEVC）是即将推出的视频流压缩标准[46,47]。使用该编解码器获得的压缩级别能够以400Kb/s（30fps）和800Kb/s（60fps）之间的比特率观看720p流，以2Mb/s的比特率观看1024p流。对于高质量的MP3，音频流的典型比特率为128Kbps。这些级别（128400kbps、800Kbps和2Mb/s在图6中用水平线表示）。请注意，我们使用这个用例作为一个简单的例子。对于有兴趣深入研究类似Netflix的私有应用程序的读者，请参考[48]。

        根据图6的结果，基于XPIR的类似Netflix的服务器允许用户私下接收流媒体电影，在隐私和质量之间进行不同的权衡。如果用户愿意接收720p-30fps的视频流，他可以从服务器上隐藏他在35K电影中的选择。当然，也可以在计算上进行权衡，使用8K电影和720p-30fps时，服务器的CPU占用了8%，因此每个处理器可以处理12个用户。介质访问问题：使用高达10GB的数据库获得实验结果非常简单，因为它们适合RAM。为了在最大的数据库中获得性能结果，我们将它们分为适合RAM的大数据块进行处理，消除了每个数据块的磁盘传输时间。如果我们使用SSD磁盘访问数据，并考虑传输时间，磁盘访问是瓶颈，因此我们获得了$2/n$ Gbps的性能结果（我们的磁盘允许4 Gbps访问，预计算的数据是初始数据的两倍）。在所描述的用例中，这意味着对于给定的分辨率，隐藏选项的电影的最大数量将减少七倍。我们认为，在需要大型数据库和吞吐量的应用程序中，例如Netflix用例，提供者具有高性能磁盘。为了匹配我们库的计算性能，可以在RAID 0中使用例如两个OCZ Vertex RevoDrive PCIe SSD，它提供30Gbps的读取吞吐量，成本大约为1000美元。
多用户：请注意，如果并发用户同步访问数据，磁盘访问成本不会增加，因此可扩展性不是问题。因此，例如，如果12个用户在质量为720p-30fps的8K电影中隐藏他们的选择，服务器可以仅以其处理速度15的8%访问数据库∗ 8/100=1.2Gbits/s，所以一个普通硬盘就足够了。有关私有Netflix用例、相关CPU和I/O性能权衡的优秀分析，请参见[48]。在结论中，我们也进一步讨论了这一点。

4.3 在动态数据库上的高吞吐量

        乍一看，动态数据库与静态数据库相似，只是数据不能离线预处理，例如IPTV。然而，它们可以具有大范围的形状和内容，并且并不总是静态数据库对“无限大小”文件的简单扩展。对动态数据库的详尽分析超出了本文的范围，但我们展示了两种不同的设置：IPTV和专用嗅探器。

        第一个设置非常简单：无法预处理的常规数据流，例如IPTV。图8显示了与图6相同的结果，但带有动态数据。可以看出，用户感知的吞吐量大致除以6。对于类似IPTV的应用程序，单个处理器可以为50个同时客户端（例如经典电视）处理100个720p-30fps流，或为单个客户端（例如一组大型远程IP网络摄像头）处理5000个此类流。第二个设置更复杂，因为动态数据元素大部分时间为空，而非空值可能非常小。我们在第二个用例中描述了这个设置。

fig 8 用户在MSI GT60笔记本电脑上感知的XPIR流式动态数据吞吐量，其核心为i7-3630QM 2.67GHz。100Mbits/s FTTH连接（粗黑线）上的普通PIR比cPIR慢五到五十倍。红线表示未进行递归时的吞吐量（即数据库作为一维数组处理），蓝线表示一级递归（即数据库作为二维数组处理）。水平线对应于以1024p（2Mbps）、720p-60fps（800Kbps）和720p-30fps（400Kbps）观看电影或收听128Kbps音频文件所需的吞吐量。在具有更好处理器（例如十核Xeon E7-4870）的服务器上，性能可以提高两到三倍。

        私有嗅探器用例：在这个用例中，我们假设有人创建了一个嗅探器来存储具有给定源IP地址的所有数据包，但希望</br>确保没有人能够找到嗅探器并分析其代码，从而了解嗅探器感兴趣的IP。当然，可以存储每一条消息（与普通的PIR一样），但是，如第2.3节所述，使用cPIR存储要紧凑得多。

        使用这种方法，将生成一个cPIR查询，并将每个查询元素与给定的源IP相关联。我们可以问的第一个问题是：IP范围有多大？假设我们使用（1024，60）个参数或（2048120）个参数进行环L加密。前一种情况下，每个查询元素的长度为128Kbit，后一种情况下为512Kbit。如果我们的目标是覆盖B类网络范围（65535个地址），那么前者的查询大小将为1G字节，后者为4G字节。1需要注意的是，此查询大小不是必须定期发送的，对于大多数嗅探器来说，它将定义其行为方式（它是嗅探程序的加密部分），并用于在检索之前将大量结果存储在本地硬盘中（当然，结果也可以通过网络发送）。这个大小也不会影响性能，因为我们关于处理吞吐量的结果已被证明与查询的元素数量无关，只要它适合RAM，我们假设这是真的。

        对于嗅探器截获的每个数据包，他都会构建一个数据库，这样每个查询元素都与一个空元素相关联，但与截获数据包的源IP对应的查询元素与该数据包相关联。然后，嗅探器使用第2.3节中描述的压缩技术生成一个cPIR应答，将应答存储在磁盘中。因此，动态数据库非常特殊，因为它几乎为空，要处理的元素通常比密文中可以吸收的元素小得多（320位到12Kbits之间）（较小的参数大约为20Kbits，较大的参数大约为90Kbits）。因此，一个微不足道的实现不会使用我们的库在其他设置中可以提供的所有功能。

fig 9 在核心为i7-3630QM 2.67GHz的MSI GT60笔记本电脑上使用XPIR的嗅探器用例的数据包处理吞吐量。在这种情况下，微不足道的PIR性能没有意义。红线单独测量每个数据包大小的性能，以x轴上的字节为单位（即，仅测量处理40字节数据包的性能，然后测量80字节数据包的性能等）。绿线给出了流量遵循经典双峰分布时的处理吞吐量，如[49]中所示。紫色线给出了忽略小于60字节（基本上是ACK）的数据包的流量。如果我们等待流量填满缓冲区，并且只有在收集到足够的信息来填充密文时才生成cPIR回复，那么蓝线会提供性能。

        图9中的红线给出了嗅探器处理截获数据包的吞吐量。由于数据包比经典的明文大小小得多，我们选择了尽可能最小的密码参数，即（1024，60）。我们认为，在吸收之后，密文可以经历多达一千个和（对于诸如布隆过滤器上的插入等操作）。鉴于我们密码系统的内部结构，这意味着明文大小为15Kbits。如果我们为每个40字节的传入数据包生成一个cPIR应答，则生成的密文中的大部分可用空间都将丢失，但cPIR应答生成操作的成本不会降低（对于空元素，该操作是免费的，但是对于小元素，该操作的成本与完整的明文相同）。因此，如果我们处理400字节的数据包而不是40字节的数据包，那么cPIR应答生成的成本是相同的，但我们处理的信息要多十倍。即使对于最大的大小（我们考虑通常的数据包大小，达到标准MTU（AXIMUM传输单元），即1500字节），分组总是适合明文，处理吞吐量在分组大小上是线性的。

        如果我们考虑一个典型的双态分布（40%个非常小的分组，40%个接近MTU分组，20%个在分组之间），如在[49 ]中描述的，嗅探器能够以600 MbPs（紫色线）处理链路。如果我们认为嗅探器对非常小的数据包（大部分是ACK）不感兴趣，它可以在稍微超过1Gbps（绿线）的情况下处理一个链接。如果我们对数据包进行缓冲，直到从给定的源IP地址获得足够的数据来填充明文，才生成cPIR应答，那么我们可以做得更好。在这种情况下，我们可以选择提供更好处理速度的参数，例如（2048120）。在这种设置下，如果我们在生成cPIR应答之前为给定IP源缓冲90kbit的数据，我们可以以大约3Gbps（蓝线）的速度处理参数（2048120）的链路（使用更高的安全参数，我们可以获得几乎相同的性能，但查询要大两倍）。

        当然，实现一个完整的私有搜索原型将意味着研究其他问题，例如确保其他方面（数据包拦截、输出上的Bloom过滤器等压缩功能）能够应对这种吞吐量，但这超出了本文的范围。

4.4 静态\动态数据库上的延迟

        在本节中，我们希望在数据为静态或动态的设置中评估XPIR延迟，即往返时间（RTT）。图10显示了使用静态数据实现的RTT，图11显示了使用动态数据实现的RTT。x轴表示数据库的大小，范围从1Mb到1Tb。绿线表示请求处理时间（RP），红线表示没有网络的RTT（即客户端与服务器位于同一台机器上），不同的蓝线表示具有FTTH网络的RTT，n的不同值。而在考虑吞吐量时，请求处理和数据导入是最重要的参数，在查看RTT时，在回复处理时间和上传/下载时间之间取得平衡的性能结果 .

fig 10 XPIR在FTTH网络上的MSI GT60笔记本电脑上提供静态数据的往返时间（RTT）和请求处理（RP）时间（数据库大小以位为单位）。对于10个元素以下的数据库，普通PIR（从上到下第二个填充行）比cPIR快，这是很自然的，因为cPIR的回复扩展因子约为5。对于包含更多元素的数据库，cPIR的速度可以提高50倍。当客户端是本地的时，RTT（红色粗虚线）与RP（绿色粗填充线）匹配，特别是对于大型数据库。每一条蓝色细线都给出了固定n和不同数据库大小的RTT。对于大型数据库来说，回复大小是一个限制因素，这解释了为什么随着n的增长，性能更接近理想的RTT（当n增长时，固定的数据库大小“缩小”）。对于小型数据库，查询大小是限制因素。RTT的增长速度不如n快，因为优化器使用聚合。

        需要注意的是，cPIR中的常用技术，如聚合和递归（见第2.2节），对于保持RTT较低是强制性的。在图10中，我们为Ring-L we加密系统使用了参数（1024，60），因此查询元素大小为128Kb，$F\simeq 6$。对于$n=10000$和$l=1MB$，如果没有使用聚合和递归，则发送查询（通过FTTH链路传输$10000\ast 128Kb$数据需要12.8秒，发送回复$（6\ast 1Mb）$需要0.06秒，而生成查询（2.2 Gbps）需要0.05秒，处理查询（10 Gbps）需要0.1秒，解密回复（5.6 Gbps）需要约1秒。使用递归将查询发送时间除以系数50，对其他时间几乎没有影响，因此显然是有益的。

fig 11 XPIR在FTTH网络上的MSI GT60笔记本电脑上提供动态数据的往返时间（RTT）和请求处理时间（RP）（数据库大小以位为单位）。为了清晰起见，琐碎的PIR被屏蔽了，因为图10中的大多数注释也适用于此。由于数据尚未预处理，请求处理时间更长，但上传/下载时间不变。这就解释了为什么除了达到理想RTT的差距较小之外，蓝线几乎是相同的。实际上，这意味着RTT不受预处理的太大影响，除了非常大的数据库。

        在有利的情况下，使用聚合和递归，优化器可以设置cPIR参数，以便将具有高n值的数据库的形状转换为具有较小n值的数据库。这就是为什么在这两个图上，n越高RTT越低的原因。事实上，如果较小的n更有利，则数据库的形状会被转换以降低该参数。正如人们所观察到的，高n线倾向于接近RTT极限，即RP线。静态数据库和动态数据库之间的唯一区别在于请求处理速度受动态情况下数据预处理需求的影响。可以观察到请求处理的不同值（两个图上都有红色虚线）。此后，对于动态数据库，高n行将在以后趋向于RP行，即使用更大的数据库。这意味着在大多数联网情况下，除了最大的数据库外，静态和动态数据库的RTT将类似。

        Match.com Use-Case：在这个用例中，我们认为在线约会数据库服务器希望为其客户提供付费的私人关键字搜索机制。当使用这个系统时，用户可以定义一些公共标准，比如他们想在哪个城市与人见面（这可能是他们的IP透露的）。这组公共参数将减少数据库大小，在此范围内，将根据私有条件进行第二次搜索。然后，用户可以进行基于cPIR的关键字搜索（参见第2.3节），以获得与一组私有关键字匹配的配置文件。如果我们假设数据库有100万个配置文件，每个配置文件都是1兆比特，那么完整的数据库将是1兆比特。我们还必须考虑到，每个配置文件可能会匹配一组关键字，并且回复生成成本会乘以私人关键字搜索中匹配关键字的平均数量。如果我们假设平均配置文件有五个关键字，使用图10中给出的RTT，用户需要等待十分钟才能得到回复，这对于web体验来说可能太多了。使用我们描述的公共关键字预过滤，我们可以希望将数据库的大小除以10到100（如果用户分布在各个城市，并且公共关键字足够具体），这将把等待时间减少到6-60秒，这是一个更合理的搜索时间。当然，如果我们考虑匹配。com拥有500万用户（根据维基百科的页面引用了2014年的信息来源）和数兆字节的个人资料，公共过滤必须更加高效。但不久前，我们还无法想象在如此庞大的社交网络中拥有可用的cPIR协议。

        纽约证券交易所用例：在最后一个用例中，我们感兴趣的是以尽可能低的延迟在动态流上使用XPIR。纽约证券交易所（NYSE）安全金融交易基础设施（SFTI）高端服务提供5-10Gbps的全球各种股票市场数据。彭博社的“窥探”丑闻很好地说明了为什么人们希望对自己感兴趣的财务信息保密。在这个应用程序中可以看到两种不同类型的用法：面向吞吐量或面向延迟。在第一种情况下，客户可能希望注册到一组给定的信息流，并获得来自股票市场、分析师等的有关关联公司的所有信息，以及源源不断的最新信息流。在这种情况下，应用程序非常类似于IPTV服务，其中数据流涉及财务信息，而不是电视流。有关性能结果，请参阅第4.3节。

        在第二种情况下，客户希望尽可能快地检索有关公司的最后一组信息。在这种情况下，股市服务可以被视为收集远程传感器生成的数据，并根据每个请求向其客户提供对这些动态数据的访问。因此，最困难的问题是，客户检索给定公司的信息需要多长时间，换句话说，数据有多新鲜？例如，假设一个用户想要从过去的100毫秒中获取一些信息（考虑到底层网络RTT，我们不能期望获得更多的最新数据）。在SFTI 5Gbit流中，对应于100ms的数据量应为500Mbit。由于这些数据由许多元素组成，我们可以预期延迟将接近图11中的最佳线，因此用户应该在大约100ms内获得信息，这是对已经是100ms的信息的合理等待时间。

4.5 其他密码系统

        如前所述，在几乎所有情况下，优化器都会选择基于Ring-LWE的cPIR，因为它提供了最佳结果。然而，在某些极端情况下，优化器选择执行基于Paillier的cPIR或简单的（完整数据库下载）PIR。将为非常小的带宽选择基于Paillier的cPIR，在这种情况下，cPIR应答生成吞吐量并不重要，因为大部分时间用于发送应答，而应答扩展因子是最重要的参数。另一方面，当可用带宽高于数据库处理吞吐量时，普通PIR当然是自然选择。因此，静态预处理数据库的限制应该是20Gbps，动态数据库的限制应该是5Gbps。其他极端情况下，琐碎的PIR将是自然选择。例如，包含两到四个元素的数据库。在这种情况下，由于我们的加密方案的扩展因子，带有我们的RingL WE方案的cPIR回复将大于数据库本身。另一个例子是非常小的数据库，其中查询大小可能大于数据库大小。例如，在一个包含10个元素的10Mbit数据库上使用ADSL连接（1Mbps上传/20Mbps下载），发送我们查询的RingL至少需要1秒，而完整的数据库下载只需要半秒（请注意，使用聚合来减少查询大小并不能解决问题）。当然，在某些情况下，这样的设置可能与现实生活中的情况相符，但几乎没有。

5 结论

        基于格的密码学在最坏情况到平均情况的缩减和完全同态加密方面取得了突破性进展。然而，长期以来，它被认为是不切实际的，尽管它的渐近结果非常好。这个研究领域已经成熟了很多。理想晶格设置的到来，以及许多性能调整的发展，在非渐近意义上彻底改变了可达到的性能。cPIR通常被认为是一种临时协议[1]，但基于晶格的加密技术带来了真正的彻底改变，因为即使没有高端服务器，cPIR也变得可行。我们已经证明，我们的协议可以在几秒钟内处理范围广泛的数据库，甚至可以处理100Gb的数据库。

        以数论密码系统为Paillier，这些实验将花费数千秒，该系统将以1Mbit/s的速度处理数据库。发送数据库，即使超过100Mbit/s的链接，也将比我们在实验中给出的增加100倍。本文给出的结果是在一台商品笔记本电脑上获得的，在多核环境下使用高端服务器只能进一步增加这种差异。然而，这并不是我们的目的，我们想强调的是，基于晶格的加密技术已经将完全不切实际的东西转变为每个人都可行的东西。因为我们想证明这对每个人来说都是可行的，所以我们提供了自动优化工具，允许任何人不用成为密码专家就可以使用我们的库。我们渴望听到这些人的经历。

        最后，值得注意的是，即使我们已经证明cPIR可以用于非常大的数据库，但在实践中，随着数据库的增长，cPIR可以作为一个构建块，与其他技术结合使用，以提高可伸缩性。Popcorn[48]就是一个很好的例子，它巧妙地结合了cPIR和ITPIR，提供了一个比我们使用的简单例子更高效的类似Netflix的私有流媒体服务。另一个例子是使用cPIR作为构建块的通信和计算效率高的ORAM协议。我们还希望XPIR将增加使用cPIR作为子例程的应用程序的范围。

---

参考文献

[1] R. Sion and B. Carbunar, “On the Computational Practical-ity of Private Information Retrieval,” in 14th ISOC Network and Distributed Systems Security Symposium (NDSS’07),San Diego, CA, USA, 2007.
[2] B. Chor, O. Goldreich, E. Kushilevitz, and M. Sudan, “Pri-vate Information Retrieval,” in 46th IEEE Symposium on Foundations of Computer Science (FOCS’95), Pittsburgh,PA, USA, pp. 41–50, IEEE Computer Society Press, 1995.
[3] W. Gasarch, “A Survey on Private Information Retrieval,” Bulletin of the European Association for Theoretical Computer Science, vol. 82, pp. 72–107, Feb. 2004. Columns:Computational Complexity.
[4] A. Kiayias and M. Yung, “Secure Games with Polynomial Expressions,” in ICALP: Annual International Colloquium on Automata, Languages and Programming, 2001.
[5] C. Aguilar Melchor and P. Gaborit, “A Fast Private Information Retrieval Protocol,” in The 2008 IEEE International Symposium on Information Theory (ISIT’08), Toronto,Ontario, Canada, pp. 1848–1852, IEEE Computer Society Press, 2008.
[6] J. T. Trostle and A. Parrish, “Efficient computationally private information retrieval from anonymity or trapdoor groups,” in ISC (M. Burmester, G. Tsudik, S. S. Magliveras, and I. Ilic, eds.), vol. 6531 of Lecture Notes in Computer Science, pp. 114–128, Springer, 2010.
[7] J. P. Stern, “A New Efficient All-Or-Nothing Disclosure of Secrets Protocol.,” in 13th Annual International Conference on the Theory and Application of Cryptology & Information Security (ASIACRYPT’98), Beijing, China, vol. 1514 of Lecture Notes in Computer Science, pp. 357–371, Springer, 1998.
[8] H. Lipmaa, “First cpir protocol with data-dependent compu- tation,” in Proceedings of the 12th International Conference on Information Security and Cryptology, ICISC’09, (Berlin, Heidelberg), pp. 193–210, Springer-Verlag, 2010.
[9] R. Ostrovsky and W. E. Skeith III, “Private Searching on Streaming Data,” in Advances in Cryptology - CRYPTO 2005: 25th Annual International Cryptology Conference, Santa Barbara, California, USA, August 14-18, 2005, Pro- ceedings, vol. 3621 of Lecture Notes in Computer Science,
pp. 223–240, Springer, 2005.
[10] D. Bleichenbacher, A. Kiayias, and M. Yung, “Decoding
of Interleaved Reed Solomon Codes over Noisy Data,” in
Automata, Languages and Programming, 30th International
Colloquium, ICALP 2003, Eindhoven, The Netherlands,
June 30 - July 4, 2003. Proceedings (J. C. M. Baeten, J. K.
Lenstra, J. Parrow, and G. J. Woeginger, eds.), vol. 2719 of
Lecture Notes in Computer Science, pp. 97–108, Springer,
2003.
[11] D. Coppersmith and M. Sudan, “Reconstructing curves in
three (and higher) dimensional space from noisy data,” in
Proceedings of the 35th Annual ACM Symposium on Theory
of Computing, STOC’2003 (San Diego, California, USA,
June 9-11, 2003), (New York), pp. 136–142, ACM Press,
2003.
[12] S. Arora and R. Ge, “New algorithms for learning in pres-
ence of errors,” in Automata, Languages and Programming,
30th International Colloquium, ICALP 2003, Eindhoven, The
Netherlands, June 30 - July 4, 2003. Proceedings, pp. 403–
415, Springer, 2011.
[13] J. Bi, M. Liu, and X. Wangi, “Cryptanalysis of a homomor-
phic encryption scheme from isit 2008,” in Information The-
ory Proceedings (ISIT), 2012 IEEE International Symposium
on, pp. 2152–2156, 2012.
[14] T. Lepoint and M. Tibouchi, “Cryptanalysis of a (some-
what) additively homomorphic encryption scheme used in
pir,” in WAHC’15 - 3rd Workshop on Encrypted Computing
and Applied Homomorphic Cryptography, 2015.
[15] C. Aguilar Melchor, B. Crespin, P. Gaborit, V. Jolivet, and
P. Rousseau, “High-speed Private Information Retrieval
Computation on GPU,” in Second International Conference
on Emerging Security Information, Systems and Technolo-
gies (SECURWARE’08), Cap Esterel, France, pp. 263–272,
IEEE Computer Society Press, 2008.
[16] P. Mittal, F. G. Olumofin, C. Troncoso, N. Borisov, and
I. Goldberg, “Pir-tor: Scalable anonymous communication
using private information retrieval.,” in USENIX Security
Symposium, 2011.
[17] R. Henry, Y. Huang, and I. Goldberg, “One (block) size fits
all: Pir and spir with variable-length records via multi-block
queries,” Proceedings of NDSS, 2013.
[18] T. Mayberry, E.-O. Blass, and A. H. Chan, “Efficient private
file retrieval by combining ORAM and PIR,” in Proceedings
of Annual Network & Distributed System Security Sympo-
sium, pp. 1–11, Citeseer, 2014.
[19] E.-O. Blass, R. Di Pietro, R. Molva, and M. Önen, “Prism –
privacy-preserving search in mapreduce,” in Privacy Enhanc-
ing Technologies (S. Fischer-Hübner and M. Wright, eds.),
vol. 7384 of Lecture Notes in Computer Science, pp. 180–
200, Springer Berlin Heidelberg, 2012.
[20] F. Olumofin, P. Tysowski, I. Goldberg, and U. Hengartner,
“Achieving efficient query privacy for location based ser-
vices,” in Privacy Enhancing Technologies (M. Atallah and
N. Hopper, eds.), vol. 6205 of Lecture Notes in Computer
Science, pp. 93–110, Springer Berlin Heidelberg, 2010.
[21] F. Olumofin and I. Goldberg, “Privacy-preserving queries
over relational databases,” in Privacy Enhancing Technolo-
gies (M. Atallah and N. Hopper, eds.), vol. 6205 of Lecture
Notes in Computer Science, pp. 75–92, Springer Berlin Hei-
delberg, 2010.
[22] C. Devet and I. Goldberg, “The best of both worlds: Com-
bining information-theoretic and computational pir for com-
munication efficiency,” in Privacy Enhancing Technologies,
pp. 63–82, Springer, 2014.
[23] V. Lyubashevsky, C. Peikert, and O. Regev, “On ideal
lattices and learning with errors over rings,” in EURO-
CRYPT’2010, vol. 6110 of Lecture Notes in Computer Sci-
ence, pp. 1–23, Springer, 2010.
[24] W. Gasarch and A. Yerukhimovich, “Computational in-
expensive PIR,” 2006. Draft available online at http:
//www.cs.umd.edu/~arkady/pir/pirComp.pdf.
[25] O. Regev, “New lattice based cryptographic constructions,”
Journal of the ACM, vol. 51, no. 6, pp. 899–942, 2004.
[26] S. W. Smith and D. Safford, “Practical server privacy with
secure coprocessors,” IBM Systems Journal, vol. 40, no. 3,
pp. 683–695, 2001.
[27] E. Kushilevitz and R. Ostrovsky, “Replication is not needed:
Single database, computationally-private information re-
trieval (extended abstract),” in FOCS: IEEE Symposium on
Foundations of Computer Science (FOCS), pp. 364–373,
1997.
[28] F. Olumofin and I. Goldberg, “Revisiting the computa-
tional practicality of private information retrieval,” in Fi-
nancial Cryptography and Data Security (G. Danezis, ed.),
vol. 7035 of Lecture Notes in Computer Science, pp. 158–
172, Springer Berlin Heidelberg, 2012.
[29] Gilles Brassard and Claude Crépeau and Jean-Marc Robert,
“All-or-Nothing Disclosure of Secrets,” in CRYPTO (A. M.
Odlyzko, ed.), vol. 263 of Lecture Notes in Computer Sci-
ence, pp. 234–238, Springer, 1986.
[30] Z. Brakerski and V. Vaikuntanathan, “Fully homomorphic
encryption from ring-lwe and security for key dependent
messages,” in Advances in Cryptology - CRYPTO 2011 -
31st Annual Cryptology Conference, vol. 6841, p. 501, 2011.
[31] Y. Doröz, B. Sunar, and G. Hammouri, “Bandwidth efficient
pir from ntru,” in 2nd Workshop on Applied Homomor-
phic Cryptography and Encrypted Computing - WAHC’14,
pp. 195–207, Springer, 2014.
[32] A. Kiayias, N. Leonardos, H. Lipmaa, K. Pavlyk, and
Q. Tang, “Optimal rate private information retrieval from
homomorphic encryption,” PoPETs, vol. 2015, no. 2,
pp. 222–243, 2015.
[33] D. Pointcheval, “Le chiffrement asymétrique et la sécurité
prouvée,” Habilitation à diriger des recherches, Université
Paris VII, 2002.
[34] S. Goldwasser and S. Micali, “Probabilistic encryption,”
Journal of Computer and System Sciences, vol. 28, no. 2,
pp. 270–299, 1984.
[35] R. Lindner and C. Peikert, “Better key sizes (and attacks)
for lwe-based encryption,” in CT-RSA (A. Kiayias, ed.),
vol. 6558 of Lecture Notes in Computer Science, pp. 319–
339, Springer, 2011.
[36] H. Lipmaa, “An oblivious transfer protocol with log-squared
communication,” in 8th Information Security Conference
(ISC’05), Singapore, vol. 3650 of Lecture Notes in Computer
Science, pp. 314–328, Springer, 2005.
[37] M. J. Freedman, Y. Ishai, B. Pinkas, and O. Reingold, “Key-
word Search and Oblivious Pseudorandom Functions,”
vol. 3378 of Lecture Notes in Computer Science, pp. 303–
324, Springer, 2005.
[38] R. Ostrovsky and W. E. Skeith III, “Private searching on
streaming data,” J. Cryptology, vol. 20, no. 4, pp. 397–430,
2007.
[39] M. Finiasz and K. Ramchandran, “Private Stream Search
at the same communication cost as a regular search: Role
of LDPC codes,” in Information Theory Proceedings (ISIT),
2012 IEEE International Symposium on, pp. 2556–2560,
2012.
[40] P. Paillier, “Public-key cryptosystems based on compos-
ite degree residuosity classes,” in 18th Annual Eurocrypt
Conference (EUROCRYPT’99), Prague, Czech Republic,
vol. 1592 of Lecture Notes in Computer Science, pp. 223–
238, Springer, 1999.
[41] N. Göttert, T. Feller, M. Schneider, J. Buchmann, and
S. Huss, “On the design of hardware building blocks for
modern lattice-based encryption schemes,” in Cryptographic
Hardware and Embedded Systems – CHES 2012 (E. Prouff
and P. Schaumont, eds.), vol. 7428 of Lecture Notes in
Computer Science, pp. 512–529, Springer Berlin Heidelberg,
2012.
[42] S. Halevi and V. Shoup, “Design and implementation of a
homomorphic-encryption library,” 2013.
[43] Z. Brakerski, C. Gentry, and V. Vaikuntanathan, “(leveled)
fully homomorphic encryption without bootstrapping,” in
Proceedings of the 3rd Innovations in Theoretical Com-
puter Science Conference, ITCS ’12, (New York, NY, USA),
pp. 309–325, ACM, 2012.
[44] D. Harvey, “Faster arithmetic for number-theoretic trans-
forms,” J. Symb. Comput., vol. 60, pp. 113–119, 2014.
[45] T. Güneysu, T. Oder, T. Pöppelmann, and P. Schwabe,
“Software speed records for lattice-based signatures,” in
Post-Quantum Cryptography (P. Gaborit, ed.), vol. 7932
of Lecture Notes in Computer Science, pp. 67–82,
Springer-Verlag Berlin Heidelberg, 2013. Document ID:
d67aa537a6de60813845a45505c313, http://cryptojedi.org/
papers/#lattisigns.
[46] ISO/IEC, “High efficiency coding and media delivery in het-
erogeneous environments – part 2: High efficiency video
coding,” Tech. Rep. ISO/IEC 23008-2:2013, International
Standards Organization Publication, 2013.
[47] J. Ohm, G. Sullivan, H. Schwarz, T. K. Tan, and T. Wie-
gand, “Comparison of the coding efficiency of video coding
standards;including high efficiency video coding (hevc),” Cir-
cuits and Systems for Video Technology, IEEE Transactions
on, vol. 22, pp. 1669–1684, Dec 2012.
[48] T. Gupta, N. Crooks, S. Setty, L. Alvisi, and M. Walfish,
“Scalable and private media consumption with popcorn.”
Cryptology ePrint Archive, Report 2015/489, 2015. http:
//eprint.iacr.org/.
[49] R. Sinha, C. Papadopoulos, and J. Heidemann, “Internet
packet size distributions: Some observations,” Tech. Rep.
ISI-TR-2007-643, USC/Information Sciences Institute, May
2007. Orignally released October 2005 as web page http:
//netweb.usc.edu/~rsinha/pkt-sizes/.