【论文阅读】查询搜索中的安全和效率权衡（ACM 10.1145）

最新推荐文章于 2024-04-21 15:56:54 发布

囚生CY

最新推荐文章于 2024-04-21 15:56:54 发布

阅读量1w

点赞数 2

分类专栏：日常文章标签：数据安全

本文链接：https://blog.csdn.net/CY19980216/article/details/109139934

版权

日常专栏收录该内容

54 篇文章 15 订阅

订阅专栏

英文标题: Privacy and Efficiency Tradeoffs for Multiword Top K Searchwith Linear Additive Rank Scoring
中文标题: 具有线性累和排序评分的多单词TopK搜索的隐私性与效率性权衡
论文下载地址(免费): https://dl.acm.org/doi/10.1145/3178876.3186084

序言

密码学11周结课, 差不多期中就要做汇报, 找了一篇跟查询安全有关的ACM报告, 主要感觉跟自然语言处理领域能搭得上边, 之前软件工程那块也是找了个语义WEB相关的内容, 都是具有很高关联性的技术点;
这篇论文要解决的问题本质就是如何让服务器在尽可能少地知道用户查询的关键词以及搜索文档库所包含的任何信息的情况下, 还能够提供给用户一个非常完美的搜索结果排序;
这看起来强人所难, 但是事实上不论是你在百度搜索引擎还是在其他网站上进行表单提交, 一般来说, 在比较正规安全的网络架构下, 服务器接收到数据都是经过加密处理的, 存在数据库里的信息大都也是加密后的结果, 服务器往往只能在加密过的信息上直接进行处理, 因为解密通常需要付出很多额外的空间和时间开销, 会极大地影响服务器性能和用户使用体验;
本质上并不可能在安全和效率上同时取得最优, 因此总是要牺牲一些以达到一个折衷, 这似乎是句废话, 但是这篇论文的确给出了一个相当创新的解决方案;
以下的提要基本上是对原文的完整翻译, 机翻的效果非常差, 笔者因为不太熟悉这个领域基本上是一个字一个字抠出来的, 虽然很蠢, 但是应该说这样做很有助于对文章的深入了解; 论文的下载链接已经在前文中给出, 有兴趣的朋友可以自行下载阅读英文原版, 理解起来可能会更好;

摘要

本文提出一个用于在中等尺寸(modest-sized)的云数据集上对top-K的关键词搜索进行高效排序的私有排序方案(private ranking schema), 这种私有排序方案是以线性递增的得分函数来确定的; 通过提出单轮C/S(client-server)协同, 服务端基于带随机掩码(masks)的盲目特征(blinded feature)权重进行部分排序, 这种schema在私有性与效率间追求平衡(strike for tradeoff); 客户端的预处理包括带有分块发布的查询分解, 以促进更早的范围交叉(earlier range intersection)和对服务端键值存储的快速访问; 服务端的查询处理通过以下方式处理特征向量稀疏性可选的特征匹配, 并启用与查询相关的块级随机掩码进行结果过滤, 以产生许多同样的用于查询匹配的文档; 本文提供了有关索引的详细信息和运行时联合查询处理(conjunctive query processing), 并提供一个评价以评估这个schema的准确性, 效率和隐私权衡(privacy tradeoff), 并通过五个不同尺寸的数据集实现此方案;

第一节引入与相关工作 INTRODUCTION AND RELATED WORK

研究背景:

云上的敏感数据规模激增, 对于用户来说在采用基于云的数据服务(包括关键词搜索)时, 隐私性保全是一个关键因素;
云服务器一般被认为是诚实但好奇的(honest-but-curious): 指服务器诚实地执行协议规范(protocal specification)和托管程序(hosted program), 但是服务器可能会在执行过程中或通过调查托管数据来观察和推断隐私数据;
为了处理这种服务器, 可搜索的加密(searchable encryption)会被用来实现隐私保全服务器侧查询匹配, 如用单个关键词, 使用OXT协议的联合多词, 或者分隔多词查询匹配;
包括OXT在内的研究不支持排序, 因为同时取得高效和安全是很难的topK排名很难, 所以这是一个公开的研究问题;

问题难点:

实施服务器端隐私保全的topK排名的主要挑战在于:
- 一方面, 先进的排序算法通常涉及基于原始特征(raw features, 详见第二节)的算术计算, 而通过加密隐藏的特征信息阻碍服务器进行高效的评分与结果比较;
- 另一方面, 不加密的特征值(feature values)可能会导致受到隐私攻击(privacy attacks);
同态加密(Homomorphic encryption)是一种可以用来加密数据同时使得服务器可以在不解密底层数据的情况下进行算术计算;
- 比如给定特征值(feature values) $f_1$ 和 $f_2$ , 服务器使用同态加密 $E$ 就可以只通过 $E(f_1)$ 和 $E(f_2)$ 的值计算得到 $E(f_1+f_2)$ 的值, 而无需知道 $f_1$ 和 $f_2$ 确切是多少;
- 但是这样的schema在涉及大量数据时仍然不是计算可行的(computationally feasible), 因为此时乘法与加法极慢, 更不用说用同态加密计算评分来比较两个结果的能力了;
  - 比如同态加密不允许在服务器上高效比较 $f_1+f_2$ 与 $f_1^{\prime}+f_2^{\prime}$ , 即使可以安全的计算 $E(f_1+f_2)$ 和 $E(f_1^{\prime}+f_2^{\prime})$ 的值;
- 备注: 同态加密见[affliation.md]
次序保全加密(order-preserving encryption)支持在不解密的情况下高效比较两个加密结果, 但是它又不支持在不解密的情况下进行加法与乘法;
- 备注: 保序加密见[affliation.md]
另一个挑战在于先进的排序会考虑许多特征, 特征向量通常是稀疏的(有很多零元), 直接存储零元会导致空间使用激增, 但使用压缩数据结构来存储又可能会泄露关于索引的统计信息(可能有恰当的防护可以使得不泄露), 这也许会导致泄露滥用攻击(leakage-abuse attacks);

前人的研究:

关于基于相似性的安全排序(similarity-based secure ranking)的工作中, 会将每个基于TF-IDF的特征向量转化为两个随机向量;
- 备注: 这里的两个随机向量理解为可能就是TF和IDF吧; 关于TF-IDF见[affliation.md]
索引构架通过乘以带有秘密矩阵(secret matrices)的特征向量, 建立前向索引;
- 备注: 正排索引是从文档角度来找其中的单词，表示每个文档(用文档ID标识)都含有哪些单词, 以及每个单词出现了多少次(词频)及其出现位置(相对于文档首部的偏移量), 所以每次搜索都是遍历所有文章;
线上查询处理将给定的查询向量进行矩阵乘法变换, 然后获得变换后的查询向量关于所有加密文档向量的点相似度(dot similarity), 这个过程的时间复杂度是 $O(T^2+DT)$ , 其中 $D$ 是文档的数量, $T$ 是字典的规模;
- 备注: 复杂度 $O(T^2+DT)$ 可以理解, 文档可以表示成一个字典维度的向量, 每个位置是单词出现的次数, 因此比较单词和文档将有 $O (D T)$ 复杂度(计算点积有 $D T$ 次乘法), 而 $O(T^2)$ 复杂度猜测是需要预先计算不同单词之间相似度;
为了扩展这个模型以考虑包括单词对(word pairs)在内的邻近特征(proximity features), 参数 $T$ 会变得非常大;
倒排索引并不可能, 因为线下与线上的带随机的矩阵变换会生成密度特征(dense feature)和查询向量, 存储索引的成本会变成 $O (D T)$ 的空间复杂度;
- 参考文献45与48使用了这种矩阵变换, 同时考虑多用户数据所有权(multiuser data ownership)和动态文档更新(dynamic document update);
- 备注:
  - 倒排索引是从单词角度找文档, 标识每个单词分别在那些文档中出现(文档ID), 以及在各自的文档中每个单词分别出现了多少次(词频)及其出现位置(相对于该文档首部的偏移量);
  - 这是正向索引
  - 这是逆向索引
  - 直观上倒排索引更适合于排序, 但是这里提到倒排索引不可行, 原因似乎是空间占用, 但是前向索引并不能减少空间占用, 没有太搞明白;
参考文献13, 32, 40中用于测试的数据集很小, 只有几千个文档或项目, 不用倒排索引的搜索成本很高导致这些文献提供的方法无法用于处理稍大一些的数据集;

本文的研究:

综上所述似乎开发一个完全安全的, 无需诉诸重量级的密码学如功能加密(functional encryption)方法的排序schema是难以置信的, 因为实际生产中要求高响应速度, 服务器主机的算法必须部署折衷的轻量级方案来计算排名分数和选择结果;
本文用于解决这个私有排序问题的策略是利用以前的可搜索加密(searchable encryption)研究并在制定有效schema时进行折衷平衡, 使得有限的信息泄露到服务器;
本文采用了一个C/S协同的方法, 服务器执行高效匹配, 累积评分, 部分排序, 客户端执行查询预处理和最后的topK结果的选择;
本文设计仅仅使用一轮的C/S通信, 因为C/S多轮的活跃通信会导致高得多的通信成本与响应潜伏(response latency);
本文假设客户端拥有一个数据集, 将云上对应的索引设置为通过客户端可搜索的;
- 原文: We assume that a client owns a dataset and places the corresponding index on the cloud to be searchable by the client.
- 备注: 应该意思是客户端可以访问服务端的文档索引吧;
本文不考虑文档存在多用户所有权(文献48)的情况, 并假设云上的索引可以被周期性的更新, 但不考虑动态索引更新(dynamic index update, 文献30与35);
- 备注: 每个文档隶属于单个用户, 动态索引更新简而言之是通过增加新的补充索引来反映新近的修改, 而不是直接重写整个倒排索引; 每一个倒排索引都会被轮流查询到 $\rightarrow$ 从最早的开始 $\rightarrow$ 查询完后再对结果进行合并; 这里应该是倒排索引总是会全局更新;
文献4和5研究了查询争夺(query scrambling), 旨在私网搜索(private web)的发布查询(issuing queries)中保护用户隐私, 但是他们假设服务器拥有可搜索的数据与未加密的索引; 本文的工作是对不同数据所有权假设的一个补充;
本文假设一个查询包含至少两个单词, 因为处理单个单词查询相对容易, 只需要在服务器上存储加密的对每个单词的预排序文档编号即可;
- 备注: 单个单词查询直接用倒排索引就可以很容易的解决, 找到那个单词, 然后排序索引值;

本文的贡献:

本文提供一个索引的, 线上的搜索schema, 使用一个线性累积函数对于这个开放的私有topK搜索问题;
本文通过部分的服务端结果过滤来寻求平衡, 以处理一个中等大小的数据集;
本文的速度比之前的baseline方案(文献13)要快上几个量级, 并且容纳了四种预先建立的排序信号(previously-developed ranking signals);
由于篇幅所限, 本文只列出正式的性质而忽略详细证明;

