通过加密云数据的安全的排名关键字搜索

教育部伊诺理工大学芝加哥

教育部伍斯特理工学院伍斯特

摘要：随着云计算的普及，敏感信息越来越集中在云端。为了保护数据安全，敏感的数据必须在外包之前就被加密，这使得有效的数据利用变成了一项非常有挑战性的任务。虽然传统的可搜索加密方式允许用户安全地通过关键字搜索加密数据，但是这项技术仅仅支持布尔搜索，而没有捕获数据文件的任何相关性。在直接应用于云计算的背景下，这种方法有两个主要的缺点。一方面，用户对于云数据加密并不一定具备前置知识，这就导致了他们不得不对每一项检索到的文件去进行后置处理以找出那个最符合他们要求的文件。另一方面，每次都要检索包含查询关键字的所有文件进一步引起了不必要的网络流量，这在今天的即用即付的云模式中是绝对不可取的。

在本篇论文中，我们第一次定义并解决了在加密云数据中进行有效且安全的排名关键词搜索问题。通过将匹配的文件按一定的相关性标准返回，排序搜索极大地提高了系统的可用性（例如,关键字的频率），因此，在云计算中更接近于实际部署保护隐私的数据托管服务。

我们首先给出了一个简单而又理想的结构，在最先进的可搜索对称加密(SSE)安全定义下，对关键字搜索进行排序，并展示其效率低下。为了实现更实际的性能，我们提出了一种可搜索对称加密的定义，并通过正确地利用现有的加密原语——保序对称加密，给出了一个有效的设计(OPSE)。深入分析表明，与以往的SSE方案相比，我们提出的解决方案具有“尽可能强的”安全性保证，同时正确实现了关键词搜索的目标。大量的实验结果证明了该方法的有效性。

1、介绍

云计算使云客户能够远程将数据存储到云中，以便从共享的可配置计算资源池中享受随需应变的高质量应用程序和服务。这个新的计算模型带来的好处包括但不限于：减轻存储管理的负担，独立地理位置的通用数据访问，硬件、软件和人员维护等方面的支出的避免等等。

随着云服务的普及，越来越多的敏感信息被集中到云服务器中，如电子邮件、个人健康记录、私人视频和照片、公司财务数据、政府文件等。为了保护数据隐私并打击未经请求的访问，必须在外包之前对敏感数据进行加密，以便在云内外提供端到端的数据保密保证。然而，数据加密使有效的数据利用成为一项非常具有挑战性的任务，因为可能会有大量的外包数据文件。此外，在云计算中，数据所有者可以与大量的用户共享他们的外包数据，这些用户可能只希望在给定的会话中检索他们感兴趣的特定数据文件。最流行的方法之一是通过基于关键字的搜索。这种关键字搜索技术允许用户选择性地检索感兴趣的文件，并在纯文本搜索场景中得到广泛应用。不幸的是，数据加密限制了用户执行关键字搜索的能力，并进一步要求保护关键字隐私，这使得传统的纯文本搜索方法无法应用于加密的云数据。

尽管传统的可搜索加密方案允许用户通过关键字安全地搜索经过加密的数据，而不首先解密它，但这些技术只支持传统的布尔关键词搜索1，而不捕捉搜索结果中文件的任何相关性。当直接应用于大型协作数据外包云环境时，它们可能会出现以下两个主要缺陷。一方面，对于每一个搜索请求，没有云数据加密的先验知识的用户为了找到最匹配他们的兴趣的文件，必须处理每个检索文件，这可能要求大量的后处理开销；另一方面，仅仅基于存在/没有关键字，总是发送所有文件，进一步带来大量不必要的网络流量,这在今天的即用即付的云模式下是绝对不可取的。简而言之，缺乏有效的机制来保证文件检索的准确性，这是在云计算环境下现有的可搜索加密方案的一个重大缺陷。尽管如此，信息检索(IR)社区中的最新发展已经利用各种评分机制来量化和排序任何给定的搜索查询对应的文件的相关性。尽管排名搜索的重要性在IR社区的明文搜索背景下已经引起了人们的关注，但令人惊讶的是，它仍然

被忽视，而且在加密数据搜索的背景下还有待解决。

