Page 395 - 《软件学报》2025年第7期
P. 395

3316                                                       软件学报  2025  年第  36  卷第  7  期


                    (2) 计算开销对比
                    在本节中, 我们将本文方案与文献           [18,21] 中的方案从计算开销的角度进行对比. 令            G  表示一次群   G 上的幂
                 运算, G T 表示一次群   G T  上的幂运算, e 表示一次双线性配对计算, k 表示用户密钥中属性的数量, n                表示文件中数
                 据块的数量, p   表示完整性验证中数据块的数据, t 表示密文中属性的数量, 变色龙哈希函数采用第                         2.3  节提供的方
                 案, 属性基加密采用文献       [23] 中的方案. 在表   2  中, 我们分别对比了密钥生成、服务器验证、完整性验证、数据
                 访问以及所有权转移/共享        5  个部分的计算开销, 我们为计算开销最优的方案标注了“*”以便于区分.

                                                   表 2 方案计算开销对比

                         计算内容                  文献[18]              文献[21]                 本文方案
                         密钥生成                   8G                 (5k+2)G                (4k+8)G *
                        服务器验证                 7nG+2ne                4ne                 (3n+2)G+2e *
                        完整性验证                 (p+7)G+2e             pG+2e                (p+3)G+2e
                         数据访问                    -               G+3G T +(2t+1)e *     (4t+1)G T +(3t+1)e
                       所有权转移/共享                 4G                (4t+2)G+2G T              3G *
                 注: *表示计算开销最优的方案

                    在密钥生成部分, 本文方案与文献           [21] 方案的计算开销分别为        (4k+8)G  和  (5k+2)G, 而文献  [18] 仅为  8G. 这
                 是由于本文方案与文献         [21] 的密钥包括数据审计密钥和数据访问密钥两部分, 其中数据审计密钥负责对数据完
                 整性进行验证, 数据访问密钥用于实现对数据的细粒度访问控制. 文献                       [18] 由于不提供数据细粒度共享的功能,
                 因此密钥生成时只需计算数据完整性验证部分的数据审计密钥. 在本文方案中, 生成数据审计密钥的计算开销为
                 4G, 生成数据访问密钥的计算开销为           (4k+4)G, 因此在数据审计密钥生成方面, 本文方案比文献              [18] 更加高效. 与
                 文献  [21] 相比, 本文方案的计算开销更低且文献           [21] 中的数据访问控制方案是基于一个二叉树构建的, 系统中用
                 户数量受二叉树叶子结点数量的限制存在上限, 存在实用性方面的不足. 服务器验证的计算开销是指服务器收到
                 数据用户上传的数据时需要在存储前对收到的数据进行验证, 本文方案与文献                          [18,21] 方案在这部分的计算开销
                 分别为   (3n+2)G+2e、7nG+2ne 和  4ne. 由于本文方案支持批量验证, 因此云服务器在验证时的计算开销更少. 类似
                 地, 在完整性验证的过程中, 本文方案与文献             [21] 都采用了批量验证的方式, 因此计算开销均优于文献                [18]. 虽然
                 在数据访问部分, 本文方案的计算开销为             (4t+1)G T +(3t+1)e, 高于文献  [21] G+3G T +(2t+1)e 的计算开销, 但本文方
                 案在执行数据所有权共享时的计算开销仅为                3G, 而文献  [21] 执行数据所有权转移时的计算开销为            (4t+2)G+2G T ,
                 与密文中属性的数量相关. 这是由于文献             [21] 不仅需要更新用户的密钥, 同时还需要对系统中的密文进行更新,
                 而本文方案借助变色龙哈希函数, 免去了密文更新的步骤, 仅需常数级的计算开销即可在不影响数据完整性验证
                 的情况下共享数据的所有权, 与用户所拥有的数据数量无关. 总体而言, 本文方案在不影响计算效率的情况下提供
                 了更加丰富的功能, 使方案更加实用, 在数据验证以及数据有权共享时的计算开销相比于其他方案有显著的优化.

                 5.3   实验分析
                    在本节中, 我们将本文方案分别与文献              [18] 和文献  [21] 进行了实验对比. 实验基于        Charm  框架  [24] 使用
                 Python 3  编程实现, 其中双线性映射采用       Charm  框架中的默认曲线“SS512”. 实验的平台为一台         Macbook Pro  笔记
                 本电脑, 处理器为     Inter Core i7 (2.7 GHz), 内存为  16 GB. 此外, 本文方案中密文策略属性基加密使用的访问策略通
                 过  AND  相互连接, 实验中采用毫秒作为运行时间的统计单位.
                    (1) 与文献  [18] 的对比情况
                    由表  1  功能对比的情况可知, 文献       [18] 中的方案仅提供了对明文数据进行完整性验证的功能, 而本文方案在
                 提供数据完整性验证功能基础上, 还基于密文策略属性基加密实现了数据加密和细粒度共享的功能. 出于公平性
                 考虑, 我们在实验对比时, 仅关注这两个方案在数据标签生成、数据标签验证、审计挑战生成、证明生成以及证
                 明验证阶段的运行时间. 实验测试文件的大小为               2 MB, 分为  10 000  个数据块. 我们在数据标签生成和验证阶段统
                 计了运行时间随数据块在         200–2 000  的变化情况. 从图  2(a)、(b) 可以看出, 本文方案在数据标签生成阶段的计算
                 开销与文献    [18] 基本一致, 但在数据标签验证阶段, 得益于所采用的聚合计算机制, 本文方案在计算开销方面具
   390   391   392   393   394   395   396   397   398   399   400