第二节问题定义与设计考虑 PROBLEM DEFINITION AND DESIGN CONSIDERATIONS

问题定义:

给定 $D$ 个文档特征向量, 客户端拥有 $T$ 个特征(可以理解为词汇表大小), 每个文档 $d$ 有许多特征值, 用 $f_i^d$ 表示;
客户端建立一个可搜索的索引然后将它传递给服务器;
我们着重于建立一个索引和topK搜索schema使得服务器可以获得一次查询的加密匹配文档特征, 然后在合理的响应时间内在中等大小的数据集上计算他们的排序而无需知道底层特征值;
服务器同样不应该学习到任何有意义的信息当搜索中没有涉及到特征;
本文假设每次搜索查询包含一个联合的关键词组, 并采用基于可搜索加密算法OXT(参考文献16与17)的查询单词的倒排索引项合并(posting intersection);
更快的传统合并(intersection)算法, 如同时遍历两个或更多的倒排索引项(postings)的算法, 没有被采用的原因是这样一个遍历机制会给服务器泄露更多的信息;
在搜索过程中, 一个用于确保隐私的标准技术是使用确定性的伪随机函数(PRF)来隐藏包括项目编号与文档编号在内的信息;

排序公式:

本文期望得到一个简单但流行的排序评分计算schema, 这种算法应当是文档特征的线性组合;
虽然文献47的评分传达不错的相关性表现, 多个累积树(multiple additive tree, 文献44提到)可以取得更好的相关性;
尽管如此, 将这样一个非线性的排序方法转为私有, 不仅涉及得分增加, 也会涉及值比较; 目前仍然没有可用的加密方法能够在一个单一框架中解决这两个问题;
本文提出一个线性组合公式来计算排序得分: $\sum_i \alpha_i f_i^d$
- 其中 $\alpha_i$ 是关于文档 $d$ 的特征值 $f_i^d$ 的系数;
- 假设所有的系数都是静态的, 并且可以在索引安装(setup)时嵌入到特征值中;
- 本文的剩下部分将忽略这些系数, 即线性累积排序公式简化为: $\sum_i f_i^d$

原始排序特征:

定义: 称一个排序特征是原始的(raw), 若它是直接存储在索引中; 称一个排序特征是合成的(composite), 若它是基于其他原始特征计算得到的;
本文的设计是使得第2点的排序公式中的每个基础特征(basic feature)都作为原始特征, 服务器检索到之后直接简单地将他们加进来, 而无需知道这些值所扮演的角色; 这就最小化了服务器理解他们对于排序信号(ranking signal)做出的语义贡献(semantic contributions)的可能性了;
- 备注: 所谓语义贡献我理解可以视为语义安全中的攻击者优势, 语义安全相关见[affliation.md]
我们使用第2点的排序公式来支撑4种用于信息检索文献(information retrieval literature)的排序特征:
- ① 基于项频(term-frequency)的合成特征: 如TF-IDF与BM25;
  - 备注: TF-IDF上面已经提过, 本质上就是用IDF作为权重来加全TF(词频), 而BM25是计算词条与文档相似度的算法, 主要基于以下三个值:
    - ① 单词和D之间的相关性
    - ② 单词和query之间的相关性
    - ③ 每个单词的权重
    - $Score(Q,d)=\sum_i^n W_iR(q_i,d)$ , 其中 $W_i$ 就是TF-IDF中的idf值作为权重, $R(q_i,d)=\frac{f_i(k_1+1)}{f_i+K} * \frac{qf_i(k_2+1)}{qf_i+k_2}$ 是单词 $q$ 与文档 $d$ 的相关性得分, 其中 $K=k_1(1-b+b*\frac{\rm dl}{\rm avgdl})$
    - $k_1,k_2,b$ 是调节因子, 一般 $k_1=2,b=0.75$ , $f_i$ 表示 $q_i$ 在文档 $d$ 中出现的概率, $qf_i$ 是 $q_i$ 在输入句子中的频率, $\rm dl$ 是文档长度, $\rm avgdl$ 是所有文档的平均长度;
  - 他们可以被表示成加权原始词频总和, 于是第2点的排序公式可以支持这样的特征;
- ② 基于原始邻近词语特征加和的邻近合成特征: Proximity conposite features based on the sum of raw proximity term features;
  - 这样的一个邻近词语可以是在某个距离内的 $n$ - $g r a m$ 或是一个单词对;
  - 一个传统带有位置信息的倒排索引是直接存储单词位置, 线上排序基于单词在每个文档中的位置计算合成邻近特征;
  - 虽然这种方案是空间有效的, 但是计算合成邻近特征需要从单词位置得到的次序比较(order comparison)和算术计算, 正如在第一节中提到的那样, 现在缺乏既能支持安全计算又能进行次序比较的加密算法, 泄露每个文档中相关单词的位置可能会使得统计学攻击起效, 从而揭露文档内容架构;
  - 因此我们选择使用一个被表达成原始特征加和的邻近公式(proximity formula)来直接建模邻近项; 这样的结果就是一些之前的邻近公式是不能被支持, 如最小聚合(minimum aggregation)和跨度覆盖(span coverage);
    - 备注: 这两个概念都可以在ElasticSearch中找到对应
      - 桶最小值聚合(min bucket aggregation): 简单地说是一种把具有相同标准的数据分组数据的方法, 即df.groupby(["col1","col2"]).agg({...})
      - 创建存储桶https://blog.csdn.net/lijingjingchn/article/details/107961145
      - 跨度查询(span query): 按照词语在文章中的距离或者查询几个相邻词的查询, 打个比方, 如"中华人民共和国"用"中国"做为关键字, 跨度为某个值, 如5, 跨度代表中和国之间的长度;
      - 这里用了②的特征后不能支持这两个操作, 我没有太理解;
- ③ 文档查询具体特征: 如文档查询点击率(click through rate);
- ④ 文档具体特征: 如新鲜度(freshness)与文档质量;
③④两类都是原始特征, 从而可以直接适应到累积排序公式中;
- 备注: 到这里位置, 可以知道特征就是一个向量, ①应该可以理解为当前文档的TFIDF向量, ②就是一堆选出来的 $n$ - $g r a m$ 向量(可能仅仅是用很简单的加和生成);

处理原始排序特征的稀疏性:

第3点中提到的4种分类里的②③④经常会有许多零元, 如果所有的加密零元都直接存储将会大大简化隐私保全的设计, 但是空间成本将会爆炸性的上升以至于这样的方案是不切实际的;
一种处理特征稀疏性的选择: 对每个文档进行压缩存储非零元的特征值, 即存储成一个前向索引, 然后一旦匹配查询的文档在查询处理中被被确定, 加密文档特征就会被用一个经过哈希映射的文档编号检索出来;
- 备注: 这种压缩存储就是存储非零元的位置信息, 即稀疏存储, 注意是正向存的, 所以键是位置, 值是特征值;
另一种处理特征稀疏性的选择: 将特征值嵌入到传统倒排索引(inverted index)的倒排索引项条目(posting entries)中;
- 备注: 我理解这就是在倒排索引里顺便把这个单词的特征值记录下来;
这些选择如果没有一个恰当的防护就会面临服务器直接检查文档特征向量或倒排索引项(postings)的隐私风险, 这样服务器可以无需客户端许可直接将文档统计信息汇集起来, 如词频分布, 然后就会导致泄露滥用攻击;
- 备注: 稀疏存储容易泄露文档的统计信息;
本文对于常为稀疏的可选特征(optional features)的设计是使用一个线上的键值对存储, 每个匹配文档 $d$ 分别涉及以下两类权重:
- ① 每个文档 $d$ 必选的个体特征权重(required individual feature weight) $f_i^d$ ; 当一个特征是必选的, 则每个匹配的文档都有一个特征值存储在索引中;
- ② 可选的特征权重 $O_t^d$ , 其中 $1\le t\le m$ , 一个特征是可选的指, 当这个文档中这特征值是无法从索引中获得时, 它的默认值是零;

使用掩码蒙蔽(mask blinding)的特征加密:

为保全特征值的隐私, 本文使用一个带有模加(modular addition)随机掩码来蒙蔽每个特征值, 从而将这个值隐藏起来让服务器无法获得;
随机掩码使用一个PRF确定性地生成, 只对客户端可知;
每个特征值 $f$ 在索引中以 $[f + R]$ 被存储起来:
- 其中 $[f+R]=(f+R)(mod\space N)$
- $R$ 是一个被计算成项目编号和文档编号的PRF值的特征掩码(feature mask), 取值范围为 ${0,1,2,...,N-1\}$
  - 备注: 理解为随机噪声
- $N$ 在本文的实现中被设置为常数 $2^{32}$
- 中括号表示的 $[f + R]$ 也强调服务器只能看到 $(f+R)(mod\space N)$ , 而不能知道 $f$ 与 $R$ 的具体值;
如果折衷且明智地选择掩码, 上面的schema将允许服务器通过累和掩码特征值来计算排序得分, 从而可以进行部分比较(partial comparison);
本文没有采用一个同态加密schema来进行特征蒙蔽(feature blinding), 因为这不能带来可见的优势但却更加低效, 且不能支持服务端的部分排序(partial ranking);
具体来说, 对于文档 $d$ , 索引中的特征权重 $f_i^d$ 是一个整数, 并且使用随机噪声掩码 $R_i^d$ 处理后以 $f_i^d+R_i^d]$ 存储; 可以引入一个可选的权重 $O_t^d$ 即存储成 $O_t^d+RO_t^d]$ , 这里的随机噪声掩码是 $RO_t^d$ ;
- 给定一个带有 $q$ 个必选特征的查询和 $m$ 个可选的权重, 对于包含这些掩码的文档 $d$ 排序总分(total rank score) $F$ 加上总分掩码(total score mask)模 $N$ 的结果是: $[F+M]=[\sum_{i=1}^q[f_i^d+R_i^d]+\sum_{1\le t\le m, O_t\in X}[O_t^d+RO_t^d]]$
- 其中 $M=\sum_{1\le t\le m, O_t\in X}O_t^d+\sum_{1\le t\le m, O_t\in X}RO_t^d$
- $O_t\in X$ 表示对应的可选特征可以在索引的键值对存储中找到;
虽然服务器可以计算上面的加密总和, 但是不同文档里的特征掩码是随机且相互独立的, 所以服务器是不能比较所有匹配到的文档中的相对排名次序;
- 当服务器匹配到的文档数量适中时, 服务器可以将这些结果发送给客户端, 顺带发送一个用在每个文档里的可选特征的位图(bitmap), 这个位图可以用来协助客户端移除每个排序得分中的掩码总和;
  - 备注:
    - 位图: 就是用每一位来存放某种状态, 适用于大规模数据, 但数据状态又不是很多的情况, 通常是用来判断某个数据存不存在的; 这里应该就是表示文档是否被匹配;
