Appearance
Theshold BBS+
Threshold BBS+ Signatures for Distributed Anonymous Credential Issuance
BBS+ 基本流程
1. KeyGen
- 假设待签名消息数量为
- 选择生成元
、 - 随机选择
个元素,记为
- 随机选择私钥
- 计算公钥元素
- 输出:
- 公钥
- 私钥
- 公钥
2. Sign
给定消息向量:
签名者执行:
- 采样随机数
- 构造承诺基点:
- 计算
- 输出签名:
3. Verify
给定消息向量
若等式成立,则接受该签名。
4. 正确性
因为
所以:
因此验证方程成立。
Blind BBS+
普通 BBS+ 中,签名者直接看到全部消息。盲签名场景下,用户希望:
- 某些消息对签名者可见;
- 某些消息对签名者隐藏;
- 签名者最终仍然对完整消息向量签名。
这时需要补充 blind、blind sign 和 unblind 三步。
1. 消息划分
设消息集合被拆成两部分:
- 显式消息(签名者可见):
- 隐藏消息(签名者不可见):
其中
2. Blind
用户先对隐藏消息做一个承诺,并发送给签名者。
- 用户随机选择盲化因子
- 计算隐藏消息承诺:
- 用户将
发送给签名者
在更严格的协议中,用户还需要附带一个零知识证明,证明自己确实知道
3. Proof of Knowledge of Commitment(PoK)
为了让签名者相信用户不是随意伪造一个群元素,而是真的知道隐藏消息与盲化因子,用户需要对
设隐藏消息个数为
- 盲化因子
; - 隐藏消息
; - 且它们满足
这可以用一个基于 Fiat--Shamir 变换的 Sigma 协议来实现。
Prove
用户执行:
- 随机选择掩码
- 构造临时承诺
- 计算挑战
- 计算响应值
- 输出证明
Verify
签名者收到
- 重新计算挑战
检查
检查如下等式是否成立:
若成立,则说明用户确实知道对应的盲化因子和隐藏消息;否则拒绝继续 blind signing。
为什么验证等式成立
因为
因此只要用户知道
4. BlindSign
签名者拿到:
- 可见消息
- 用户提交的承诺
- 用户提交的知识证明
签名者先验证
然后:
- 采样随机数
- 构造待签名项
- 计算盲签名
- 输出给用户:
5. Unblind
用户收到盲签名
注意到:
因此用户令:
并得到标准 BBS+ 签名:
这个签名可直接按普通 Verify 算法验证。
6. 为什么解盲成立
由上式可知:
其中
门限设置下的 BBS+
在门限场景中,可将私钥
- 各参与方分别持有
的份额; - 在签名阶段通过 MPC 协同计算
; - 最终得到与普通 BBS+ 一致的签名结果。
如果系统还要支持 blind signing,那么 MPC 参与方实际上是在对用户提交的承诺
选择性披露(Selective Disclosure)
BBS+ 的核心优势之一,是签名生成后用户可以只披露部分消息,而不暴露全部消息内容。
1. 将 BBS+ 看作对承诺的签名
定义:
因此,签名实际上证明了签名者认可这组消息被编码进了承诺
2. 选择性披露的目标
用户持有
- 自己知道一个有效 BBS+ 签名;
- 某些消息
被公开; - 其余消息仍被隐藏,但签名依然对完整消息集有效。
设公开集合为
验证者直接看到的是公开消息,而对隐藏消息部分,需要用户给出零知识证明,说明“存在某些未公开消息使得上式成立”。
3. 可用的证明工具
- 可以使用多底数离散对数知识证明;
- 实现上通常可借助一个或多个 Sigma 协议;
- 若还要证明隐藏属性满足区间、年龄门槛等条件,则可叠加范围证明,如 Bulletproofs。
4. 不可链接性
选择性披露协议通常会对签名进行随机化处理。由于每次证明都会重新采样随机数,验证者即使多次看到同一份凭证导出的证明,也无法轻易判断它们是否来自同一用户,因此具备较好的不可链接性。