文章目录
1、群签名（group signature）
群签名（group signature）即某个群组内一个成员可以代表群组进行匿名签名。签名可以验证来自于该群组，却无法准确追踪到签名的是哪个成员。
群签名需要存在一个群管理员来添加新的群成员，因此存在群管理员可能追踪到签名成员身份的风险。
群签名最早于1991年由David Chaum和Eugene van Heyst提出。
2、环签名（ring signature）
由Rivest、Shamir和Tauman三位密码学家在2001年首次提出。环签名属于一种简化的群签名。环签名中只有环成员没有管理者,不需要环成员间的合作。
签名者首先选定一个临时的签名者集合，集合中包括签名者自身。然后签名者利用自己的私钥和签名集合中其他人的公钥就可以独立地产生签名，而无需他人的帮助。
生成过程
1、密钥生成。为环中每个成员产生一个密钥对(公钥PKi,私钥SKi)。
2、签名。签名者用自己的私钥和任意n个环成员(包括自己)的公钥为消息m生成签名a。
3、签名验证。验证者根据环签名。和消息m,验证签名是否为环中成员所签,如果有效就接收,否则丢弃。
应用例如，某个用户在线下进行消费，并通过比特币进行支付，那么商家事实上建立了对用户的线上（比特币地址）线下（用户身份）关联。为避免个人隐私信息的泄露，用户必须十分谨慎地对其比特币帐户地址进行管理和隔离。从这个角度来而言，比特币无法满足交易不可追踪和不可关联的条件。
而基于群签名（group signatures）基础上环签名（ring signatures）技术，提供了可行的匿名性解决办法。环签名在保护匿名性方面有很多的用途。
环签名因为其签名隐含的某个参数按照一定的规则组成环状而得名。而在之后提出的许多方案中不要求签名的构成结构成环形，只要签名的形成满足自发性、匿名性和群特性，也称之为环签名。
3、群签名和环签名主要特性对比
| 算法 | 特性 |
|---|---|
| 群签名 | 1. 匿名性：群成员用群参数产生签名，其他人仅可验证签名的有效性，并通过签名知道签名者所属群组，却无法获取签名者身份信息； 2. 可追踪性: 在监管介入的场景中，群主可通过签名获取签名者身份. |
| 环签名 | 1. 完全匿名性：其他人仅可验证环签名的有效性，无法获取签名者身份信息； 2. 不可追踪性：无法追踪签名对应的签名者信息. |
4、签名流程
| 流程 | 说明 |
|---|---|
| 生成群 | 生成群公钥(gpk)，群主私钥(gmsk)和群参数(可用不同线性对参数生成群，sig-service支持A， A1， E 和 F类型线性对，默认使用A类型线性对) |
| 加入群 | 群主为群成员产生私钥(gsk)和证书(cert) |
| 生成群签名 | 群成员用私钥和证书产生群签名 |
| 群签名验证 | 其他人通过群公钥、群参数验证群签名信息的有效性（此时其他人仅知道签名者属于哪个群，但无法获取签名者身份信息） |
| 追踪签名者信息 | 在监管介入场景中，群主通过签名信息可获取签名者证书，从而追踪到签名者身份 |
环签名主要流程
| 流程 | 说明 |
|---|---|
| 初始化环 | 生成环参数 |
| 为环成员产生公私钥对 | 成员加入环时，rpc 服务为环成员产生公私钥对 |
| 生成环签名 | 环成员使用私钥和其他环成员公钥产生匿名签名，环大小可由用户根据性能和安全性需求自定义指定（环越大，安全性越高，性能越低；环越小，安全性越低，性能越低，sig-service 默认环大小为 32） |
| 环签名验证 | 其他人通过环参数和产生环签名的公钥列表，验证环签名的有效性 |
5、sig-service-client 基本功能
5.1 群签名
** 向机构内成员提供生成群、密钥托管以及群签名服务 **
机构内成员通过客户端sig_client访问群签名服务，可生成群、加入指定群、请求获取群签名；
部署在可信第三方的群签名服务提供密钥托管功能；
机构成员可通过调整线性对参数，折中安全性和签名速度
向监管机构提供签名者追踪服务
监管可通过群主获取某个签名对应的签名者身份
5.2 环签名
向机构内成员提供生成环签名服务
成员可根据安全性需求动态调整环大小，在安全性和签名速度两方面做折中
支持密钥托管 && 密钥自管理
签名验证 && 存证
通过 sig_client 客户端，可链上验证群签名 && 环签名，保证签名不可篡改；
sig_client 客户端以联盟链机构身份（如 webank 等）将签名数据上链，其他成员可重复验证签名的有效性（存证的简单 demo）；
区块链上其他成员通过签名无法获取机构成员的身份信息，仅可获取成员所属的机构和群组；
6、应用场景
6.1 群签名场景
场景1： 机构内成员（C端用户）通过客户端 sig_client 访问机构内群签名服务，并在链上验证签名，保证成员的匿名性和签名的不可篡改，监管也可通过群主（可信机构，如 webank）追踪签名者信息（如拍卖、匿名存证等场景）
场景2：机构内下属机构各部署一套群签名服务，通过上级联盟链机构成员，将签名信息写到区块链上，链上验证群签名，保证签名的匿名性和不可篡改；（如征信等场景）
场景3：B端用户部署群签名服务，生成群签名，通过 AMOP 将签名信息发送给上链结构(如webank)，上链机构将收集到的签名信息统一上链（如竞标、对账等场景）
6.2 环签名场景
场景1（匿名投票）：机构内成员（C端用户）通过客户端 sig-service-client 访问机构内环签名服务，对投票信息进行签名，并通过可信机构（如 webank）将签名信息和投票结果写到链上，其他人可验证签名和投票，仅可知道发布投票到链上的机构，却无法获取投票者身份信息
其他场景（如匿名存证、征信）：场景与群签名匿名存证、征信场景类似，唯一的区别是任何人都无法追踪签名者身份
匿名交易：在 UTXO 模型下，可将环签名算法应用于匿名交易，任何人都无法追踪转账交易双方
来源：oschina
链接：https://my.oschina.net/u/4403932/blog/4311717