- 当服务器匹配到的文档数量非常大时或C/S带宽很小, 本文想要服务器进行部分排序从而使得有低分的结果先被过滤掉, 就可以不用发送给客户端; 本质上这变成了一个两阶段的排序, 是cascade ranking的一种类型;
下一节本文探索几种必要用于平衡隐私和查询响应效率的折衷方法的可能性;

第三节服务端部分排序 SERVER-SIDE PARTIAL RANKING

带均匀随机掩码(uniforma random masks)的服务端部分排序:

为了允许服务器计算匹配文档的排序得分, 一个方法是给所有具有相同特征的文档选择相同的随机掩码; 通过这种放松(relaxation), 改变掩码标志(mask symbol): 第二节中的 $R_i^d$ 变成 $R_i$ , $RO_i^d$ 变成 $RO_i$ , 于是在相同集合的匹配可选项(matching optional terms)下, 掩码总和对于所有匹配文档都是相同的, 服务器可以对这些文档进行排序;
为了支撑上面的这种策略, 需要强调两个问题:
- ① 因为每个随机特征掩码都是均匀随机的从 ${0,1,2,...,N-1\}$ 中选取, 掩码特征权重和它们的总和可能会在模 $N$ 的情况下呈现出环绕的形态, 这就可能会误导服务端的排序;
  - 为了使得服务器在不知道真实排序得分或额外的C/S交互情况下处理这种环绕问题, 可以强加一个限制使得最后的排序得分在没有特征掩码的情况下是小于 $\frac{N}{2}$
  - 给定 $q + m$ 个必选和可选特征, 每个特征权重 $w$ 应该满足不等式 $\max_{q,m}(q+m)w<\frac{N}{2}$ , 即 $w$ 的上限是 $\frac{N}{\max_{q,m}(2q+2m)}$
  - 举例子:
    - 当 $q+m\le 32$ , $N=2^{32}$ 时, 每个特征权重的上限是 $2^{26}$
    - 当 $q+m\le 1024$ , $N=2^{32}$ 时, 每个特征权重的上限是 $2^{21}$
  - 结论: 使用21bit的整型特征来排序对于测试数据集来说是充足的(sufficient)
  - 定理3.1
    - 给定 $q + m$ 个必选和可选特征, 每个特征权重满足 $\max_{q,m}(q+m)w<\frac{N}{2}$ ; 令 $F_1$ 和 $F_2$ 作为两个文档在相同的掩码和 $M$ 下的排序得分, 其中 $0\le M\le N$ , 则有下面的结论
      - 若 $|[F_1+M]-[F_2+M]|\lt \frac{N}{2}$ , 则 $[F_1+M]\le [F_2+M]$ 当且仅当 $F_1\le F_2$
      - 若 $|[F_1+M]-[F_2+M]|\gt \frac{N}{2}$ , 则 $[F_1+M]\le [F_2+M]$ 当且仅当 $F_1\ge F_2$
  - 定理3.1证明了当服务器获得两个有一定概率环绕(wraparound)的掩码排序得分 $F_1+M]$ 和 $F_2+M]$ 时, 服务器可以确定 $F_1$ 和 $F_2$ 中哪个比较大而无需知道 $F_1$ 和 $F_2$ 的具体值, 只需要检查 $F_1+M]-[F_2+M]|$ 的值是否超过 $\frac{N}{2}$ ; 注意到这个值是不会等于 $\frac{N}{2}$
- ② 相同的查询中, 不同文档可能会匹配到不同的可选特征集合; $m$ 个可选项的不同匹配组合有 $2^m$ 种可选特征匹配案例, 注意到得分掩码(score masks)在不同的案例下是不同的, 所以服务器不能直接比较两个可选案例:
  - Figure1可选特征匹配案例( $q = 3, m = 3$ )的网格关系图
    - 备注: 是否可以理解为机器学习调参中的GridSearch?
  - Figure1是一个包含3个必选项和3个可选项的可选特征匹配网格关系图, 每条边表示一个包含(subsuming)关系, 父案例包含子案例中的所有项;
  - 因为所有对应相同可选特征匹配案例的文档的得分掩码值相同, 所以这些文档都是可比较的; 于是服务器可以排序后选择匹配相同案例的topK的结果出来;
  - 定理3.2
    - 定理内容：令 $U$ 和 $V$ 分别表示可选特征匹配案例网格图(如Figure1)中的两个顶点, 且 $V$ 是 $U$ 的一个父亲节点(在Figure1中即 $U$ 指向 $V$ ), 在案例 $U$ 下的topK文档设为 $t o p K (U)$ , 对于任何匹配在 $U$ 中的文档 $d$ 且 $d\notin topK(U)$ , 则 $V$ 中的任意排在 $d$ 后面的等于 $d$ 的文档, 在案例 $V$ 下的都可以被安全地从 $V$ 中移除
    - 定理原文
      
      THEOREM 3.2
      Let U and V be two vertices in the lattice of optional feature matching cases and V is a parent node of U (V points to U in Figure 1). Let topK(U) be the top K documents matched under Case U. For any document d matched in U, and d < topK(U), any document in V ranked below d or equally under Case V can be removed safely from V.
  - 定理3.2揭示了Figure1这种网格图的一种性质, 从而可以移除掉案例中的一些不必要的结果;
  - 通过定理3.2这种基于网格图的抑制(suppression), 服务器将不同匹配案例下的top结果发送给客户端, 客户端进一步进行得分模糊(score deblinding, 这个是什么意思???), 最终得到topK的结果;
    - 备注: 猜测deblind应该是解盲的意思, de应该表示反向的意思, blind是蒙蔽的话, deblind就是解除蒙蔽的意思, 关键是根本没有deblind这个单词

使用块级运行(chunk-wide runtime)随机掩码的依赖查询(query-dependent)模糊(deblinding):

第1点中的均匀掩码策略允许服务端进行部分排序, 但是会导致以下两种类型的信息泄露:
- 给定两个来自相同特征掩码 $R$ 的文档 $d$ 和 $d^{\prime}$ , 服务器可以学习到他们的相对权重差异 $f^d-f^{d^{\prime}}$ , 即通过计算 $[f^d+R]-[f^{d^{\prime}}+R]$
  - 备注:
    - $[f^d+R]-[f^{d^{\prime}}+R] = (f^d+R)(mod\space N)-(f^{d^{\prime}}+R)(mod\space N) = (f^d-f^{d^{\prime}})(mod\space N)$
    - 两个文档的评分差值可能会暴露出一些相关性信息
- 服务器也可以使用 $\frac{[f^d+R]-[f^s+R]}{[f^{d^{\prime}}+R]-[f^s+R]}$ 来近似 $\frac{f^d}{f^{d^{\prime}}}$ , 其中 $f^s$ 是最小的特征值; 这样一种近似在 $f^s$ 刚好很小时是合理的(比如 $f^s=0$ );
  - 备注:
    - $\frac{[f^d+R]-[f^s+R]}{[f^{d^{\prime}}+R]-[f^s+R]}=\frac{f^d-f^s}{f^{d^{\prime}}-f^s}\approx \frac{f^d}{f^{d^{\prime}}}$
    - 两个文档的评分比值与差值泄露的信息大致类似, 特别地拥有这两个信息后就可以实际计算出两个文档的评分了
为使这两种信息泄露被限制到一个更小的范围内, 本文提出一种基于运行时查询选择(runtime query choice)的动态块级随机掩码策略(dynamic chunk-wide random masking strategy);
- 每个特征中会有一个包含非零特征值的文档编号的倒排索引项列表(posting list); 索引构建(index construction)将这个列表划分成块, 然后对于每个特征的随机掩码就是一个文档的独有掩码(specific mask)与一个块的独有掩码(chunk-specific mask)之和;
  - 备注: posting似乎有倒排索引项的意思, 摘自百度百科:
    
    倒排列表用来记录有哪些文档包含了某个单词, 一般在文档集合里会有很多文档包含某个单词, 每个文档会记录文档编号(DocID), 单词在这个文档中出现的次数(TF)及单词在文档中哪些位置出现过等信息, 这样与一个文档相关的信息被称做倒排索引项(Posting), 包含这个单词的一系列倒排索引项形成了列表结构, 这就是某个单词对应的倒排列表;
    - 这段话的意思可以理解为特征包含一个倒排索引项的列表(这个列表中的每个term所包含的文档具有非零特征值), 然后在建索引(数据库)时就会把这个列表分成若干块(我想是随机的), 每个特征的随机掩码由文档和块分别生成一个随机掩码加和得到;
- 在某次查询中, 服务端的部分排序被触发, 运行时查询处理(runtime query processing)将在相关特征中文档的独有掩码给移除; 在这种情况下对于相同的特征, 同一块中匹配的文档就会共享相同的掩码, 然后服务器就可以对在同一块下匹配的文档进行排序;
仅当匹配结果可能会潜在地超过一个阈值(如带宽或响应时间), 客户端触发服务端的部分排序; 为了监测这种情况, 可以称一个特征是流行的(popuplar), 当这个包含这个特征(有非零值)的文档总数超过一个流行性(popularity)阈值, 否则称该特征是不流行的(unpopular); 当一次查询中的必选特征之一是不流行的, 匹配到的结果不会超过上述阈值(指带宽或响应时间);

查询分解(query decomposition):

紧跟着上面的设计, 给定一个特征的文档列表, 将列表排序后, 我们把这个列表分解成一块一块的集合, 注意这个分解确保同一文档编号不会出现在不同集合中;
- 备注: 根据下面的Figure2这里的特征可以理解为**{match:“CD”}或是{term:“CD”}**
概念上, 我们将每个特征编号视为一个项(term), 每个块视为原始项(original term)的一个子项(subterm)
- 备注: 特征就是词语, 每个块是原始词语的子词语, 这个不是很能理解, 根据下面的Figure2来看一个块应该是一个文档的集合才对;
Figure2: (a)分块(chunking)例子; (b)客户端对于查询分解的范围交叉(range intersection)
Figure2(a)给了一个特征分块(feature chunking)和查询内容是CD rate的查询分解的例子:
- 备注: 可以看到Figure2(a)中每个块并非是连续的数字, 但是在Figure(b)中每个块都表示成了块中最小值到最大值的区间, 理解是不是分块的目的是为了加快寻找查询分解后每个特征对应文档交叉区间? 无法理解范围交叉(range intersection)为何是7-25, 后面的36和41也属于交叉却没有被包含进来;
- 被添加的可选单词对特征(optional word-pair feature)是CD-rate;
- CD的倒排索引项(posting)被分解成4块, 对应4个子项(subterm): $a_1,a_2,a_3,a_4$
  - 备注: posting仍然是倒排索引项的意思, 所以这里的块是文档编号的集合;
