隐私信息检索(Private information retrieval PIR)也称为隐匿查询或匿踪查询，在医疗、股票、金融、社交等领域中都有大量应用场景。近年来PIR技术研究逐渐丰富，行业对应用PIR实现隐私保护的呼声也随之高涨。

引言

[SealPIR]^[1]是微软开源的PIR实现，实现了2018年发表在IEEE S&P的论文[ACLS18]^[2]中的PIR方案。论文题目《PIR with Compressed Queries and Amortized Query Processing》已经包含了两个主要的贡献点：

• 对查询进行了压缩，通信量降低了274倍；

• 通过概率批量编码(probabilistic batch codes PBCs)可以同时执行多个查询，分摊查询处理的开销。

在近年的PIR协议研究中，特别是基于HE的PIR协议有很多进展，且大多数都是和SealPIR进行对比，因此理解SealPIR的原理也就有助于理解和跟踪he-based PIR近年来的发展。

本文将为小伙伴们介绍基于同态的隐私信息检索协议-SealPIR，欢迎大家在本文留言讨论。

1.PIR定义及分类

1.1 PIR定义

隐私信息检索(Private information retrieval PIR)是对信息检索(information retrieval IR)的一种扩展，最早在[CKGS95]^[3]中提出，用于保护用户查询信息，防止数据持有方得到用户的检索条件。

PIR协议目标可以定义为：Alice有共N行的数据库D，每一行的数据大小为L。Bob希望查询获得其中指定位置的某一行，但是不想告诉Alice自己查询的是哪一行。

隐私信息检索协议(PIR)需要满足正确性和安全性两方面的要求：

• 正确性：用户得到要查询的数据

• 安全性：服务端 无法知道 用户查询的是哪条数据

1.2 PIR分类

1.2.1 服务器数量分类

按照服务器数量分类可分为多服务器PIR和单服务器PIR。

• 多服务器PIR(MultiServer-PIR)

多服务器PIR一般基于信息论安全(Information-theoretic security)的密码技术，例如：基于函数密码分享(Function Secret Sharing)[BGI16]^[4]方案，也称为：IT-PIR。

多服务器PIR协议大体流程如下：

1. 客户端生成查询条件的分量，发送给不同的服务器；
2. 服务器收到查询条件的分量后进行相应的计算，返回给客户端；
3. 客户端接收到所有服务器的响应后，将服务器查询响应看做秘密共享的分量进行合成，得到查询结果。

为了保护查询信息的安全，多服务器PIR方案中要求服务器之间是不能合谋的，增加了系统实现和部署的难度。多服务器PIR方案中计算量相对较小，但通信量一般很大，大体规模是?^? (1)。

• 单服务器PIR(SingleServer-PIR)

单服务器PIR一般基于公钥密码方案，特别是同态性质的公钥密码方案，安全性基于计算复杂理论，也称为CPIR。

基于同态的单服务器PIR方案，大体流程如下：

1. 客户端生成加密的查询向量，发送给服务端;
2. 服务端接收到查询向量后，在本地执行同态运算，将结果返回给客户端；
3. 客户端收到响应后，解密得到查询结果。

单服务器PIR方案一般通信量较少，但计算量较大，且容易部署。

1.2.2 按照检索条件分类

• Index PIR/Dense PIR

服务端有n个元素的数据库?={?₁,?₂,…,?_?}，用户查询第?个元素，通过执行PIR协议，用户得到?_?，服务端不知道用户查询?的信息。由于用户的查询条件在一个连续的集合[1…?]，Index PIR也称为Dense-PIR。

 

• Keyword PIR/Sparse PIR

服务端的数据是(key,value)对构成的n个元素的数据库，用户选择自己要查询的key，通过执行PIR协议，用户得到key对应的value。这里查询条件key不能覆盖一个连续集合，例如：手机号或身份证，也称为Sparse PIR。

1.3 PIR性能指标

PIR的性能指标主要包括计算量和通信量。

• 计算量：计算量一般指的是服务端的计算量。

• 通信量：通信量可细分为查询请求的通信量和响应的通信量。