因此，如何启用可搜索的加密系统来支持安全排序搜索，是本文要解决的问题。我们的工作是探索云计算中加密数据排名搜索的前几名。通过将匹配的文件按照一定的相关性标准(例如，关键字频率)返回匹配的顺序，排序搜索极大地提高了系统的可用性，从而更接近在云计算环境下实际部署隐私保护数据托管服务。为了实现我们在系统安全性和可用性方面的设计目标，我们结合了加密技术和IR社区两者的先进性，以“尽可能强”安全保证的精神设计出可搜索的对称加密方案。具体地说，我们研究了IR和文本挖掘中的统计度量方法，在将加密的文件收集外包之前，在可搜索索引的建立过程中嵌入每个文件的权重信息(即相关性分数)。由于直接外包关联得分将会对关键字隐私泄露大量敏感的频率信息，因此我们整合一个最近的密码原语——保持对称加密(OPSE)，并适当地修改它，以保护那些敏感的权重信息，同时提供高效的排序搜索功能。我们的贡献可以总结如下:

（1）首次定义了加密云数据安全排序关键字搜索的问题，提出了一种有效的协议，实现了安全排名搜索功能，对关键词隐私相关度评分信息泄漏小。

（2）彻底的安全性分析表明，与以前的SSE方案相比，我们排名的可搜索对称加密方案确实享有“尽可能强”的安全保证。

（3）广泛的实验结果证明了所提出的解决方案的有效性和有效性。

本文的其余部分安排如下。第二部分给出了系统和威胁模型，我们的设计目标，符号和预备。然后我们在第三节提供框架，定义和基本方案，接下来是第四节，详细描述了我们排名的可搜索对称加密系统。第五节和第六节分别给出了安全分析和性能评估。第七节讨论了可搜索加密和安全结果排序的相关工作。最后，第八节给出了整篇文章的结束语。

2、问题陈述

A、系统和威胁模型

我们考虑一个涉及三个云的数据托管服务不同的实体，如图2所示。

图1：通过加密云数据搜索的体系结构

1：数据拥有者（O），数据用户（U）和云服务器（CS）。

数据所有者拥有他想要的n个数据文件C =（F 1，F 2，...，F n）的集合以加密的形式在云服务器上外包，同时仍然保持搜索的能力，以实现有效的数据利用。为此，在外包之前，数据拥有者将首先从文件集合C中提取2的m个不同的关键字W =（w 1，w 2，...，w m）的集合中构建安全的可搜索索引I，并且把索引I和加密文件集合C存储到云服务器上。

我们假设数据所有者和用户之间的授权是正确完成的。为了搜索给定关键字w的文件集合，授权用户以秘密形式（关键字w的陷门T w）向云服务器产生并提交搜索请求。云服务器接收到搜索请求T w后，负责搜索索引I，并将相应的一组文件返回给用户。我们认为安全排名的关键字搜索问题如下：搜索结果应该根据一定的排名相关性标准（例如，基于关键词频

率的分数，将在稍后介绍）返回，以提高用户的文件检索准确度，而不需要事先知道文件集合C。但是，云服务器应该对相关性标准本身没有什么或几乎没有学习，因为它们会表现出关键字隐私的敏感信息。为了减少带宽，用户可以随着陷门T w发送一个可选的值k，并且云服务器仅向用户感兴趣的关键字w返回top-k最相关的文件。

我们在我们的模型中考虑一个“诚实但好奇”的服务器，这与以前的大多数搜索加密方案是一致的。我们假设云服务器以“诚实”的方式行事，正确地遵循指定的协议规范，但对协议期间接收的消息流进行推断和分析以“学习”以学习附加信息。换句话说，云服务器无意主动修改消息流或破坏其他任何类型的服务。

B、设计目标

在上述模型下，为了有效利用外包的云数据，实现排序的可搜索对称加密，我们的系统设计应该达到以下安全性和性能保证。具体来说，我们有以下几个目标：（1）排名关键词搜索：根据现有的可搜索加密框架，探索设计有效排序搜索方案的不同机制; ii）安全保证：防止云服务器学习数据文件或搜索到的关键字的明文，并与现有的可搜索加密方案相比，实现尽可能强的安全强度; iii）效率：以最少的沟通和计算开销来实现上述目标。

C、符号和预备

?C - 要外包的文件集合，表示为一组n个数据文件C =（F 1，F 2，...，F n）。

?W - 从文件集合C中提取的不同关键字，表示为一组m个单词W =（w 1，w 2，...，w m）。?id（F j）- 文件F j的标识符，可以帮助唯一地定位实际文件。

?I - 从文件集合建立的索引，包括一组发布列表{I（w i）}，如下所述。

T wi - 用户生成的陷门作为关键字w i的搜索请求。