- rate的倒排索引项被分解成5块, 对应5个子项(subterm): $b_1,b_2,b_3,b_4,b_5$
- 类似地, 基于文档编码范围分区(range partitioning), 可选特征CD rate的文档列表被分解成唯一的块 $c_1$
  - 范围分区: 就是根据数据库表中某一字段的值的范围来划分分区, 下面是sql的范围分区代码示例:
```
create table graderecord  
  (  
  sno varchar2(10),  
  sname varchar2(20),  
  dormitory varchar2(3),  
  grade int  
)  
partition by range(grade)  
(  
  partition bujige values less than(60), --不及格  
  partition jige values less than(85), --及格  
  partition youxiu values less than(maxvalue) --优秀  
)  
```
在知道倒排索引项块(posting chunks)的编号范围(ID ranges)的情况下, 客户端可以执行一个更早的范围交点(earlier range intersection), 然后将这个原始查询(original query)分解成一个子查询(subqueries)的集合; 任何匹配子查询的文档满足原始查询;
- 备注: 分别去找匹配子查询结果的文档, 类似elasticsearch中的最细粒度划分搜索;
在Figure2(b)中, 客户端可以学习到只有文档编号在 $(6, 13), (24, 26), (36, 44)$ 的是可能包含所有必选关键词, 等价于原始查询CD rate被转化成隔离的4个子查询:
- ① 带有可选 $c_1$ 的 $a_1b_2$
- ② 带有可选 $c_1$ 的 $a_3b_3$
- ③ $a_4b_4$
- ④ $a_4b_5$
- 备注:
  - 可选$ $c_i$ 的意思是同时匹配两个特征的特征是可选的???
除了服务端的部分排序外, 注意到被提出的客户端查询分解有以下两个额外的好处:
- ① 正如我们在前一节讨论的那样, 特征获取(feature access)是通过哈希表查找来实现的;
  - 查询分解利用地点感知的(locality-aware)数据划分(data partitioning), 于是减少了在交叉(intersection)与特征查找过程加载哈希表相关部分的内存占用空间;
    - 备注: 第二节第4点中有
      
      加密文档特征就会被用一个经过哈希映射的文档编号检索出来;
  - 我们也已经考虑过避免对数据划分的地点(locality)过度利用, 因为隐私权衡(privacy tradeoff)会阻止对数据访问操作;
    - 备注: 划分点可能会泄露一些文档特征信息, 你说什么就是什么吧…
- ② 一个交点算法(intersection algorithm)选择一个必选特征来开始枚举可能的候选文档, 典型情况下, 这是一个拥有最小倒排索引项长度(posting length)的特征, 这称为OXT(参考文献17)中的一个 $s$ 项( $s$ -term)
  - 备注: 以Figure2来看, 就是从CD开始枚举, 然后CD的倒排索引是比rate短的(肯定是遍历短的去匹配长的);
  - 在OXT中, 服务器确实地在交叉(intersection)过程中学习到对于每个查询的 $s$ 项的倒排索引项长度;
- 服务器在处理许多查询后积累了大量信息, 就可能给泄露滥用攻击(leakage-abuse attacks)开后门, 一种对抗措施是通过添加虚假(bogus)编号对倒排索引项(posting)进行填充(padding), 就可以伪装真实的计数值(true counts);
  - 备注: 服务器在多词范围交叉中肯定能知道哪些文档会同时包含哪些加密特征, 根据统计分布信息是有可能破解加密的, 通过在倒排索引项里添加虚假编号可以改变先验统计分布, 减少被破解的可能性, 这里所谓的true counts应该就是上面的匹配块的数量;
- 在本文的设定中, 因为一次查询可以被分解成一个子查询序列, 客户端可以选择一个彼此不同于子查询的起始特征(a start feature differently from one subquery to another, 本质上是 $s$ -term, 那个最短的倒排索引的词语), 就可以大大减少泄露单个单词倒排索引项长度(posting length)的可能性;
  - 备注: 起始特征不一样, 匹配块的结果也不一样, 比如在Figure2里按照rate来划分的话, 应该 $b_2,b_3,b_4,b_5$ 这样的了;

通过限制可选特征数量来权衡(tradeoff):

在下一节中, 服务器使用一个位图记录(bitmap record)来存储每个文档匹配到的可选特征, 因此有大量可选特征会导致两个劣势:
- ① 保持一个长位图的空间开销;
- ② 基于在上文中的网格(lattice)讨论, 服务端会有更少的可比较的匹配结果;
- 这两个劣势因素会导致更多的C/S通信开销, 比如发回部分排序的结果;
当单词对(word pair)被用作原始文本邻近特征(raw text proximity features)时, 为了减少单词对的总数, 我们合并出现在文档中不同章节的单词对权重;
- 根据参考文献8的研究, 索引可以强加上一个限制, 这个限制就是一个单词对是包含在索引中仅当这个单词对的单词距离(word distance)在一个限制距离内;
- 我们的评估中使用限制距离为3来处理三个测试数据集;
- 在运行时, 给定一次查询的 $q$ 个单词, 将有 $C_q^2$ 个单词对, 且如果我们令 $m=C_q^2$ , 就会有 $2^{C_q^2}$ 个网格案例(lattice cases)使用了这些单词对特征;
  - 举例: 当 $q = 5$ , 就会有 $2^{10}$ 个案例, 当 $q = 7$ , 就会有 $2^{21}$ 个案例;
- 我们强加一个限制, 要求客户端在查询中仅仅需求那些在限制距离 $L$ 以内的可选单词对;
  - 举例: 5个单词的查询 $w_1,w_2,w_3,w_4,w_5$ , 限制距离 $L = 2$ , 则只有单词对 $(w 1, w 2), (w 1, w 3), (w 2, w 3), (w 2, w 4), (w 3, w 4), (w 3, w 5), (w 4, w 5)$ 会被当作可选特征;
  - 总体来说基于单词对的可选特征数 $m$ 从 $C_q^2$ 减少到 $C_L^2+L(q-L)$ , 其中 $q\ge L$ , 当 $q\lt L$ 时本身可选特征数 $m$ 就很小, 无需限制; 当我们选择 $L = 2$ 则 $m = 2 q - 3$ , 第五节中证明了 $L = 2$ 的关联在测试集上可以接受的一个限制距离; 在实际情况下, 可以假设 $q\lt 10$ , 因为对更长的查询进行简单修剪一般不会影响其关联性; 于是可以得到 $m\lt 15$ , 当可选特征仅基于单词对;
  - 在一些应用中额外的可选项可能会被考虑进来用于改善排序关联性, 比如文档的新鲜度(freshness)与权威性(authoritativeness), 因此 $m$ 一般会小于24, 本文在评估中为可选位图(optional bitmap)分配3bytes空间;

第四节索引与查询处理 INDEXING AND QUERYPROCESSING

在本节中我们将在文档匹配中采用OXT可搜索加密(参考文献16和17), 然后扩展它用于排序; 我们展示一个索引和查询处理schema来支撑被动态块级随机掩码蒙蔽的特征, 并且使得客户端能够安全地触发服务端对于选好的包含流行(popular)特征的查询的部分排序; 该设计防止服务器学习到关于特征和一个加密单词的倒排索引(posting)的任何信息, 只要这个单词从未被搜索过;

摘自参考文献16: Searchable symmetric encryption (SSE) allows one to store data at an untrusted server and later search the data for records (or documents) matching a given keyword while maintaining privacy. Many recent works [4–6,8,10,15,16,18,20,22] studied SSE and provided solutions with varying trade-offs between security, efficiency, and the ability to securely update the data after it has been encrypted and uploaded. These constructions aim at practical efficiency, in contrast to generic cryptographic tools like homomorphic encryption or multiparty computation which are highly secure but not likely to be efficient in practice soon.

数据结构与高层级的搜索流程(search flow):

本文的搜索流程包含3个键值对存储:
- ① $R$ 存储: 保存特征倒排索引项块(feature posting chunks)中的元信息, 如块的文档编号范围(document ID range of chunks), 这可以促进客户端的查询分解;
  - 备注: $R$ 存储我理解就是倒排索引表, 可能在每行中加了一些额外的信息;
- ② $S$ 存储: 包含必选特征值, 且被搜索算法使用来确定候选文档;
  - 备注: 对比上面提到的 $s$ -term
- ③ $X$ 存储: 包含可以用一对文档编号和特征编号来访问的特征值;
  - 备注: 用于查询一个文档中某特征的值;
搜索流程详解:
- 给定一次查询, 客户端使用 $R$ 存储将它转化成一个子查询序列;
  - 备注: 应该就是Figure(a)这种倒排索引表
- 对于每个子查询, 客户端生成 $n$ 个必选和可选特征编号, 标记为 $w_1,w_2,...,w_n$ , 给服务器来匹配文档然后取回(fetch)它们的特征;
- 令 $d$ 是出现在起始特征 $w_1$ 的倒排索引项列表(posting list)中的候选一个文档编号, 为了取回 $d$ 的另一个特征 $w_i,i\le i\le n$ , 线上算法将两个编号 $w_i$ 和 $d$ 配对在一起作为访问 $X$ 存储的钥匙;
- Table1: 函数与算子标志
  - 备注:
    - ① 字节拼接符号
    - ② 密钥为 $k$ 的确定性伪随机函数(SHA256)
    - ③ 密钥为 $k$ 的非确定性的对称密码加密(AES)
    - ④ 密钥为 $k$ 的对称密码解密
    - ⑤ 用 $s t a g$ 查询 $S$ 存储, 返回结果是一块加密特征的倒排索引
    - ⑥ 用 $x t a g$ 查询 $X$ 存储, 返回查询的特征值
    - ⑦ $x_1,x_2,...,x_n$
- 为了保全隐私, 所有编号和中间值(intermediate values)将被哈希映射或直接用Table1中总结的算子和函数来加密, 于是对于任何特征名称与文档编号, 服务器未经客户端许可, 就不能从一个托管的(hosted) $X$ 存储和 $R$ 存储中访问倒排索引项列表(posting list)或是特征值; 服务器不应当在线上搜索中学习到查询项(query terms)的身份(identity);

加密倒排索引(inverted index)的建立:

由特征向量创建的输入数据被转换成一个倒排索引的格式, 索引创建者(indexer)被客户端控制, 构建加密索引并令服务器托管(host) $S$ 存储和 $X$ 存储; 对于文档 $d$ 的每个值为 $f$ 的特征 $w$ , 索引创建者为 $X$ 存储建立一个如下的键值对:
- 定义 $p$ 为 $d$ 在倒排索引项(posting)中的位置计数(position count), $c = f l o o r (p / c s i z e)$ 是块编号(floor是向下取整函数), 其中 $c s i z e$ 是块大小(chunk size);
  - 备注: 如块大小为5, 第37个位置的块编号就是37//5=7