Trivial PIR中服务端没有计算量，将数据全部发给客户端，客户端在本地查询，通信量跟数据库中数据量n相关。因此PIR的通信量要求小于数据库的容量。对比IT-PIR和CPIR的计算量和通信量可以看到，IT-PIR在计算量较少，但通信量较大；CPIR计算量较大，但通信量较小。

除了计算量和通信量两个指标外，有些论文里还引入了成本(monetary)作为指标，成本(monetary)指标实际上是对计算量和通信量平衡得到的指标，更适用于实际业务需求。

2.基础知识

目前Single-PIR最好的协议大多基于近似同态算法(Somewhat homomorphic encryption SHE)设计的，SealPIR中用到的是[BFV12]^[5]算法。

2.1 BFV方案

[BFV12]将[Brakerski12]^[6]中的同态算法从LWE迁移到RLWE，RLWE因为有特殊的结构比LWE性能更好，例如，RLWE选择特定参数时，乘法可以使用NTT(Number Theoretic Transform)。BFV算法的参数包括：

• 多项式次数: ?
• 明文模: ?，素数
• 密文模: ?，若干素数的乘积

明文空间是?_?=?_?[?]/(?^?+1)，即：?₀+?₁?+…+?_?-2?^?-2+?_?-1?^?-1，?_?∈?_?密文由两个多项式(?₀,?₁)构成，?₀^,?₁∈?_?=?_?[?]/(?^?+1)。密文扩张因子(Ciphertext expansion factor)，是指SHE加密后得到密文相对明文的增大的比例，对于BFV算法，密文扩张因子?=2???(?)/???(?)。对于128bit安全，同态加密标准中给出了推荐参数。考虑上面的密文扩展因子，明文模?取相对较大时，能获得较小的密文扩张；但进行密文同态计算时，明文模?太大时，会导致噪声增长太快，明文模?也不能取得太大。SealPIR中BFV参数中N和q选择举例如下表：

多项式次数	明文模	密文模
2048		54bit
4096	38bit	109bit 2*36+37
8192	17bit	218bit 243+344

SealPIR中用到的同态运算：

• 密文加法：

    明文?₁(?)，?₂(?)对应的密文是?₁和?₂，?₁+?₂是?₁(?)+?₂(?)的密文。

• 明文乘密文：

    明文?₁(?)对应的密文是?₁，?₂(?)·?₁是?₁(?)·?₂(?)的密文。

• 替换：

    明文?(?)对应的密文是?，对于奇数?，???(?,?)是?(?^?)的密文。

    例如，?(?)=7+?²+2?³，???(?,3)得到?(?³)=7+{?³}²+2{?³}³=7+?⁶+2?⁹的密文。

SHE的同态运算会引起噪声的增长，当噪声超过一定限制时，无法解密得到明文，所以要适当选择SHE算法的参数，及控制同态运算的噪声增长。

2.2 HE-based PIR

HE-based PIR基本原理如下图所示：

假设服务端数据量为?，基本流程如下

1. 客户端生成BFV算法的私钥和公钥（??,??）;
2. 客户端生成查询?维0-1向量(0,...,0,1,0,...,0)，其中查询index ?的位置位1，其它位置为0;
3. 客户端使用公钥加密查询向量的每个分量，得到(?(0),...,?(0),?(1),?(0),...,?(0))，发送给服务端;
4. 服务端接收到密态查询向量后，和本地数据构成的?维向量(?1,?2,...,??)，进行点乘，得到?(0·?₁+...+0·?_?-1+?_?+0·?_?+1+...+0·?_?)，发送给客户端;
5. 客户端对查询响应密文解密，得到待查询的数据?_?。

HE-based PIR协议可以抽象为四个子算法，即(Setup,Query,Answer,Extract)，如下图所示：

• SETUP: 服务端 将数据库中的数据转换为HE明文
• QUERY: 客户端根据查询index，生成密态查询向量
• ANSWER: 服务端计算明文向量和密文向量的内积
• EXTRACT: 客户端使用私钥解密查询响应密文，得到查询数据

3.SealPIR协议

HE-based PIR基本原理中的协议，存在的问题是

• 查询请求的计算量和通信量都大，需要生成和发送?个密文；

• 服务端每个数据表示为一个HE明文，需要计算n为向量的内积，容易导致噪声太大，无法解密