?F（w i）- C中包含关键字w i的文件的标识符集合。

?N i - 包含关键字w i的文件数量，N i = | F（w i）|。

我们现在为我们提出的方案引入一些必要的信息检索背景：

倒排索引在信息检索中，倒排索引（也被称为发布文件）是一种广泛使用的索引结构，它存储了从关键字到包含该关键字的相应文件集的映射列表，允许全文搜索。对于排序的搜索目的，确定哪些文件最相关的任务，通常是通过基于下面介绍的一些排名函数，将可以预先计算的数字分数分配给每个文件来完成的。一个索引的示例性发布列表被显示在图2中。我们将使用这个倒排索引结构来给出我们基本排列的可搜索对称加密结构。

图2：倒排索引的示例发布列表。

排序函数在信息检索中，使用排序函数来计算匹配文件对给定搜索请求的相关性分数。在信息检索社区中，用于评估相关性得分，最广泛使用的统计测量是使用TF×IDF规则，其中TF （术语频率）仅仅是给定术语或关键字（我们将在下文中互换使用）的次数出现在文件（在特定文件中测量该术语的重要性），IDF（逆文件频率）通过将整个集合中的文件数除以包含该项的文件的数量获得（衡量整个集合中术语的整体重要性）。在TF×IDF加权方案的数百个变体中，它们的任何一个组合都不比其他任何组合更普遍。因此，在不失一般性的情况下，我们选择一个在文献中常用的和广泛见到的例子公式来计算相关性分数。其定义如下：

Score(Q,F d)=

1

d

t∈Q

×(1+ln f d,t)×ln(1+

N

t

)

这里Q表示搜索的关键字; f d,t表示文件F d中词条t的TF; f t表示包含术语t的文件数; N表示集合中文件的总数;而|F d| 是文件F d的长度，通过计算索引项的数量获得，作为归一化因子。

3、定义和基本计划

在介绍中，我们提出了对加密数据的排名关键字搜索，实现了云计算的规模经济。在本节中，我们从审查现有的可搜索对称加密（SSE）方案开始，并提供我们提出的排名可搜索对称加密（RSSE）的定义和框架。请注意，遵循现有SSE的相同安全保证，通过加密数据支持排名搜索功能的效率非常低，如我们的基本方案中所示。讨论其缺点并以此展开我们提出的方案。

A、可搜索对称加密的背景

可搜索加密允许数据拥有者以加密方式外包他的数据，同时保持对加密数据的选择性搜索能力。通常，使用Oblivious RAM可以在其全部功能中实现可搜索的加密。尽管可以在恶意服务器（包括访问模式）搜索期间隐藏所有内容，但是利用Oblivious RAM通常会为每个搜索请求带来用户和服务器之间的对数次交互的成本。因此，为了实现更有效的解决方案，几乎所有关于可搜索的加密文献的现有工作都采取了削弱的安全保证，即揭示访问模式和搜索模式，而不是别的。这里访问模式指的是搜索结果的结果，即哪些文件已被检索。搜索模式包括两个搜索请求之间的相等模式（是否对同一个关键字执行两次搜索）以及此后从该语句中导出的任何信息。我们引用读者对SSE定义进行深入的讨论。

对现有SSE文献的安全性保证有一个正确的直觉，对于我们定义排序的可搜索对称加密问题是非常重要的。后面我们将会证明，在现有SSE方案完全相同的安全保证下，实现排名关键字搜索的效率非常低，这促使我们进一步弱化了现有SSE的安全保障（泄露相对相关性顺序，而不是相关性分数），并实现“尽可能强”排名的可搜索对称加密。实际上，这个概念已经被密码学家用在许多最近的工作中，效率优于安全。

B、RSSE系统的定义和框架

我们遵循先前提出的可搜索的对称加密方案的类似框架，并调整我们排名的可搜索加密系统的框架。排名可搜索的加密方案由四个算法（KeyGen，BuildIndex，TrapdoorGen，SearchIndex）组成。我们排名的可搜索加密系统可以由这四个算法分两个阶段构建- 建立和检索：

?建立：数据拥有者通过执行KeyGen初始化系统的public和secret参数，并使用BuildIndex 对数据文件集合C进行预处理，从C中提取的唯一字生成可搜索索引。然后，所有者对文件集合C的数据进行加密，并且将包括基于关键词频率的相关分数的索引以加密的形式与加密的集合C一起发布到云。作为设置阶段的一部分，数据所有者还需要通过采用现成的公钥密码或更有效的原语（如广播）将必要的秘密参数（在我们的例子中为陷门生成密钥）分发给一组授权用户加密。