- 键: $xtag=g^{PRF(k_5,w)PRF(k_2,d)}$
  - $k_5$ 和 $k_2$ 是加密哈希键;
  - 底数 $g$ 是一个用于伪随机映射的Diffie-Hellman常数(参考文献10);
  - 备注:
    
    摘自百度百科: Diffie-Hellman是一种确保共享密钥安全穿越不安全网络的方法, 它是OAKLEY的一个组成部分; Whitefield与Martin Hellman在1976年提出了一个奇妙的密钥交换协议, 称为Diffie-Hellman密钥交换协议/算法(Diffie-Hellman Key Exchange/Agreement Algorithm), 这个机制的巧妙在于需要安全通信的双方可以用这个方法确定对称密钥; 然后可以用这个密钥进行加密和解密; 但是注意, 这个密钥交换协议/算法只能用于密钥的交换, 而不能进行消息的加密和解密; 双方确定要用的密钥后, 要使用其他对称密钥操作加密算法实现加密和解密消息;
    - 相当于查询 $X$ 存储的文档编号和特征编号都会被加密然后用密钥交换方法传递过去, 因为离散对数困难性, 所以无法解出 $PRF(k_5,w)PRF(k_2,d)$ 的确切值;
- 值: $S(xtag)=(f+R_c+R_x)(mod\space N)$
  - $R_x=PRF(k_u,g^{PRF(k_5,w)PRF(k_2,d)})$ , 代表块独有掩码;
  - $R_c=PRF(k_0,w||c)$ , 代表文档独有掩码;
- 备注:
  - 键值都需要被加密好再添加到 $X$ 存储中
  - 键加密基于离散对数, 值加密为[特征值 + 键的随机数 + 块编码和文档编码的随机数]
当上述的特征是必选的, 则 $d$ 和 $f$ 值也都被保存在文档 $w$ 的倒排索引项的块(posting chunk) $c$ 里, 存储在 $S$ 存储中; 对应的 $S$ 存储键为 $stag=PRF(k_7,w||c)$ , 对应的值为倒排索引项条目的块列表(chunk list of posting entries), 每个倒排索引项条目是一个加密的 $e,y,f_s)$ 三元组, 定义如下:
- $e=E(k_e,d)$ 用于表示加密文档编号 $d$ , $e$ 的加密是语义安全的(semantically secure), 因此服务器不能学习到除原始文档编号长度外的任何信息;
- $y=PRF(k_4,w||p)^{-1}PRF(k_2,d)$ 是一个蒙蔽的桥接数字(bridging number), 它用于在交叉过程(intersection)中为了取得访问 $X$ 存储的钥匙, $w$ 被选择成一个初始特征(参考文献17中提到的交叉过程)时; 本文扩展 $y$ 的用法, 即用于选取特征(feature fetching), 这将在下面的例子中详细阐述;
- $f_s=(u_d+f+R_c+R_s)(mod\space N)$ 是蒙蔽特征(blinded feature), 其中 $u_d$ 是文档独有的第四类特征权重之和(在第二节中提到, 即新鲜度之类的特征), $R_s=PRF(k_3,w||p)$ 是文档独有掩码;
- 备注: 这个三元组似乎不是很好理解, $p$ 是位置计数, 我理解 $e$ 就是加密的文档编号, $y$ 就是用于查询 $X$ 存储中特征值的键, $f_s$ 就是加密后的特征值;

线上搜索步骤:

Figure3的伪代码展示了查询处理的三阶段:
- Figure3: TopK搜索
- 阶段一: 客户端的查询处理
  - 备注: Figure3中的算法解释:
    - 建立查询词语(query terms), 分解查询, 使得服务端部分排序可行;
    - 对于每个子查询, 将 $S$ 存储的键 $s t a g$ , 解密的密钥 $s k e y$ , 标记数组 $t o k e n s$ , 相关起始特征掩码 $R_s$ (这个好像是上面提到的文档独有掩码), 发送给服务器;
  - 为一个给定的查询构建必选和可选特征, 并执行一个更早的范围交叉(earlier range intersection)来获得经过 $R$ 存储查找后的子查询;
  - 假设每个子查询有 $n$ 个特征, 并带有 $n$ 个对应的块编号 $w_i,c_i)_{i=1}^n$ , 其中 $w_i$ 是特征, $c_i$ 是块编号;
  - 在这个特征序列里, 所有必选特征都要放置在可选特征的前面, 其中 $w_1$ 是被选来作为起始的必选特征;
  - 然后访问 $S$ 存储的键(key)就是 $stag=PRF(k_7,w_1||c_1)$ , 这个在服务器里用来解密倒排索引项(posting) $S (s t a g)$ 的条目的密钥(key)就是 $skey=PRF(k_6,w_1||c_1)$
  - 此外, 客户端给服务器建立一个特殊的2维标记(token)数组, 每个数组元素 $t o k e n s [i] [j]$ 定义为:
    - $xtoken_i=g^{PRF(k_5,w_i)PRF(k_4,w_1||p)}$
    - $mtoken_i=g^{PRF(k_1,w_i)PRF(k_4,w_1||p)}$
    - 其中 $2\le i\le n$ , $1\le j\le csize$ , $c s i z e$ 是块大小;
    - 备注: 这个标记数组的维度是[特征数×块数], 就是表示Figure2中的每块, 然后在每个块里放入当前[特征+起始特征+位置计数]的加密结果, $xtoken_i$ 其实是可以用于访问 $X$ 存储的, $mtoken_i$ 将用来生成随机掩码 $R_x$ ;
  - 倒排索引项位置(posting position) $p=c_1*csize+j$
  - 起始特征对应的文档独有掩码(document specific mask) $R_s=PRF(k_3,w_1||p)$
    - 备注: 这边几个结果都是套用本节第2点里的公式;
  - 若预测的结果长度不超过某个阈值, 客户端将不会打开服务端的结果过滤, 在这种情况下, 每个标记数组元素的第二个条目 $mtoken_i$ 与 $R_s$ 信息都宣布无效作废, 在需要的情况下, 最终客户端将 $s t a g$ , $s k e y$ 和整个标记数组, 相关掩码(related mask) $R_s$ 一起发送给服务器, 用于上面提到的子查询;
    - 备注: 显然这些信息都是经过伪随机数生成器加密过的, 服务器无法攻破;
- 阶段二: 服务端的子查询处理评分
  - 备注: Figure3中的算法解释:
    - 服务器收到一个子查询的 $stag,skey,R_s,tokens$
    - 遍历 $S (s t a g)$ 返回的倒排索引块里满足 $1\le j\le csize$ 的每个条目 $Z$ , 执行以下逻辑:
      - 解密三元组 $e,y,f_s)=D(skey,Z)$
      - 初始化得分 $F=f_s$ , 初始化一个位图 $O$
      - 若允许部分排序则令 $F\leftarrow (f_s-R_s)(mod\space N)$
      - 遍历标记数组 $t o k e n s$ , $i = 2, 3, . . ., n$ , 得到每个 $xtoken_i,mtoken_i)$ , 执行如下操作:
        $xtag_i\leftarrow xtoken_i^y$
        若 $X(xtag_i)$ 不存在且 $w_i$ 是必选特征, 则跳过该文档;
        若 $X(xtag_i)$ 存在则将 $i$ 加入到可选特征位图 $O$ 中:
        若允许部分排序则令:
        特征掩码 $R_x\leftarrow PRF(k_u,mtoken_i^y)$
        更新得分 $F=(F+X(xtag_i)-R_x)(mod\space N)$
        
        否则令: $F=(F+X(xtag_i))(mod\space N)$
      - 将四元组 $(e, F, O, j)$ 加入到结果列表中
    - 若允许部分排序则在可选位图 $O$ 中选出topK的结果, 丢弃掉不必要的结果;
    - 将匹配文档以 $(e, F, O, j)$ 的列表格式返送给客户端;
    - 重复该流程对于每个子查询;
  - 服务器在接收到每个子查询的控制信息后, 基于函数 $S (s t a g)$ 调用, 从 $S$ 存储中取出 $w_1$ 的倒排索引项(posting);
  - 对于每个特征 $w_1$ 的倒排索引项条目(posting entry, 假设是第 $j$ 个条目), 和第 $i$ 个其他特征, 服务器在需要的时候就使用接收到的标记数组 $t o k e n s [i] [j]$ 来计算 $x t a g$ , 从而可以访问 $X$ 存储和文档独有掩码 $R_x$ ; 同样在需要的时候服务器可以通过掩码减法(mask substraction)来累积排序得分(如Figure3的第21行);
    - 即 $m t o k e n$ 就是用来给服务器计算掩码并消除使用的, 在部分排序的情况下;
  - 当部分排序启动, 在每个可选特征网格案例下的文档得分就会被比较然后过滤, 最终每个案例至多返回排序最高的K个结果; 对于每个从服务器发送回客户端的匹配文档, 结果四元组的格式为 $(e, F, O, j)$
    - $e$ 表示一个加密的文档编号;
    - $F$ 表示一个加密得分;
    - $O$ 表示一个在使用了的可选特征上的位图(a bitmap on the the optional features used);
      - 备注: 上面已经提到, 位图的作用就是判断某个元素是否存在, $O$ 可以告诉客户端哪些可选特征被使用了;
    - $j$ 表示文档出现在 $w_1$ 的倒排索引项块(posting chunk)中的位置;
- 阶段三: 客户端的后处理
  - 备注: Figure3中的算法解释:
    - 对于每个从服务器收到的结果列表 $(e, F, O, j)$ , 执行以下逻辑:
      - 客户端解密文档编号并减去排序得分中的掩码值;
    - 排序结果列表并选取topK的结果;
  - 这一步是移除得分掩码(score masks)和比较所有接收到的文档并最终选出topK的结果;
  - Figure4: C/S查询处理样例
  - Figure4中给了查询CD rate运行时处理的样例(带有可选项CD-rate):
    - 查询分解后, 子查询生成, 假设CD是这次子查询的起始特征, 对于这次特征的倒排索引项块 $c$ , 访问 $S$ 存储的钥匙就是 $s t a g = P R F (k, " C D " ∣ c)$
    - 访问 $S$ 存储后, 假设 $d$ 是一个从带有对应三元组 $e,y,f_s)$ 的CD倒排索引项中找到的候选文档; 为了进一步访问 $X$ 存储以得到特征rate, 服务器计算访问的钥匙 $xtag=xtoken_2^y$ 与 $R_x=PRF(k_u,mtoken_2^y)$ , 因为基于索引建立算法, 有 $y=PRF(k_4,"CD"||p)^{-1}PRF(k_2,d)$ , 我们可以核实服务器确实获得了相同的值 $xtag=g^{PRF(k_5,"rate")PRF(k_2,d)}$ 与 $R_x=PRF(k_u,g^{PRF(k_1,"rate")PRF(k_2,d)})$ , 这就在建立 $X$ 存储上匹配到了索引建立算法;
    - 这意味着无需知道 $k_1,k_2,k_5$ 的值, 服务器也可以在查询独有认证信息(query-specific authorization information, 如标记数组被客户端签发, token array is issued by the client)之后, 成功取到和加上单词rate的特征权重;
