system: [SYSTEM]

user: 4. 实验分析 4.1. 安全性分析 首先，由于查询数据Q经过具有语义安全性的Paillier密码系统加密，Bob的输入查询Q在第四节提出的两种协议中都无法被数据拥有者Alice、服务器C1和C2知晓。 在SkNNb协议中，步骤3(b)的解密操作将欧式距离d i 值泄露给服务器C2。此外，由于C2生成了k近邻索引列表(在算法5步骤3(c)中)并将其发送给C1，因此数据访问模式将被泄露给服务器C1和C2。因此，如果我们不介意di值可以泄露给C2，数据访问模式可以泄露给C1和C2，我们的基本SkNNb协议可以认为是安全的。 另一方面，对SkNNm的安全性分析如下。在算法步骤2中，安全欧几里得距离SSED协议和安全位分解SBD协议的输出是经过加密的，只有服务器C1知道。此外，在安全欧几里得距离SSED协议中所有由服务器C2解密的中间结果在Z N 中都是一致随机的。此外，安全位分解SBD协议是安全的。因此，在算法步骤2中没有泄露任何信息。在每次迭代中，SMINn的输出只有服务器C1知道，而服务器C2不知道任何信息。另外，C1和C2不知道哪个记录对应当前的全局最小值。因此，数据访问模式无法被服务器C1和C2知晓。算法步骤3(c)，β向服务器C2泄露了某个解密的元组满足当前全局最小距离。但是，由于C1发送之前进行了乱序排列，C2无法追溯到对应的数据记录。同时，注意β的解密数据为0或范围Z N 内的随机数进行加密后的数据。同样，由于C2返回给C1的U是加密的向量，C1无法知道哪个加密元组对应当前全局最小距离。因此，在此步骤中，数据访问模式无法被C1知晓。此外，算法步骤3(e)的更新过程不会向服务器C1和C2泄漏任何信息。总之，服务器C1和C2不知道哪个数据记录对应于输出集 〈 t ′ 1 ， ⋯ ， t ′ k 〉 。 综上所述，很明显，本文使用的SkNNm协议能有效保护数据的机密性、用户输入查询数据的隐私，并隐藏数据访问模式。 4.2. 复杂性分析 SkNNb的计算复杂度受加密、解密和求幂的限制为 O ( n ∗ m + k ) 。实际上 k ≪ n ∗ m ，因此，受到加密和求幂的限制(假设在Pallier密码系统下加密和解密操作需要相同的时间)SkNNb的计算复杂度为 O ( n ∗ m ) 。另一方面，SkNNm的计算复杂度受加密和取幂的限制为 O ( n ∗ ( l + m + k ∗ l ∗ log 2 n ) ) 。 根据密钥大小的不同，我们使用的SkNNm的总体计算成本(高于SkNNb协议)比非加密情况(本文提出的相关工作)高2到3个数量级。这是为了最大化数据保密性所需要付出必要的代价。然而，在客户端，我们使用的协议所用运行时间与非加密情况相当，因为用户只需执行非常少量的操作(受属性数量的限制)，这些操作将在不到一秒的时间内完成。我们的目标是将所有或大部分计算发送给服务器，这样用户就可以使用任何具有存储和有限计算能力的移动设备提出查询。 4.3. 数据对比 我们在一台Windows机器上进行了各种实验。其中我们使用JetBrainsPyCharm作为python编辑器，使用Anaconda作为python第三方库的管理软件，主要使用了python-paillier库进行paillier加密解密，所使用的python版本为3.7。 在数据集选择方面，我们使用了著名的UCI Heart Disease 数据集作为数据库数据T，并选择其中十四个主要属性进行实验。但是由于原数据集数据量较少，且在实际数据集中很难控制参数，我们根据考虑的参数值随机生成合成数据集。利用这些综合数据集，我们可以对不同参数设置下的协议计算成本进行更详细的分析。我们在实验中使用密钥大小不同的Paillier加密技术对这些数据集进行了属性加密，加密后的数据存储在我们的机器上。然后，根据所提议的协议，我们对这个加密数据执行一个随机查询。对于本节的其余部分，我们不讨论数据拥有者Alice的性能，因为它是一次性成本。我们分别评估和分析了SkNNb和SkNNm的性能，然后，我们比较了这两种协议的性能。在我们的实验中，Paillier加密密钥大小S被设置为512位或1024位。 1) SkNNb协议测试 在本小节中，我们通过改变数据记录的数量(n)、属性的数量(m)、最近邻居的数量(k)和加密密钥大小(S)来分析SkNNb协议的计算成本。 首先，通过设置最近邻数量k = 5，密钥大小S = 512，我们评估不同n和m下SkNNb的计算成本。如图2所示，SkNNb的计算成本呈线性增长趋势。例如，当属性数量m = 6时，随着数据记录数量n从2000增加到4000，SkNNb计算时间从44.01秒增加到88.02秒。密钥大小S = 1024时也有类似的趋势，如图3所示。对于任何固定参数，我们发现当S大小增加一倍时，SkNNb的计算时间几乎增加了7倍。 图2. k = 5，S = 512情况下SkNNb趋势图 图3. k = 5，S = 1024情况下SkNNb趋势图 接下来，通过固定设置参数属性数量m = 6和记录数量n = 2000，我们评估了最近邻数量k和密钥大小S变化时SkNNb的运行时间，结果如图4所示。不管密钥大小S是多少，SkNNb不会因最近邻数量k的改变而变化计算时间。这是因为SkNNb大部分的计算成本来自安全欧几里德SSED协议，该协议与最近邻数量k无关。例如，当S = 512位，随着k从5变化到25，SkNNb计算时间从44.01变化到44.11秒。综上所述，可以看出，SkNNb的运行时间主要取决于记录数量n和属性数量m，这进一步证明了我们的复杂性分析是合理的。 图4. m = 6，n = 2000情况下SkNNb趋势图 2) SkNNm协议测试 我们还评估了最近邻数量k、属性值大小(二进制位数)l和密钥大小S值变化时SkNNm的计算成本。在本小节中，我们固定属性数量m = 6且数据数量n = 2000。我们发现SkNNm的运行时间也几乎呈线性增长。 当密钥大小S = 512位时，变化最近邻数量K和属性二进制位数l，产生的SkNNm计算量如图5所示。由图5可知，当l = 6时，随着k从5变为25，SkNNm的运行时间从11.91变为55.58分钟。同样，对于l = 12，SkNNm的运行时间随着k从5变为25，由20.56分钟变为97.83分钟。无论哪种情况，SkNNm的计算成本几乎与k和l呈线性增长。 图5. n = 2000，S = 512情况下SkNNm趋势图 在S = 1024时也观察到类似的趋势，如图6所示。特别地，对于任何给定的固定参数，我们发现当S增加一倍时，SkNNm的计算成本几乎增加了7倍。例如，当k = 10时，SkNNm分别花费22.83分钟和157.16分钟生成S = 512和1024位下查询数据Q的10个最近邻。此外，当k = 5时，我们发现在SkNNm中约有69.7%的成本是由于安全最小n个数字协议SMINn在SkNNm中启动了k次。同时，当k值从5增加到25时，SMINn引起的成本从69.7%增加到至少75%。 图6. n = 2000，S = 1024情况下SkNNm趋势图 此外，通过设置记录数量n = 2000，属性数量m = 6，属性大小l = 6和密钥位数S = 512，我们比较两个协议在不同的K值下的运行时间，如图7所示，SkNNb的运行时间一直约为0.75分钟，因为它几乎与k不相关。然而，当我们把K从5增加到25，SkNNm的运行时间从11.91分钟变化到55.58分钟。 图7. SkNNm与SkNNb趋势对比图 从以上结果可以看出，SkNNm的计算成本明显高于SkNNb。但是，我们强调SkNNm比SkNNb更安全。在SkNNb中，安全欧几里得距离SSED协议最耗费时间，而在SkNNm中，则是安全最小n个数字SMINn协议。另外，需要注意的是，Bob的计算成本主要是由于其输入查询记录的加密和最终离群点的计算造成的。例如，对于m = 6，当K分别为512位和1024位时，Bob的计算成本分别为10和37毫秒。这进一步表明，从终端用户的角度来看，我们的协议非常有效。