?检索：用户使用TrapdoorGen生成对应于他感兴趣的关键字的安全陷门，并将其提交给云服务器。在收到陷门后，云服务器将通过SearchIndex搜索索引，得到匹配的文件ID及其相应的加密相关性分数列表。匹配的文件应根据相关性分数以排序顺序发回。但是，服务器应该除了相关性分数的顺序再也学不到别的任何东西。

请注意，在我们的设计中，我们专注于单个关键字搜索。在这种情况下，等式1中的IDF因子对于给定的搜索关键字总是恒定的。因此，可以使用等式2仅基于包含在单个文件内的词频和文件长度信息来准确地排列搜索结果：

Score(t,F d)=1

d

×(1+ln f d,t)

数据所有者可以保留这两个值的记录并预先计算相关性分数，这对于索引建立来说，引入的开销很小。我们将在第六部分的绩效评估中通过实验来证明这一点。

C、基本方案

在给出我们的主要结果之前，我们首先从简单而理想的方案开始，其中我们排名的可搜索加密的安全性与先前的SSE方案相同，即用户获得排名结果而不让云服务器学习任何额外的信息，除了访问模式和搜索模式。然而，这是通过效率的折中来实现的，即用户要么等待每个搜索请求的两个往返时间，要么甚至可能丧失执行top-k检索的能力，导致不必要的通信开销。对这些缺点的分析将引出我们的主要结果。请注意，我们这里讨论的基本方案与最近的工作密切相关，尽管我们关注的是安全结果排名。事实上，它可以被看作是可搜索对称加密的最简化版本，它满足[10]中的非自适应安全定义。

基本方案：将k，l，l'，p作为Keygen(?)中使用的安全参数。令ε成为一种语义上安全的对称加密算法：设ν是包含单词w i的文件的最大数量：该值并不需要事先知道该方案的实例化。另外，设f是伪随机函数，π是

具有以下参数的抗碰撞散列函数：实际上，π(·)将通过像SHA-1这样的自身散列函数来实例化，在这种情况下，p是160位。

在设置阶段：

1)数据拥有者通过调用KeyGen（1k，1l，1l'，1p）来启动该方案，生成随机密钥

并且输出K=

2)数据拥有者然后通过调用BuildIndex（K，C）从文件集合C中建立一个安全的倒排索引。

细节在图3中给出。l’填充0表示有效的发布条目。

图3：基本方案的BuildIndex(·)的详细信息

在检索阶段：

1)对于感兴趣的关键字w，用户通过调用TrapdoorGen（w）生成一个陷门

2)在收到陷门T w后，服务器调用SearchIndex（I，T w）：首先通过πx（w）定位索引的匹

配列表，使用f y（w）解密条目，然后发回相应的文件根据F（w），连同其相关的加密相关性分数。

3)用户通过关键字z解密相关性分值并获得排名的搜索结果。

讨论：上述方案显然满足了SSE的安全保证，即只有访问模式和搜索模式被泄露。然而，排名是在用户端完成的，这可能会带来巨大的计算和后期处理开销。而且，发回所有文件消耗很大的不需要的带宽。减少通信开销的一个可能的方法是服务器首先发送所有有效的条目

其中1≤j≤Ni。然后，用户解密相关性分数并且向云服务器发送另一个请求以通过排序解密得分来检索最相关的文件（top-k检索）。作为有效条目的大小远远小于相应的文件，只要用户不检索所有匹配的文件，预计将会节省大量

的带宽。然而，最明显的缺点是每个用户的每个搜索请求有两个往返时间。还要注意的是，这样服务器仍然不了解关联分数的值，但是它知道所请求的文件比没有请求的文件更相关，这比访问模式和搜索模式不可避免地泄漏了更多的信息。

4、对偶排序的可对称S对称加密方案

上述直接的方法显示了导致排名可搜索加密效率低下的核心问题。那就是如何让服务器快速执行排名，而不必真正了解相关分数。为了有效支持对加密文件集合的排序搜索，我们现在求助于新开发的密码原语——保序对称加密（OPSE），以获得更加实际的性能。请注意，通过使用OPSE，与SSE相比，我们的RSSE安全性保证本质上被削弱了，因为我们现在让服务器知道相关性顺序。但是，这是我们想要权衡RSSE效率的信息，正如前面的章节III。我们将首先简要地讨论原始的OPSE及其利弊。然后，我们将展示如何通过“尽可能强”的安全保证来适应我们的目的。最后，我们演示如何通过具体的例子来选择不同的方案参数。A、使用保持对称加密的顺序