- 总结:
  - 相当于客户端需要确定查询关键词, 分解查询关键词, 确保服务端能部分排序, 然后把访问 $S$ 存储的键, 解密 $S$ 存储值的密钥, 访问 $X$ 存储的 $x t o k e n$ , 计算掩码的 $m t o k e n$ , 以及起始特征 $R_s$ 都以 $P R F$ 加密后送给服务器;
  - 服务器计算文档得分, 并在可能的时候进行部分排序(此时需要用到 $m t o k e n$ 来去除随即掩码 $R_x$ ), 最后把每个匹配的文档编号(加密), 得分(加密), 用了哪些可选特征(位图), 和这个文档在倒排索引表里的位置都发回给客户端;
  - 客户端解密文档编号和得分做最后的topK选取;

搜索复杂度:

加密后的索引空间开销与非零可选特征值总和 $+$ 必选特征编号的数量 $*$ 文档总数成正比;
- 必选特征编号的数量 $*$ 文档总数很好理解, 就是Figure2(a)
- 再加上可选特征;
加密后的数字因为具有随机性所以无法很好地被压缩;
对于一个有 $n$ 个特征的查询, 令 $\sum(Posting(w_1))$ 表示每个子查询的起始特征的倒排索引项长度(posting length)之和, 则这次查询的时间成本为 $O((n-1)\sum|Posting(w_1)|)$ , 这要比参考文献19中的方法要慢, 因为后者不需要考虑隐私保全, 而前者代表了对私有性查询的权衡;

查询处理的性质与泄露讨论:

本文展示一个更加正式的最坏案例泄露情况分析(详见附录A), 本文schema的两个私有性性质如下所示:
- ① 定理4.1: 如果一个特征编号从未被在任何查询中使用, 服务器就不能学习到任何文档中这个特征对应的权重;
- ② 定理4.2: 查询处理过程中及之后, 对于任何不流行(unpopular)单词, 服务器不能学习到文档的特征权重; 这对于任何涉及至少一个不流行的必选单词的搜索查询中的任何流行(popular)单词也是正确的;
以上两个定理证明了如果一个特征从未出现在任何过去搜索查询历史中(比如一个从未被搜索查询过的单词), 服务器就不能探查出它的特征值以及在任何文档中学习到关于这个特征的任何泄露信息;
在查询处理中, 如果一个查询不能触发部分排序(比如该查询涉及至少一个不流行的单词), 服务器就不能学习到关于特征的信息或是每个文档的最终得分;
本文评估中, 块级掩码(chunk-wide masks)为10000, 以下5个数据集中流行单词的比例如下所示:
- CSIRO: 0.07%
- TREC45: 0.31%
- Aquaint: 0.47%
- Clueweb: 0.07%
- Enron: 0.1%
当服务端结果过滤被触发, 即查询仅涉及到这些流行单词, 就会有一些排名顺序和块级特征差异的泄露, 这些在第三节有所讨论, 并且在附录A中将会更加详细的讨论; 为了将这种泄露限制到一个更小的范围, 一种策略是使得相对比率(块大小除以倒排索引项长度阈值)尽可能地小; 在我们的测试数据集中, 这种比率被调整到了2.1%, 块大小为210, 因为这只是对出现在超过10000个文档中的单词;
- 备注: 我理解是部分排序时会触发 $m t o k e n$ 使用, 去除了特征随机掩码 $R_x$ , 所以服务器会知道一些排名顺序和每个块上特征的差异(部分排序应该是发生在块内的), 如果将每个块尽量缩小, 那么部分排序本质上仅仅是少数文档间的比较, 服务器获得的信息是有限的;

第五节评估 EVALUATION

实现与数据集:

本文研究使用C++实现原型系统, 实验环境为八核2.4GHz AMD FX8320, 16GB内存的Linux Ubuntu 16.04服务器, 代码用optimization flag -O3编译;
本文使用的数据集:
- ① TREC Disk 4&5 数据集(TREC Robust 2004 topics 301-450 & 601-700);
- ② CSIRO 数据集(TREC 2008 Enterprise Track Topics CE051-CE127 queries)
- ③ Aquaint 数据集(TREC Robust 2005 query set of 50 topics)
- Table2: 数据集的规模特征
- Table2中总结了这3个数据集的关键特征(经过索引生成后):
  - 第2行为文档总数;
  - 第3行为项(term)与文档编号成对的数量;
    - 备注: 单词与文档的配对(倒排索引??)
  - 第4行为合成项(composite)与文档编号成对的数量;
    - 由两个单词组成的可选项(如果这两个单词出现在一个文档中且距离为9)出现在 $X$ 存储中, 注意加密的索引大小就来自这些可选项, 如果更低的排序相关度是可以接受的, 则距离限制是可以被显著减少, 因为 $X$ 存储的规模是与文档——特征对总数成正比的;
  - 第5, 6, 7行是 $R$ 存储, $R$ 存储, $X$ 存储的字节大小;
  - 第8行是索引占用的总字节大小;
- 因为本文运行实验的机器是共享在云环境中, 我们控制搜索内存耗用在每个机器2GB以内; 由于存在内存限制, 我们选择只给CSIRO1个服务器, 而给Aquaint和TREC45分配8和5个服务器; 交叉(intersection)与得分累积在这些服务器上是并行的; 在本节结束时, 我们也会展示对于更大的数据集Clueweb和Enron电子邮件数据集上的调研结果;
实现过程中的几个点:
- 对于每个文档, 本文选择那些在文本排序(基于参考文献[8,12,41,42,49])中表现得好的特征;
- 本文基于BM25系数区分单词出现的位置(如出现在标题或是主体), 来生成文档包含的单词的特征值;
  - 备注: BM25见https://www.jianshu.com/p/b4f06594d32f
- 本文也基于出现在同一文档中且处于距离限制内的单词对, 计算了可选特征值;
  - 备注: 指单词对(wordpair);
- 如果这样一个单词对出现在文档的标题与主体中, 每个单词对的特征值是基于单词距离的平方逆(square inverse);
  - 备注: 特征值可以理解为权重, 单词距离越远, 权重越小;
- 本文使用AdaRank来引导特征加权(feature weighting)与基于3折交叉检验进行关联型评估(relevance evaluation);
  - 备注: Adarank跟Adaboost紧密联系, 是机器学习在排序中的用法, http://blog.sina.com.cn/s/blog_740773f40100vy8c.html
- 注意到在联合查询需求(conjunctive query requirement)下, 我们的文档匹配检索相比于分隔假设(disjunctive assumption)可能会遗漏一些查询中已标注的关联结果, 在一些案例中这将会导致10%的关联性差异;
  - 备注: 意思可能是限制单词对距离后可能会遗漏一些匹配结果?
每个从服务器返回的文档结果平均使用大约16bytes, 包括8-byte的加密文档编号, 4-byte的蒙蔽得分(blinded score), 3-byte的位图(bitmap), 1-byted的位置; 本文选择结果大小阈值(result size threshold)为10000, 这个阈值用于触发服务端的部分排序; 注意到全球互联网平均连接速度已经接近7.2Mbps(2017年), 在这个平均连接速度下, 只需要0.18秒就可以传输10000个大小为16bytes匹配结果;

多词搜索时间:

Table3: 三个数据集的查询处理开销
Table3列出了当搜索单词数量变化时, 平均搜索响应时间, 与开销明细(cost breakdown)的变化;
- 在本文设定中, $X$ 存储有1024个分区(partition);
- 一次查询响应时间包括:
  - 客户端开销: 包括 $R$ 存储交叉(intersection)与第一个子查询的标记生成(token generation), 然后服务器一旦接收到就开始尽快搜索;
    - 注意到Table3中当 $q = 1$ 时, 则 $X$ 存储操作是没有开销的, 从表中可以看到单词和多词查询的平均开销差异;
      - 备注: 单个单词查询时, 不存在查询分解, 直接把这个单词对应的特征的倒排索引项拉出来就完事了;
    - 当 $q$ 从2增加到3时, $X$ 存储的开销随着增加更多可选特征被包含进来而增加;
    - 但是当 $q$ 为4-5时, 在更早的范围交叉(earlier range intersection)后, 从 $S$ 存储中找到的候选文档变少了, 且 $X$ 存储时间在三个查询集合上都下降了;
    - 客户端开销是适中的, 在三个数据集上都随着查询单词增多而增加, 因为查询单词增多会导致在范围交叉和 $x t o k e n$ 生成的开销增加, 计算 $x$ -token的开销增加是相当显著的, 这是一个指数级增加的速度;
  - 服务端查找 $S$ 存储取得候选文档的开销;
  - 服务端查找 $X$ 存储取得交叉(intersection)和得分累积(score accumulation)的开销;
Table4: 搜索时间中倒排索引项长度的影响
Table4列出了五种查询倒排索引项长度(posting length)的平均搜索响应时间; 基于子查询的起始特征倒排索引项长度之和, 每个查询落到一个列中, Table4验证了查询响应时间是近似正比于第四节中讨论的所有子查询中选出的起始特征倒排索引项长度之和;
- 备注: 第四节第4点中关于时间复杂度的阐述;

与baseline的比较:

基于矩阵变换(参考文献13和45, 这两个文献的机器资源配置与本文是相同), 本文也实现并评估了baseline方法, 在3个数据集上的耗时如下:
- CSIRO: 1台机器超过48小时, 前向索引(forward index)空间开销105TB;
- TREC45: 5台机器超过26小时, 前向索引(forward index)空间开销285TB;
- Aquaint: 8台机器超过46小时, 前向索引(forward index)空间开销815TB;
- 空间开销很大是因为特征向量是稠密的(非稀疏), 且特征数量 $T$ 的数量非常大, 三个数据集上分别是39M, 73M, 108M;
当我们把线下单词对距离限制从10减到3, 特征数量 $T$ 近似平均较少了一半, 上述的开销也缩减了一半;
本文的方法相比于baseline仍然要快上几个数量级(积累一个挺fancy的英文表达: several orders of magnitude faster);
参考文献45中讨论了一个使用树搜索的优化来加速相似度计算, 平均复杂度可以到 $O(T\log D)$ , 但是最坏情况的复杂度要到 $O (T D)$ , 其中 $D$ 是文档的总数;