SealPIR论文给出了解决上面的问题的办法：

3.1 将多个数据pack到一个HE明文

查询的db_index需要转换为plaintext_index

假设数据库中数据长度为288字节(SealPIR论文中给出的长度)，BFV参数选择：多项式次数8192，明文模16bit，举例说明一下pack的效果：

• 数据库中每条数据，需要HE 明文多项式中个系数来表示????(288*8/16)=144。
• HE 一个明文多项式可以包含?????(8192/144)=56调数据库数据。
• 对数据库的查询db_idx，需要转换为明文的查询plain_index=??_???/56。
• 用户得到查询相应密文，通过私钥进行解密，得到HE明文，将HE明文对应的系数进行组合，得到真正查询的数据。

3.2 将查询向量压缩到一个密文

显著减少通信量，服务端增加一个额外的Expand操作得到查询密文向量。

查询向量(0,...,0,1,0,...,0)压缩到一个HE明文多项式为例，查询向量中的每个分量对应为HE明文多项式中的系数。

?₀+?₁?+...+?_?-2?^?-2+?_?-1?^?-1=?^?????_?????,其中：?_?=0,?≠?????_????? ， ?_?=1,?=?????_?????。

对查询明文进行加密，得到?(?₀+?₁?+...+?_?-2?^?-2+?_?-1?^?-1)=?(?^?????_?????)。

服务端接收到查询密文后，执行Expand算法，得到查询密文向量：(?(0),...,?(0),?(1),?(0),...,?(0))。

还是以上面packing的参数举例，每个HE明文可以pack 56个数据库数据，客户端查询时，将db_index转换为plain_index，即对HE明文数据库进行查询，最多可以查询8192个HE明文，转换成数据库数据，最多可以查询8192*56=458752条数据，不能满足实际业务中的需求。

为了满足实际将查询向量压缩到多个HE明文来表示查询向量，对于百万数据来讲，需要????(1000000/8192)=123个HE明文，对应123个HE密文，才能表示百万数据的查询向量。为了进一步压缩查询密文的数量，可以使用下面的多维表示方法。

Expand算法的详细描述和证明可以参考[ACLS18]^[2]论文中的内容。

3.3 将数据库一维向量转换为多维向量

二维查询时将数据库数据表示为√?*√?的矩阵，减少查询向量

以上面packing的参数举例，将数据库表示为2维数据时，通过两个查询密文可以查询的数据量是8192*8192*56≈37亿，已经能满足绝大多数的数据库查询任务。数据库数据量为?，通过packing后得到HE明文数量为?′，?是密文扩张因子，二维查询流程如下：

服务端：

• 将HE明文表示为√?′*√?′的矩阵?，其中√?′＜8192。
• ?_?是密文查询列向量，?_?=?·?_?，其中?_?是√?′ * 1的密文列向量。
• 将?_?中每个密文拆分为?份明文多项式，得到√?′ * ?矩阵??_?。
• ?_?是密文查询行向量，??^?_?·?_?，? * 1得到的密文向量。

客户端：

• 客户端收到?个密文向量，使用私钥??解密，将其组合成密文???(?[?,?])，对使用私钥??解密???(?[?,?])得到真正的查询HE明文?[?,?]，对HE明文?[?,?]中对应的系数进行组合，得到真正查询的数据。

服务端为了避免进行密文乘以密文的同态运算，第3步中将密文拆解成?个明文进行操作，最后服务端发给客户端的查询响应是?个密文，在多项式次数8096时，?≈26，因此，服务端发给客户端的查询响应消息太大，这也是SealPIR主要的问题，后续的文章，主要目标是减少查询响应消息，在后面的性能对比中可以看到。

3.4 通过一次进行多个查询降低整体性能开销

SealPIR论文中还给出了通过PBC(probabilistic batch code)将数据库中的内容分成若干batch，同时执行k个查询时，分别对不同的batch进行查询，降低整体的性能开销。论文给出了基于CuckooHash的PBC构造方案。

CuckooHash的hash数为3，bin数量为1.5?，k为同时查询的数量。

服务端 预处理：

• 对DB中n个index，分别计算cuckooHash的3个Hash，得到3个bin_index,将(db_index, data)插入到3个bin_index中。

