有效的数字签名机制必须表明签名者的身份吗？在不知道签名者身份的情况下，如何确认数字签名的有效性？匿名签名方案如何支持监管仲裁的有效干预？后面的组签名和环签名技术有什么区别？

现代商业活动中签名机制的字面解释是：为了表示同意、批准、责任或义务而写名字的同时，验证者可以检查字迹的真实性，以验证签名的有效性。在这个过程中，认证者经常从“名字”中知道签名者的身份。在传统的签名机制中，能够知道签名者的身份是验证签名有效性所必需的。

这也提出了一个问题：如果参与商业活动的合作者不愿意或不方便表明自己的身份，我们能和他签订有效的合同吗？

举个具体的例子，在典型的暗票购买方案中，投标人必须签署自己提出的标书，确保标书的有效性，并反映自己符合一定的素质。与此同时，投标人、投标平台、其他投标人无法通过签名识别投标人的身份，因此无法避免围攻、串扰等潜在的非法行为。

解决这些问题的关键是将使用集团签名和环签名技术的数字签名的可验证性与签名者的身份信息分开。这两种技术为什么能达到如此常识性的效果？然后和这篇文章一起探索到最后。

组签名和环签名的匿名性

在签名者ID隐藏中，组签名和环签名是最常见的两种数字签名技术，主要效果是签名的验证者只能在一个组中验证签名。但是不能准确推测签名来自哪个个别签名者。

回到以前的秘密投标采购场景，投标人可以通过集团签名或环签名签署标书。投标人和投标平台可以确认相应的标书是否来自合格的集团，但不能知道身份信息。

一般来说，有效的组签名或环签名算法除了前面理论中提到的加密数字签名的基本特征外，还具有以下特征：

组匿名：认证者只能确认签名是否来自该组，但不能准确地放置在单个成员身上。无法连接：对于两个签名，认证者不知道两个签名的来源是否是同一个个人成员。

基本使用程序如下：

签名：同一集团的个别成员使用不同的私钥签署合同内容。验证签名：验证者使用该组的公钥验证签名。

以上的程序与经典数字签名最大的区别是，签名时可以使用多个不同私钥中的一个，但使用相同的公钥可以获得一定程度的匿名性。

更精细的组签名具有组管理员的设置，可以识别用自己的管理员私钥签名的个人成员的身份，对于一个成员，同一组内的其他成员不能冒充签名，从而实现监管仲裁。

相反，环签名不需要引入组管理器，每个个人可以自由选择不同的对象，可以自由配置隐藏自己身份的组，就像创建聊天组一样。有趣的是，Ron Rivest、Adi Shamir和Yael Tauman Kalai最初提出这一概念的论文题目为《How to leak a secret》，由此可见，环签名的最初目的是用于安全、匿名

在实际工作中，对于监管要求或上下从属结构相对稳定的方案，可以优先使用集团签名，邀请主管部门担任管理者的角色，并颁发与管辖范围内的个别成员相对应的签名私钥。如有必要，可以介入监管调整。

对于组织结构比较灵活、对匿名性要求较高、不想引入管理者的场景，环签名可能是更好的选择，个别成员可以自由选择组成员，从外部将自己展现为该组的成员。

请注意，集团签名和环签名的匿名性不是无条件的。使用时要具体注意的事项将在以下两部分具体展开。

使用组签名的注意事项

典型的组签名算法包括三种类型的角色，核心使用过程如下：

组管理器

负责初始化组设置

组管理私钥生成和自行存储

基于组管理私钥生成和公开组公钥

与新组成员协商，生成或分发成员的签名私钥

使用自己的组管理私钥，使用现有签名的身份解密组成员自己签名私钥，确认使用合同内容的组签名认证者当前组公钥接收的组签名

表明，在组签名的许多操作中，核心输入——组公钥由所有组成员共享。也就是说，如果组成员关系发生变化，则当前组公钥可能无效。

如上所述，可靠处置旧公钥和分发新公钥是一个相当困难的过程，现有阶段的主流解决方案必须依靠集中的公钥基础设施。尽管如此，也不能保证取消的公钥证书能及时反映在公钥黑名单列表中。

在现代商业环境中，动态的业务往来比比皆是，如果每一次群成员关系发生变更之后，都需要更新群公钥，那么群签名的实用性将大打折扣。

目前经典的群签名算法，对这一挑战提供了部分解决方案，以经典的BBS04群签名算法为例，增加新的群成员并不需要更新群公钥，群管理员可以使用群管理私钥增加任意多个群成员。

但BBS04核心算法并没有提供对删除群成员的直接支持，难以有效地支持被删除群成员签名私钥的撤销操作。为此，原论文和后续论文提出了一系列协议层面的扩展，来缓解这一问题，常见思路有：