查询分解的影响:

带块状倒排索引项(chunked postings)的查询分解使得更早的范围交叉(earlier range intersection), $S$ 存储和 $X$ 存储的地点感知划分(locality-aware partition)成为可能;
- 对于查询分解中更早的范围交叉, 本文发现交叉范围在CSIRO, TREC45, Aquaint上分别缩减了6%, 12%, 21%;
- 相较于1024个划分, 在没有 $X$ 存储划分的情况下, 搜索查询关键词为2, 3, 4-5的三种情况中速度大约分别慢了42.5x, 17x, 19.1x;
  - 备注: x是时间单位吗?
- 因此上述的分解对于支持低查询响应时间是极其重要的;

服务器部分排序的效用(effectiveness):

所有154 TREC查询(不经过topK过滤)从服务器返回结果的平均数量在CSIRO, TREC45, Aquaint上分别为849, 5490, 5704;
Table5: top-10搜索, 阈值10000, 返回结果缩减情况
Table5展示了对于top-10搜索的结果平均数量, 触发部分排序的阈值正如上文所述为10000;
- 备注: Nofilter其实就是块大小为1, 那么显然块越大, 返回结果越少;
- 第3列是23 TREC查询返回结果的平均数量, 这些23 TREC查询是触发了部分排序, 且倒排索引项块(posting chunk)大小分别是105和210;
- 标记成 $N o f i l t e r$ 的行是指那些设置成不适用服务端部分排序的搜索;
- 对于Aquaint数据集, 有13 TREC查询触发结果过滤, 在过滤掉51%的匹配结果后, 块大小210的情况下, 平均返回16112个结果;
- 对于更大的块大小, 在每个子查询中将有更多可比较的匹配文档, 并且也有更多的结果会在部分排序中被过滤掉;
- 为了验证极端情况, 第四列在每个数据集上基于流行词(popular words)和停词(stop words)的构建, 处理了15个综合查询(synthetic queries), 得到了多得多的返回结果; 部分排序schema也能够过滤掉更多不必要的返回结果; 就Aquaint数据集而言, 对于综合查询服务器在过滤掉所有匹配结果中的87.9%后, 平均返回了22437个结果, 在这个案例中, 以全球互联网平均连接速度7.2Mbps来计算大约耗时0.39秒;

线性累积评分与可选项数量的关联性影响:

Table6: 不同单词对数量的关联性
Table6解释了在不同查询单词距离限制( $L=2,5,\infty$ )下, 三个数据集在两种模型(线性模型与LambdaMART模型, 后者参考文献44)上的NDCG@10得分情况;
- 距离限制没有对表现产生明显的负作用, 相较于LambdaMART, 线性评分模型有合理的表现(decent performance);

ClueWeb数据集:

本文也调研了我们的schema在处理更大的数据集上的表现, 这里以使用ClueWeb09 Category B数据集(参考文献6), 该数据集包含5000万个网络文档, 相关原始特征包括BM25加权的单个单词权重, 出现在标题和主体中的单词对, 以及文档的页码排序得分(PageRank scores);
2011年的Web TREC竞赛里排名第一的队伍已经完成了0.24282的NDCG@20得分(参考文献11), 他们使用的是TREC 2011 Queries加上从Million Query(MQ) TREC 2009(参考文献14)的684个查询里挑选出的450个查询;
LambdaMART使用的是我们的原始特征, 取得了NDCG@20得分0.2547, 0.2554, 0.2601在查询单词距离限制是 $L=2,5,\infty$ 的情况下;
本文的累积排序schema取得了0.2512, 0.2530, 0.2585在查询单词距离限制是 $L=2,5,\infty$ 的情况下;
对于ClueWeb数据的搜索时间仍然是合理的, 因为客户端查询处理不需要很大的内存, 服务端可以使用更多的机器来分布 $S$ 存储和 $X$ 存储以达到并行效果;
C/S通信开销是一个关键因素, 于是我们选择这个ClubWeb数据集的几个不同子集来评估数据集大小变化对于服务端部分排序的影响:
- Table7: top-10搜索, 阈值10000, 在ClubWeb子集大小从3M变化到50M时返回结果的数量变化
- 对于从MQ TREC 2009中的684个带有判断标签(judgment labels)的查询, Table7列出了返回结果的平均数量;
  - 第3行到第4行是两个不同块大小的情况;
  - 第6行和第7行展示了占查询结果前10%服务端过滤后的平均返回结果数量;
  - 当数据集大小为5M, 块大小为210时, 服务器发回给客户端25394个结果大约耗时0.46秒(在7.2Mbps的网速下), 最慢的10%的查询会耗时1.93秒来发回107195个结果; 注意到顶尖的国家平均网络连接速度是28.6Mbps(参考文献3), 那么这107195个结果仅仅需要0.486秒即可完成传输;

Enron电子邮件数据集:

本文也研究了Enron数据集, 这个数据集由150个用户合作收集的大约50万封邮件构成; 该数据集中平均的单词倒排索引项长度是65, 其中0.1%的单词是流行词;
与其他已经研究了的数据集一样, 倒排索引项长度服从一个长尾的Zipf分布;
我们使用从邮件中收集到的100个人名作为测试查询, 发现所有查询都只包含不流行的单词, 因为它们的结果都少于10000且服务器只计算了排序得分而没有过滤;
如果我们将阈值减少到1000, 则在服务端部分排序后的结果过滤比例平均有50%, 因为每个邮件内容是很短的, 相同文档规模下, 搜索这样的数据集要比TREC45数据集快得多;

第六节结束语 CONCLUDING REMARKS

本文的贡献是提出了一个用于搜索云端数据的, 带有多重权衡的, 新颖的私有topK排序schema;
附录A中提供了有限泄露(limited leakage)的隐私分析(privacy analysis);
本文的实验证明了这个schema的响应时间是合理的, 就测试数据集而言, 服务端的部分排序可以高效地减少返回结果数量;
本文开发的技术在中等大小数据集上解决了这个公开难题;
对于非常大的数据集, 现有的技术要求有高速的C/S通信, 因为从服务器返回的结果数量即使在经过部分排序后仍然是很大的(如果查询单词都是流行的话);
部署起如5G之类的更快的网络连接可以扩展本文提出的方法的应用, 并且能够带来额外的改善;
如果可能的话, 另一种用于支持大数据集的策略是采用一个具有高速服务器代理通信连接的可信赖代理(trusted proxy); 这样最后的补充排序(supplimental rank)就可以在这个代理上完成, 并且返回结果可以以一个很低的通信开销发送回给客户端;
近期在基于神经网络的排序(参考文献24和26)上有新的进展, 我们的技术可以应用于这样的工作中或是直接整合神经特征;
致谢:

We thank Olaoluwa Osuntokun for initial code development, and the anonymous referees for their thorough comments. 
This work is supported in part by NSF IIS-1528041. 
Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the NSF.

附录A 隐私分析 PRIVACY ANALYSIS

参考文献17和18的工作分析了一个可搜索加密系统(searchable encryption system)的派生泄露(derived leakage)的正确性, 方式是证明任何攻击者(adversary)可以在真实搜索协议执行过程中获得的信息, 都可以通过一个攻击者(adversary)和模逆算法的交互实验被很好的模拟, 其中这个模拟算法仅知道这个安全搜索系统的泄露; 附录A将依据这样一个语义安全泄露(sematic security leakage)来分析本文schema的隐私性;
数学抽象:

设 $\Pi$ 是一个可搜索的对称加密schema, 其中包含两个算法:
- 算法一: EDBSetup分配钥匙给客户端和服务器, 然后加密倒排索引;
- 算法二: Search在服务器和客户端间执行搜索协议;
设 $L (D B, q)$ 是一个泄露概况函数(leakage profile function), 接收明文倒排索引 $D B$ 和一个查询序列 $q$ 作为输入, 输出结果是整个系统的泄露信息;
对于一个安全参数(security parameter) $\lambda$ (可以视为和钥匙的字节数相关), 两个高效算法 $A$ (攻击者, Adversary)和 $S$ (模拟者, Simulator), 定义实验 $Real_A^{\Pi}(\lambda)$ 和 $Ideal_{A,S}^{\Pi}(\lambda)$ :
- 实验 $Real_A^{\Pi}(\lambda)$ :
  - $A(1^{\lambda})$ 选择明文倒排索引 $D B$ 和一个查询列表 $q$ , 该实验运行 $(K,EDB)\leftarrow EDBSetup(DB)$ , 其中 $K$ 是一个仅对客户端可知的密钥集合, $E D B$ 是一个加密索引; 对于 $q$ 中的每个查询, 它秘密地运行算法Search(使用客户端输入的 $K$ 和服务器输入的 $E D B$ )然后存储副本(transcript, i.e. C/S间所有的通信); 然后该实验把 $E D B$ 和副本给到 $A$ , $A$ 将返回并输出一个布尔值(零一值)来告诉我们这个副本是否是通过真实搜索协议生成出来的, 或是由一个模拟者(simulator)生成出来的;
- 实验 $Ideal_{A,S}^{\Pi}(\lambda)$ :
  - $A(1^{\lambda})$ 选择明文倒排索引 $D B$ 和一个查询列表 $q$ , 该实验秘密运行 $S (L (D B, q))$ 然后将它的输出(一个综合副本, a synthetic transcript)给到 $A$ , 然后 $A$ 返回并输出一个零一布尔值来回答这个输出是否是通过真实搜索协议生成出来的, 或是由一个模拟者(simulator) $S$ 生成出来的;