OPSE是一个确定性的加密方案，其中明文的数字排序通过加密函数被保留。Boldyreva等人给出了OPSE的第一个密码学研究，并提供了一个在伪随机函数或伪随机序列的安全框架下可证明的安全结构。即，考虑到从域D = {1，...，M}到范围R = {1，...，N}的任何保序函数g(·)可以被M中提取的N个有序项组合唯一定义，当且仅当入侵者必须对M中的所有可能组合进行蛮力搜索以破坏加密方案时，OPSE才被认为是安全的。如果安全级别被选择为80位，那么建议选择M = N / 2> 80，以使组合的总数大于2 80。它们的构建基于随机顺序保持函数（符合上述安全概念）与超几何概率分布之间的关系，后者将被表示为HGD。有关OPSE 及其安全性定义的更多详细信息，请参阅[12]。

乍看之下，通过将标准的不可区分的对称加密方案的相关性分值加密改变为该OPSE，似乎直接跟随在明文域中可以实现有效的相关性分值排序。然而，如前所述，OPSE是一个确定性的加密方案。这个固有的确定性属性，如果处理不当，仍然会泄漏大量的信息，因为任何确定性的加密方案都会这样做。图4是从我们的测试集合的1000个文件中采样的关键字“network”的偏斜的相关性得分分布的示例。为了便于说明，我们将实际分数编码为从1到128的域中的128个等级。得分分布可以被视为来自斜率，值范围或其他度量的特定关键词。请注意，直接使用OPSE并不会随机化这个关键字特定的分数分布性质。因此，对于文件集合中的某些背景信息，攻击者可以直接从加密分数分布反向设计关键字“network”，而不实际上打破陷门结构，对手也不需要打破OPSE。

图4：相关分数分布的例子。算法1一对多保序映射OPM

B、迈向一对多保序映射

因此，我们必须修改OPSE以适应我们的目的。为了减少来自确定性属性的信息泄漏量，因此期望一个一对多的OPSE方案，其可以使原始的相关性分数分布变平或混淆，增加其随机性，仍然保持明文的顺序。为此，我们首先简要回顾原始确定性OPSE的加密过程，其中域D中的明文m总是映射到范围R中的相同的随机大小的非重叠间隔桶，由范围内的keyed binary search确定R和随机HGD采样函数的结果。然后通过使用m作为一些随机选择函数的种子，在桶内选择密文c。

我们的一对多保序映射采用了OPSE的随机明文- 桶映射，但是在最终的密文选择过程中，将独特的文件ID与明文m一起作为随机种子。由于使用唯一文件ID作为随机选择种子的一部分，相同的明文m将不再被确定性地分配给相同的密文c，而是在范围R中随机分配的桶内的随机值。整个过程如图所示在算法1中，改编自[12]。这里的TapeGen（·）是一个随机硬币发生器，HYGEINV（·）是在MATLAB中实现的高效函数，作为HGD（·）采样函数的实例。我们的一对多保序映射的正确性直接来自算法1.请注意，我们的理性是使用OPSE分组密码作为不同应用场景的工具，并获得更好的安全性，这是建议和一致的。现在，如果我们将OPM表示为我们的具有参数的一对多保序映射函数：

我们提出的RSSE方案可以描述如下：

在设置阶段：

1)用户通过调用生成随机密钥，并且输出

2)数据所有者通过调用建立集合C的倒排索引，并使用

而不是E(·)来加密分数。

在检索阶段：

1)用户为感兴趣的关键字w生成并发送陷门云服务器接收到陷门

T w后，首先通过πx（w）找到索引的匹配条目，然后用f y（w）对该条目进行解密。这些与基本方法相同。

2)云服务器现在看到文件标识符（假设从而）和相关

的顺序保存的加密分数：

3)然后，服务器根据加密的相关性分数获取文件并以排列顺序发回它们

或者如果提供了可选值k，则发送top-k最相关的文件。

讨论：在顺序保存映射的帮助下，服务器现在可以相应地按照未加密的分数对文件进行有效排序。我们使用不同的密钥来加密不同发布列表的相关性分数的原因是为了使一对

