Page 469 - 《软件学报》2025年第8期

3892 软件学报 2025 年第 36 卷第 8 期

生成阶段、签名生成阶段以及验证阶段进行分析.
由于本文设有预签名阶段, 考虑到各方案总体计算开销对比, 分析了本文方案预签名阶段的计算开销. 对比结
果如表 1 所示. 假设有 n 个参与者, 其中 dc 表示点乘, dj 表示点加, mj 表示模加, mn 表示模逆, mc 表示模乘运算.
需要注意的是, 我们对比的是文献 [14] 在密钥生成阶段不存在可信中心的情况下各阶段的计算量. 在密钥生成阶
段, 文献 [6] 计算 Q 时需要执行 n 次点乘运算, 计算公钥时执行了 n 次点加运算. 文献 [14] 执行 PM-SS 得到公钥
以及执行 Inv-ss 得到私钥份额时需要 n 次点乘、1 次模逆和 3n 次模乘运算. 而本文方案需要在计算公钥和密钥
份额时只需要 n 次点乘运算; 在签名生成阶段, 文献 [6] 计算中间变量以及签名时共需要执行 n 次点乘、 (2n+3)
次点加、1 次模逆和 2n 次模乘运算. 文献 [14] 在计算 kG 和签名份额时需要执行 n 次点乘、 n+1 次点加和 2n 次
n 次点加运算即可完成. 而在本文方案的签名阶段需要 n 次点乘、1 次点加、1 次模逆和
模乘运算. 本文仅需要
4n 次模乘运算; 它们的签名验证主要依赖于 SM2 数字签名的验证过程. 因此, 易知在验证阶段它们的计算量是相
当的. 由上表可以看出, 文献 [6] 总体的计算量最大, 文献 [14] 的计算量较小, 本文方案的计算量最小.

表 1 本文方案与文献 [6] 和文献 [14] 计算量比较

方案 密钥生成 预签名阶段 签名生成 验证阶段
文献[6] (n)dc+(n)d j － (n)dc+(2n+3)m j+mn + (2n)mc dc+d j
文献[14] (n)dc+mn+(3n)mc － (n)dc+(n+1)m j+(2n)mc dc+d j
本文方案 (n)dc (n)dc+mj+mn+(4n)mc (n)m j dc+d j

5.2 功能性对比
本节分别从参与方是否加权、健壮性、预签名和半诚实模型这 4 个方面与已有方案进行功能性对比. 其中, ×
表示方案不具备该性质或功能; √则表示具有该性质或功能. 功能性对比如表 2 所示.

表 2 本文方案与文献 [6] 和文献 [14] 功能性对比

方案 加权(权重) 健壮性 预签名 半诚实模型
文献[6] × × × －
文献[14] × √ × √
本文方案 √ √ √ √

相较文献 [6], 本文引入了加权的概念, 在现实应用上更加具备灵活性. 相较于文献 [14] 的 SM2 分布式签名,
本方案不需要所有参与者同时在线以此完成签名密钥的分发. 此外, 本文方案有效抵抗文献 [14] 中部分密钥丢失
的攻击, 增强了 SM2 签名的健壮性. 本文保证半诚实模型下安全, 同时方案增加预签名阶段, 参与者可以离线进行
本地操作, 提高了运算效率, 有效降低了通信开销.

6 应 用

在传统门限秘密共享方案中, 所有参与者被视为具有相同地位. 然而, 在实际场景中, 参与者的权力可能不均.
因此, 人们提出了加权门限秘密共享方案. 其主要思想是, 只有当参与者的权重总和达到预设的权重门限时, 方可
还原秘密; 反之, 则无法还原秘密. 本文结合加权门限 SM2 签名与区块链技术, 针对现实应用中参与者权利不同的
问题, 设计出一个基于加权门限 SM2 签名的区块链投票系统. 系统模型如图 1 所示.
系统主要包含: 用户、区块链模块和加权门限 SM2 签名模块. n 个用户提出投票请求, 只有权重之和≥T 的用
户才能利用加权门限 SM2 签名模块生成签名, 权重之和在 (t,T) 之间可以了解到签名密钥相关信息, 但不能进行
签名, 而权重之和≤t 的用户既不能了解到密钥相关信息也不能进行签名. 用户签名后利用加权门限 SM2 签名模
块对签名进行验证, 验证通过后投票才会被认可并通过区块链模块记录在区块链上. 并且任何人都可以在区块链
上查询投票结果, 确保透明和公正.