群签名与环签名介绍

群签名

群签名，即群数字签名。是 1991 年 由 Chaum 和 van Heyst 提出的一个比较新的签名概念。Camenish、Stadler、Tsudik 等对这个概念进行了修改和完善。

群签名（group signature）：
在一个群签名方案中，一个群体中的任意一个成员可以以匿名的方式代表整个群体对消息进行签名。与其他数字签名一样，群签名是可以公开验证的，而且可以只用单个群公钥来验证。

环签名

环签名 (ring signature) 是一种数字签名方案，最初由 Rivest 等人提出，环签名是一种简化的群签名，环签名中只有环成员没有管理者，不需要环成员间的合作。

实现：
假定有 n 个用户，每一个用户$u_i$ 拥有一个公钥 $y_i$ 和与之对应的私钥 $x_i$ 。环签名是一个能够实现签名者无条件匿名的签名方案，它主要由下述算法组成：

1. 生成 Gen。一个概率多项式时间（PPT）算法，输入为安全参数 k，输出为公钥和私钥。这里假定 Gen 为每一个用户 $u_i$，产生一个公钥 $y_i$ 和私钥 $x_i$ ，并且不同用户的公私钥可能来自不同的公钥体制，如有的来自 RSA，有的来自 DL。
2. 签名 Sign。一个 PPT 算法，在输入消息 m 和 n 个环成员的公钥 $L=y_1,y_2,\cdots ,y_n$以及其中一个成员的私钥 $x_s$ 后，对消息 m 产生一个签名 R，其中 R 中的某个参数根据一定的规则呈环状。
3. 验证 Verify。一个确定性算法，在输入 (m, R) 后，若 R 为 m 的环签名则输出 “True”，否则为 “False”。

环签名因为其签名隐含的某个参数按照一定的规则组成环状而得名。而在之后提出的许多方案中不要求签名的构成结构成环形，只要签名的形成满足自发性、匿名性和群特性，也称之为环签名。

群签名和环签名主要特性对比

算法	特性
群签名	1. 匿名性：群成员用群参数产生签名，其他人仅可验证签名的有效性，并通过签名知道签名者所属群组，却无法获取签名者身份信息； 2. 可追踪性: 在监管介入的场景中，群主可通过签名获取签名者身份.
环签名	1. 完全匿名性：其他人仅可验证环签名的有效性，无法获取签名者身份信息； 2. 不可追踪性：无法追踪签名对应的签名者信息.

签名流程

群签名主要流程

流程	说明
生成群	生成群公钥(gpk)，群主私钥(gmsk)和群参数(可用不同线性对参数生成群，sig-service支持A， A1， E 和 F类型线性对，默认使用A类型线性对)
加入群	群主为群成员产生私钥(gsk)和证书(cert)
生成群签名	群成员用私钥和证书产生群签名
群签名验证	其他人通过群公钥、群参数验证群签名信息的有效性（此时其他人仅知道签名者属于哪个群，但无法获取签名者身份信息）
追踪签名者信息	在监管介入场景中，群主通过签名信息可获取签名者证书，从而追踪到签名者身份

环签名主要流程

流程	说明
初始化环	生成环参数
为环成员产生公私钥对	成员加入环时，rpc 服务为环成员产生公私钥对
生成环签名	环成员使用私钥和其他环成员公钥产生匿名签名，环大小可由用户根据性能和安全性需求自定义指定（环越大，安全性越高，性能越低；环越小，安全性越低，性能越低，sig-service 默认环大小为 32）
环签名验证	其他人通过环参数和产生环签名的公钥列表，验证环签名的有效性

sig-service-client 基本功能

群签名

** 向机构内成员提供生成群、密钥托管以及群签名服务 **

• 机构内成员通过客户端sig_client访问群签名服务，可生成群、加入指定群、请求获取群签名；
• 部署在可信第三方的群签名服务提供密钥托管功能；
• 机构成员可通过调整线性对参数，折中安全性和签名速度

向监管机构提供签名者追踪服务

• 监管可通过群主获取某个签名对应的签名者身份

环签名

向机构内成员提供生成环签名服务

• 成员可根据安全性需求动态调整环大小，在安全性和签名速度两方面做折中
• 支持密钥托管 && 密钥自管理

签名验证 && 存证

• 通过 sig_client 客户端，可链上验证群签名 && 环签名，保证签名不可篡改；
• sig_client 客户端以联盟链机构身份（如 webank 等）将签名数据上链，其他成员可重复验证签名的有效性（存证的简单 demo）；
• 区块链上其他成员通过签名无法获取机构成员的身份信息，仅可获取成员所属的机构和群组；

应用场景

（1）群签名场景

• 场景1： 机构内成员（C端用户）通过客户端 sig_client 访问机构内群签名服务，并在链上验证签名，保证成员的匿名性和签名的不可篡改，监管也可通过群主（可信机构，如 webank）追踪签名者信息（如拍卖、匿名存证等场景）

• 场景2：机构内下属机构各部署一套群签名服务，通过上级联盟链机构成员，将签名信息写到区块链上，链上验证群签名，保证签名的匿名性和不可篡改；（如征信等场景）

• 场景3：B端用户部署群签名服务，生成群签名，通过 AMOP 将签名信息发送给上链结构(如webank)，上链机构将收集到的签名信息统一上链（如竞标、对账等场景）

（2）环签名场景

• 场景1（匿名投票）：机构内成员（C端用户）通过客户端 sig-service-client 访问机构内环签名服务，对投票信息进行签名，并通过可信机构（如 webank）将签名信息和投票结果写到链上，其他人可验证签名和投票，仅可知道发布投票到链上的机构，却无法获取投票者身份信息

• 其他场景（如匿名存证、征信）：场景与群签名匿名存证、征信场景类似，唯一的区别是任何人都无法追踪签名者身份

• 匿名交易：在 UTXO 模型下，可将环签名算法应用于匿名交易，任何人都无法追踪转账交易双方；