多映射更加难以区分。因此，在指数I的不同列表中出现相同的相关性分数在R中被映射到不同的“桶”。结合我们的一对多映射将从整体的观点来随机化加密的值。

因此，我们可以进一步减轻向云服务器显示的有用信息，云服务器可能一直对加密数值的统计分析感兴趣，以推断基础信息。

C、选择R的范围大小

我们已经强调了我们的想法，但是仍然需要一些关注的实施。我们的目的是在映射过程中尽可能多地丢弃明文域的峰值分布，从而消除域D上关键字特定分数分布的可预测性。显然，根据我们的随机一对多有序分布，保留map-ping（算法1行6），设置范围R越大，保留的峰值功能就越少。但是，范围大小| R | 不能任意大，因为这可能会降低HGD功能的效率。在这里，我们使用最小熵作为我们的工具来找到范围R的大小。

在信息论中，离散随机变量X的最小熵定义为：X越高，X 就越难预测。如果∈我们说X具有高的最小熵，其中k是用来表示X的所有可能状态的比特长度。注意是，其中c> 1。

令max表示索引I内最大可能的重复记录数目，并且令λ表示在每个发布表I（w i）内映射的平均分数。不失一般性，我们令D = {1，...，M}，因此| D | 那么基于上面的最小熵要求，我们可以找到最小可能的| R | 满足以下等式：

在这里，我们使用[12]的结果，在OPSE操作期间HGD采样的总递归调用是属于O（logM）的函数，并且平均最多5logM + 12，这是期望的范围的次数在BinarySearch（·）的函数调用过程中，R将被切成两半。我们还假设一对多的映射是真正的随机的（算法1行5-6）。因此，上述等式左边的分子实际上是映射后预期的最大重复数目。如果我们表示范围大小| R | 在比特中，即k = log | R |，我们将有：

用确定的指数I，很容易确定合适的范围大小| R |。

根据图4中关键字“网络”的例子，其中max /λ= 0.06（即最大分数重复为60，发布列表的平均长度为1000），可以确定密文范围大小| R| = 246时，如图5所示，当关联分数域被编码为128个不同的等级并且c被设置为1.1时。注意，范围的更小尺寸| R | 当我们用属于O （logM）的M的其他相对“松散”函数（例如，5logM或4logM）代替上限5logM + 12时是可能的。图5显示范围| R | 大小可以进一步减少到234或者227。但是，由于我们的方案表现为| R | = 246已经足够高效了（见第六章），我们并没有试图将这些不同选择的整体表现和效果分别进行比较，而是将其作为我们未来工作之一。

图5：范围R的大小选择，给定max/λ

= 0.06，M = 128，并且c = 1.1。LHS和RHS表示方程式4的相应侧。还包括在方程式4中替代5logM + 12的O（logM）的两个示例性选择。

5、安全分析

我们通过分析其实施第二部分所述的安全保证来评估所提议的方案的安全性。也就是说，云服务器不应该学习数据文件或搜索关键字的明文。我们从我们的一对多保序映射的安全性分析开始。然后分析了一对多保序映射和SSE组合的安全强度。

A、一对多映射的安全性分析

我们的一对多保序映射是从最初的OPSE中引入的，通过在最终的密文选择过程中引入文件ID作为附加的种子。由于这种自适应仅在最终的密文选择过程中起作用，与原始OPSE中的随机化明文- 桶映射过程无关。换句话说，引入文件ID作为新种子的唯一效果是使得多个明文副本m不再确定性地映射到相同的密文c，而是映射到范围R中指定的桶内的多个随机值。这有助于展平密文分布在一定程度上映射到了一定程度。然而，这种通用的自适应只有在明文副本数量不大时才有效。如果明文m的重复次数很多，映射后对应的密文分布可能仍然表现出一定的偏度或者明文分布的峰值特征，这是由于距离R的指定桶相对较小。

这就是为什么我们建议在第IV-C节中适当放大R的原因。请注意，在原始的OPSE中，确定大小R只是为了确保D和R之间的不同组合的数目大于280。但是从实际的角度来看，在我们的一对多情况下适当放大R的目的是进一步确保映射后的密文范围内的低重复（高概率）。这固有地增加了对手难以准确地确定范围R中的哪些点属于域D中的相同分数，使得保序映射尽可能强。注意，与最初的OPSE相比，我们的方案的一个缺点是固定范围大小R需要预先知道所有明文中最大重复的百分比（即等式3中的max /λ）。但是，在构建可搜索索引时，我们可以轻松地满足这种额外要求。