定义:
- $\Pi$ 是针对非适应性攻击(non-adaptive attack)是 $L$ 语义安全的( $L$ -semantically-secure), 若对于所有高效的攻击者 $A$ , 都存在一个算法 $S$ 使得概率差异 $Prob[Real_A^{\Pi}(\lambda)=1]-Prob[Ideal_{A,S}^{\Pi}(\lambda)=1]$ 值是可以忽略的(即在计算可行的时间内不能区分两者概率上的差异, 如渐近地小于 $\lambda^{-c}$ 对任何正整数 $c$ 成立);
- 根据上面的定义, 我们的目标是使得攻击者 $A$ 不能够区分真实安全协议间的通信和模拟者 $S$ 在C/S间通信的差异; 这种表示仅针对非适应性攻击, 因为在每个实验中攻击者在开始时只能选择查询, 然后就再也不能在与服务器交互过程中改变已经选好的查询了; 这个假设适应大部分场景, 因为一个第三方的攻击者几乎不能控制用户发布的查询; 攻击者唯一知道的事情是查询的分布; 根据这个定义我们可以证明接下来这个sketched定理;
定理(sketched):
- 在标准密码学假设下, 第四节中的搜索schema, 相对于任何拥有泄露概况 $L$ (比如泄露给攻击者的信息)的非适应性攻击者来说, 是 $L$ 语义安全的, 泄露概况 $L$ 如下给定:
  - 大小模式(size pattern):
    - ① 分割的倒排索引项列表的块大小(chunk size for partitioned posting list);
    - ② 匹配每个子查询的文档数量;
    - ③ 对于每个子查询中的 $s$ 项( $s$ -term), 倒排索引项列表的长度;
  - 排序与特征模式(rank and feature patters):
    - ① 用于回答一次查询的加密文档编号的排名顺序;
    - ② 两个相同块里相同特征的文档权重差异, 若对应的单词已经被搜索到;
  - 交叉模式(intersection patterns):
    - ① 搜索过程中发送的 $s$ -term和 $x$ -token的重叠模式; 对于任何子查询, 给定 $s$ -term的发布中的任何块, 服务器会知道子查询中任何非 $s$ -term的倒排索引项中的哪些块与此块具有非空交集;(很拗口, 原文是: The overlapping pattern of s-tags and x-tokens sent during search. For any subquery, given any chunk in the posting of the s-term, the server knows which chunks in the posting of any non-s-term in the subquery have non-empty intersections with this chunk.)
    - ② 任意两个共享相同 $s$ -term的子查询的编号(identification);
    - ③ 来自两个子查询的两个 $s$ -term的倒排索引项列表(posting list)的交叉(intersection), 其中服务器已经知道这两个子查询共享至少一个非 $s$ -term;

参考文献

REFERENCES
[1] E. Agichtein, E. Brill, S. Dumais, and R. Ragno. Learning user interaction models
for predicting web search result preferences. In Proceedings of the 29th annual
international ACM SIGIR conference on Research and development in information
retrieval, SIGIR ’06, pages 3–10, New York, NY, USA, 2006. ACM.
[2] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu. Order-preserving encryption for
numeric data. In SIGMOD 2004, pages 563–574, 2004.
[3] Akamai.com. Akamai’s State of the Internet. Q1 2017 Executive Summary, 2017.
[4] A. Arampatzis, G. Drosatos, and P. S. Efraimidis. Versatile query scrambling for
private web search. Information Retrieval Journal, 18(4):331–358, 2015.
[5] A. Arampatzis, P. Efraimidis, and G. Drosatos. Enhancing deniability against
query-logs. In European Conference on Information Retrieval, pages 117–128.
Springer, 2011.
[6] L. T. I. at Carnegie Mellon University. The clueweb09 dataset,
http://boston.lti.cs.cmu.edu/data/clueweb09.
[7] R. Baeza-Yates and B. Ribeiro-Neto. Modern Information Retrieval (2nd Edition).
Addison Wesley, 2011.
[8] J. Bai, Y. Chang, H. Cui, Z. Zheng, G. Sun, and X. Li. Investigation of partial query
proximity in web search. WWW ’08, pages 1183–1184, 2008.
[9] A. Boldyreva, N. Chenette, Y. Lee, and A. O’Neill. Order-preserving symmetric
encryption. EUROCRYPT ’09, pages 224–241, 2009.
[10] D. Boneh. The decision diffie-hellman problem. Algorithmic number theory, pages
48–63, 1998.
[11] L. Boytsov and A. Belova. Evaluating learning-to-rank methods in the web track
adhoc task. In TREC, 2011.
[12] S. Büttcher, C. L. A. Clarke, and B. Lushman. Term proximity scoring for ad-hoc
retrieval on very large text collections. SIGIR ’06, pages 621–622. ACM.
[13] N. Cao, C. Wang, M. Li, K. Ren, and W. Lou. Privacy-preserving multi-keyword
ranked search over encrypted cloud data. IEEE Trans. Parallel Distrib. Syst.,
25(1):222–233, 2014.
[14] B. Carterette, V. Pavlu, H. Fang, and E. Kanoulas. Million query track 2009
overview. In TREC, 2009.
[15] D. Cash, P. Grubbs, J. Perry, and T. Ristenpart. Leakage-abuse attacks against
searchable encryption. In CCS’15, pages 668–679. ACM, 2015.
[16] D. Cash, J. Jaeger, S. Jarecki, C. S. Jutla, H. Krawczyk, M. Rosu, and M. Steiner.
Dynamic searchable encryption in very-large databases: Data structures and
implementation. In NDSS 2014, 2014.
[17] D. Cash, S. Jarecki, C. S. Jutla, H. Krawczyk, M. Rosu, and M. Steiner. Highlyscalable searchable symmetric encryption with support for boolean queries. In
CRYPTO 2013, pages 353–373, 2013.
[18] D. Cash and S. Tessaro. The locality of searchable symmetric encryption. In
EUROCRYPT 2014, pages 351–368, 2014.
[19] J. S. Culpepper and A. Moffat. Efficient set intersection for inverted indexing.
ACM Trans. Inf. Syst., 29(1):1:1–1:25, Dec. 2010.
[20] R. Curtmola, J. Garay, S. Kamara, and R. Ostrovsky. Searchable symmetric
encryption: Improved definitions and efficient constructions. CCS ’06, pages
79–88. ACM, 2006.
[21] T. Elsayed, N. Asadi, L. Wang, J. J. Lin, and D. Metzler. UMD and USC/ISI: TREC
2010 web track experiments with ivory. In Proceedings of The Nineteenth Text
REtrieval Conference, TREC 2010, Gaithersburg, Maryland, USA, 2010.
[22] C. Gentry. A Fully Homomorphic Encryption Scheme. PhD thesis, 2009.
[23] O. Goldreich and R. Ostrovsky. Software protection and simulation on oblivious
rams. J. ACM, 43(3):431–473, May 1996.
[24] J. Guo, Y. Fan, Q. Ai, and W. B. Croft. A deep relevance matching model for
ad-hoc retrieval. In Proceedings of the 25th ACM International on Conference on
Information and Knowledge Management, CIKM ’16, pages 55–64, New York, NY,
USA, 2016. ACM.
[25] H. Hu, J. Xu, C. Ren, and B. Choi. Processing private queries over untrusted data
cloud through privacy homomorphism. In ICDE, pages 601–612, 2011.
[26] M. S. Islam, M. Kuzu, and M. Kantarcioglu. Access pattern disclosure on searchable
encryption: Ramification, attack and mitigation. In NDSS 2012, 2012.
[27] K. S. Jones, S. Walker, and S. E. Robertson. A probabilistic model of information retrieval: development and comparative experiments. Inf. Process. Manage.,
36(6):779–808, Nov. 2000.
[28] S. Kamara and T. Moataz. Boolean searchable symmetric encryption with worstcase sub-linear complexity. In Annual International Conference on the Theory and
Applications of Cryptographic Techniques, pages 94–124. Springer, 2017.
[29] S. Kamara and C. Papamanthou. Parallel and dynamic searchable symmetric
encryption. In FC 2013, pages 258–274, 2013.
[30] S. Kamara, C. Papamanthou, and T. Roeder. Dynamic searchable symmetric
encryption. In CCS’12, pages 965–976, 2012.
[31] M. Naveed, M. Prabhakaran, and C. A. Gunter. Dynamic searchable encryption
via blind storage. SP ’14, pages 639–654. IEEE Computer Society, 2014.
[32] C. Örencik and E. Savas. An efficient privacy-preserving multi-keyword search
over encrypted cloud data with ranking. Distributed and Parallel Databases,
32(1):119–160, 2014.
[33] P. Paillier. Public-key cryptosystems based on composite degree residuosity
classes. In EUROCRYPT ’99, pages 223–238, 1999.
[34] R. A. Popa, F. H. Li, and N. Zeldovich. An ideal-security protocol for orderpreserving encoding. SP ’13, pages 463–477. IEEE Computer Society, 2013.
[35] R. A. Popa, C. M. S. Redfield, N. Zeldovich, and H. Balakrishnan. Cryptdb:
Protecting confidentiality with encrypted query processing. SOSP ’11, pages
85–100. ACM, 2011.
[36] D. Pouliot and C. V. Wright. The shadow nemesis: Inference attacks on efficiently
deployable, efficiently searchable encryption. In CCS’16, pages 1341–1352. ACM,
2016.
[37] C. Project. The enron email dataset, https://www.cs.cmu.edu/ enron/.
[38] D. X. Song, D. Wagner, and A. Perrig. Practical techniques for searches on
encrypted data. SP ’00. IEEE Computer Society, 2000.
[39] E. Stefanov, E. Shi, and D. X. Song. Towards practical oblivious RAM. In NDSS
2012, 2012.
[40] W. Sun, B. Wang, N. Cao, M. Li, W. Lou, Y. T. Hou, and H. Li. Verifiable privacypreserving multi-keyword text search in the cloud supporting similarity-based
ranking. IEEE Trans. Parallel Distrib. Syst., 25(11):3025–3035, 2014.
[41] K. M. Svore, P. H. Kanani, and N. Khan. How good is a span of terms?: exploiting
proximity to improve web retrieval. SIGIR ’10, pages 154–161. ACM, 2010.
[42] T. Tao and C. Zhai. An exploration of proximity measures in information retrieval.
SIGIR ’07, pages 295–302. ACM, 2007.
[43] L. Wang, J. Lin, and D. Metzler. A cascade ranking model for efficient ranked
retrieval. In Proceedings of the 34th International ACM SIGIR Conference on
Research and Development in Information Retrieval, SIGIR ’11, pages 105–114,
New York, NY, USA, 2011. ACM.
[44] Q. Wu, C. J. Burges, K. M. Svore, and J. Gao. Adapting boosting for information
retrieval measures. Inf. Retr., 13(3):254–270, June 2010.
[45] Z. Xia, X. Wang, X. Sun, and Q. Wang. A secure and dynamic multi-keyword
ranked search scheme over encrypted cloud data. IEEE Trans. Parallel Distrib.
Syst., 27(2):340–352, 2016.
[46] C. Xiong, Z. Dai, J. Callan, Z. Liu, and R. Power. End-to-End Neural Ad-hoc
Ranking with Kernel Pooling. In Proceedings of the 40th International ACM SIGIR
Conference on Research & Development in Information Retrieval. ACM, 2017.
[47] J. Xu and H. Li. Adarank: a boosting algorithm for information retrieval. SIGIR
’07, pages 391–398. ACM, 2007.
[48] W. Zhang, Y. Lin, S. Xiao, J. Wu, and S. Zhou. Privacy preserving ranked multikeyword search for multiple data owners in cloud computing. IEEE Trans. Computers, 65(5):1566–1577, 2016.
[49] J. Zhao and J. X. Huang. An enhanced context-sensitive proximity model for
probabilistic information retrieval. In SIGIR, pages 1131–1134, 2014.