• 定期公开一个私钥的撤销列表，其中可能包含所有被删除群成员的签名私钥或相关信息，并同时更新当前的群公钥，使得被撤销的群成员签名私钥无法生成与更新后群公钥匹配的有效签名。

• 当前的群公钥保持不变，但依旧定期或实时公开一个私钥的撤销列表，有效的群成员可以通过其他手段，如零知识证明，证明自己的签名私钥不在已公布的撤销列表中。

无论哪一类扩展，都引入了撤销列表的设计，在实际业务中，如果需要支持高频的群成员关系变更，如何保证其实时性和完整性都是不小的挑战。

对于现实业务系统，通常会倾向于保持当前群公钥的整体方案，减少密钥分发过程中带来的风险。以可信硬件执行环境TEE背后的EPID协议为例，其本质上是一个群签名，用于核实当前硬件设备是否为已注册且未被加入黑名单的TEE模块。硬件厂商和平台服务商可以通过提供一个远程硬件认证服务，实时对TEE模块的有效性进行验证，控制群成员撤销（即TEE硬件被破解）的相关风险。

环签名的使用注意事项

一个典型的环签名算法会涉及两类角色，其核心使用流程如下：

• 环成员

  ·初始化自己的签名公钥和私钥对，并公开广播自己的公钥

  ·监听广播，收集其他潜在环成员的公钥

  ·自主选择一组环成员，将自己的公钥混入其公钥列表中，生成本次环公钥

  ·结合环公钥和自己的签名私钥对契约内容进行环签名

  ·公布环签名结果和对应的环公钥

• 验证方

  ·使用环签名对应的环公钥，对收到的环签名进行验证，验证结果为签名方属于环成员之一

很多情况下，环签名算法每一次使用都会公布新的环公钥（附加在签名数据中），所以不涉及群签名中群成员关系变更后需要更新群公钥的问题。

但这一特点作为设计上的取舍，也影响了环签名的匿名性。环签名提供匿名性的强度，取决于收集到的其他潜在环成员公钥的数量和质量。环签名的验证方可以通过环公钥中的公钥列表，相对容易地推断出签名方的身份必然为其中之一。

如果可以通过PKI等公钥服务获得当前环成员公钥对应的身份，那更容易排除可能性低的签名方，从而进一步削弱环签名的匿名性。相比之下，群签名提供的匿名性，除了群管理员之外，验证方无法准确地获知当前群中到底有多少个成员，以及这些成员是谁。

所以环签名在使用时，需要引入足够数量不记名的环成员公钥，保证其匿名性得到落实。以近年来比较知名的环签名应用CryptoNote为例，在其使用过程中，环成员会产生一定数量的假账户，并为此分别生成随机公钥，以此来满足环成员数量和质量的要求，达成难以追溯的匿名性。

对于涉计n个环成员的环签名，其完整签名数据的大小一般至少为O(n)，作为去除群管理员的设计取舍，环签名的数据大小和计算复杂度通常会比群签名高。所以，如果不介意群管理员的设定，群签名通常是更优选择。

尽管核心设计目标都是隐匿签名方的身份，群签名和环签名在设计上各有取舍，一般情况下，可以参照下图进行基本的技术选型。

正是：身份涉密契约难签订，群环签名可隐亦可现！

数字化经济中，隐匿协作方的身份，对于开展涉及敏感隐私数据的高价值业务，或者需要基于匿名性保证流程公正有效的公共服务等，是不可或缺的前提。基于是否需要监管介入，以及协作方关系是否稳定等具体需求，酌情选用群签名或者环签名算法，可以在协作方不透露自己身份的前提下，实现有效契约的签订。

目前，群签名和环签名主要应用在投票、竞标、竞拍等场景，以保障参与者身份隐私，在联盟链治理中也有广泛应用。以微众银行牵头联合金链盟开源工作组开源的FISCO BCOS联盟链底层平台为例，平台通过集成群、环签名方案，为用户提供能够保证身份匿名性的工具。应用详情可参考《FISCO BCOS隐私特性：群/环签名技术实现》。

根据业务需求，群签名或者环签名的基础算法可以做进一步扩展，例如，增加门限特性，使得只有在多数协作方同意的前提下才能完成签名等。

门限特性也是密码学数字签名高频使用的高级特性之一，对保障多方协作中公平、对等的合作关系至关重要，技术上究竟如何实现，欲知详情，敬请关注下文分解。

作者：01区块链；来自链得得内容开放平台“得得号”，本文仅代表作者观点，不代表链得得官方立场凡“得得号”文章，原创性和内容的真实性由投稿人保证，如果稿件因抄袭、作假等行为导致的法律后果，由投稿人本人负责得得号平台发布文章，如有侵权、违规及其他不当言论内容，请广大读者监督，一经证实，平台会立即下线。如遇文章内容问题，请发送至邮箱：linggeqi@c