客户端 预处理：

• 对DB中n个index，分别计算cuckooHash的3个Hash，得到3个bin_index,将(db_index)插入到3个bin_index中。

• 将k个查询，通过cuckooHash，插入到?=1.5?个bin中，对空的bin进行随机填充。

• 对每个bin执行PIR，共计b个PIR，每个PIR的index，是客户端实际查询的data_idx，在bin中的索引。

从上图中可以看到，客户端生成的是CuckooHashTable和SimpleHashTable两张表，服务端生成的SimpleHashTable。客户端和服务端SimpleHashTable的差别在于，服务端SimpleHashTable有实际待查询的数据，服务端SimpleHashTable只是模拟了服务端插入过程，bin中有db_index。

3.5 SealPIR的性能

SealPIR论文Figure里给出single_query和multi-query的性能数据，多项式次数是2048，明文模式20bit，密文模式60bit，数据长度288字节，数据量2²⁰。

从上面可以看到，对于百万数据(2²⁰)单个查询的时间是3.3秒左右，多个查询(256)性能可以降到0.1秒左右。

4.其它改进协议

这里介绍一下21年的两篇PIR方面的文章：

• 发表在USENIX21年的[ALP+21]^[7]

• 发表在CCS21年的OnionPIR:[MCR21]^[8]

[ALP+21]题目是《Communication–Computation Trade-offs in PIR》是计算量和通信量平衡的PIR方案，该方案显著降低了查询响应的通信量，从成本(monetary)的角度看比SealPIR降低了35%。

OnionPIR利用了somewhat homomorphic encryption(SHE)最新的进展，将两种lattice-based SHE 方案(BFV 和 RGSW)组合在一起，降低了查询响应的大小和计算量。还设计了基于状态(stateful)的PIR。

从上面的数据看到，虽然相应的改进协议对查询响应大小都有较大改进，但整体运行时间方面和SealPIR差别不大，由于引入了更复杂的算法，实现成本也会变得更高，综合来看SealPIR在实际应用中还是相对较好的选择。

参考文献

[1][SealPIR] SealPIR: A computational PIR library that achieves low communication
costs and high performance, 2020. https://github.com/microsoft/SealPIR.[2][ACLS18] S. Angel, H. Chen, K. Laine and S. Setty,"PIR with Compressed Queries and Amortized Query Processing,"2018 IEEE Symposium on Security and Privacy (SP), 2018, pp. 962-979, doi: 10.1109/SP.2018.00062.

[3][CKGS95] B. Chor, O. Goldreich, E. Kushilevitz, and M. Sudan"Private information retrieval", in Proceedings of IEEE 36th Annual Foundations of Computer Science, pp. 41-50, Oct 1995.

[4][BGI16] Elette Boyle, Niv Gilboa, and Yuval Ishai.Function secret sharing: Improvements and extensions. In CCS, 2016.

[5][BFV12] Junfeng Fan and Frederik Vercauteren. 2012.Somewhat Practical Fully Homomorphic Encryption.IACR Cryptol. ePrint Arch. 2012 (2012), 144.

[6][Brakerski12] Zvika Brakerski.Fully Homomorphic Encryption without Modulus Switching from Clas-sical GapSVP. IACR Cryptology ePrint Archive, 2012:78, 2012.

[7][ALP+21] Asra Ali, Tancrède Lepoint, Sarvar Patel, Mariana Raykova, Phillipp Schoppmann, Karn Seth, and Kevin Yeo.
Communication-computation trade-o s in PIR. In USENIX Security, 2021.

[8][MCR21] M. Mughees, Hao Chen, Ling RenOnionPIR: Response Efficient Single-Server PIR, CCS'21.

[9][CGN98] Benny Chor, Niv Gilboa, and Moni Naor.

Private information retrieval by keywords.
IACR Cryptology ePrint Archive, 1998:3, 1998.

[10][CHLR18] Hao Chen, Zhicong Huang, Kim Laine, and Peter Rindal.
Labeled PSI from fully homomorphic encryption with malicious security.
In ACM Conference on Computer and Communications Security, pages 1223–1237. ACM, 2018.P.S.文中素材来自公开发表论文，如有不妥，将立即删除