精华内容
下载资源
问答
  • 群签名与环签名介绍

    2021-01-08 04:49:52
    群签名 群签名,即群数字签名。是 1991 年 由 Chaum 和 van Heyst 提出的一个比较新的签名概念。Camenish、Stadler、Tsudik 等对这个概念进行了修改和完善。 群签名(group signature): 在一个群签名方案中,一个...
  • 在经典方案ACJT群签名方案的基础上,提出了一种基于椭圆曲线的前向安全的成员可撤销无证书群签名方案,改进了ACJT计算复杂、参数较多、签名较长的不足,减小了计算量及参数个数,缩短了签名长度,提高了方案效率,并...
  • 群签名方案是数字签名方案中非常重要的一种,允许群成员代表群进行签名而不泄露群成员的任何信息.而群签名方案中群成员的删除一直是一个难题.在此提出了一个基于网络认证的动态群签名方案,主要是为了解决群成员的...
  • PKI 盲签名 聚合签名 门限签名 代理签名 多重签名 群签名 等 介绍文档
  • 群签名方案Java实现

    2015-11-29 17:28:38
    这是一个群签名方案的实现过程demo,使用Java语言,不需要额外引用别的包
  • 给出一种新的动态群签名的构造方法。该方法以 BLS短签名方案为基础,构造出一种签名长度较短、结构简单的群签名方案。方案引入两个群管理员,一个管理员Issuer负责群成员的加入和群成员群密钥的分发;而另一个管理员...
  • 分级群签名* (2006年)

    2021-05-18 11:01:23
    现有的群签名方案均假设群成员具有相同的权限,首次提出分级群签名概念,并通过在一般的群签名中加入一个授权过程实现了分级群签名。该方案中,群成员具有不等的签名权限,任何群成员均不能对一个超出自己签名权限的...
  • 综述了群签名的定义与安全模型的演化、当前主流的基于ROM模型与标准模型的群签名方案及其构建技巧与方法, 并进行了比较; 讨论了当前实现群签名成员撤销这一重要操作的主要方法, 探讨了与群签名相关并有时容易混淆的...
  • 给出一种新的基于身份的群成员和群管理员的群签名方案。由于新方案的构造不需要零知识证明,群签名的产生是由群成员和群管理员合作完成的,所以新方案具有结构简单、签名长度短、群成员的加入和撤销可以即时实现、...
  • 提出了一个基于打印机管理模型的量子群签名协议。利用量子纠缠特性,打印机群组成员Alice可以代表群组进行签名,打印机管理员Bob可以证实签名来自该群组,但是不能够确定是哪一位成员进行了签名。如果出现了争议,群...
  • 通过对一种ElGamal类型存在特权集的门限群签名方案的分析研究,提出了一种基于ECC的存在特权集的门限群签名方案。该方案能有效防止KDC的欺诈,且只有在同时满足(t,n)和(t1,n1)门限签名时才能生成消息的有效签名,...
  • 主要讨论为了在考试管理系统中实现数据的安全性和一致性,结合数字签名技术,介绍了群签名在管理系统中的实现。
  • 环签名与群签名

    2020-12-31 00:43:19
    是一种简化的群签名,只有环成员没有管理者,不需要环成员间的合作。环签名方案中签名者首先选定一个临时的签名者集合,集合中包括签名者。然后签名者利用自己的私钥和签名集合中其他人的公钥就可以独立的产生签名,而...

    环签名:2001年,Rivest, shamir和Tauman三位密码学家首次提出了环签名。是一种简化的群签名,只有环成员没有管理者,不需要环成员间的合作。环签名方案中签名者首先选定一个临时的签名者集合,集合中包括签名者。然后签名者利用自己的私钥和签名集合中其他人的公钥就可以独立的产生签名,而无需他人的帮助。签名者集合中的成员可能并不知道自己被包含在其中。

    环签名方案由以下几部分构成:

    (1)密钥生成。为环中每个成员产生一个密钥对(公钥PKi,私钥SKi)。

    (2)签名。签名者用自己的私钥和任意n个环成员(包括自己)的公钥为消息m生成签名a。

    (3)签名验证。验证者根据环签名和消息m,验证签名是否为环中成员所签,如果有效就接收,否则丢弃。

    环签名满足的性质:

    (1)无条件匿名性:攻击者无法确定签名是由环中哪个成员生成,即使在获得环成员私钥的情况下,概率也不超过1/n。

    (2)正确性:签名必需能被所有其他人验证。

    (3)不可伪造性:环中其他成员不能伪造真实签名者签名,外部攻击者即使在获得某个有效环签名的基础上,也不能为消息m伪造一个签名。群签名:在一个群签名方案中,一个群体中的任意一个成员可以以匿名的方式代表整个群体对消息进行签名。与其他数字签名一样,群签名是可以公开验证的,且可以只用单个群公钥来验证。

    群签名一般流程:

    (1)初始化

    群管理者建立群资源,生成对应的群公钥(Group Public Key)和群私钥(Group Private Key)群公钥对整个系统中的所有用户公开,比如群成员、验证者等。

    (2)成员加入

    在用户加入群的时候,群管理者颁发群证书(Group Certificate)给群成员。

    (3)签名

    群成员利用获得的群证书签署文件,生成群签名。

    (4)验证

    同时验证者利用群公钥仅可以验证所得群签名的正确性,但不能确定群中的正式签署者。

    (5)打开

    群管理者利用群私钥可以对群用户生成的群签名进行追踪,并暴露签署者身份。

    环签名和群签名的比较:(1)匿名性。都是一种个体代表群体签名的体制,验证者能验证签名为群体中某个成员所签,但并不能知道为哪个成员,以达到签名者匿名的作用。

    (2)可追踪性。群签名中,群管理员的存在保证了签名的可追踪性。群管理员可以撤销签名,揭露真正的签名者。环签名本身无法揭示签名者,除非签名者本身想暴露或者在签名中添加额外的信息。提出了一个可验证的环签名方案,方案中真实签名者希望验证者知道自己的身份,此时真实签名者可以通过透露自己掌握的秘密信息来证实自己的身份。

    (3)管理系统。群签名由群管理员管理,环签名不需要管理,签名者只有选择一个可能的签名者集合,获得其公钥,然后公布这个集合即可,所有成员平等。

    参考网址:

    展开全文
  • 一种高效的(t,n)门限群签名方案
  • 一个具有前向安全性质的群签名方案,管婷婷,,签名密钥的安全性至关重要,一旦签名秘密密钥被泄漏,将会给整个系统带来灾难性的后果。在现实世界中,一个聪明的敌手主要还是针
  • 基于CS98加密方案和SDH假设,提出一种新的三元组(A,x,y)的零知识证明协议,并基于此协议构造了一种可证明安全的短群签名方案。该方案具有INDCCA2完全匿名性,允许新成员动态加入,并且群管理员不能伪造任何成员的...
  • 为了解决在基于身份的群签名中KGC不可信的问题,提出了一种新的基于身份的动态群签名方案。新的验证和打开算法确保了该方案可以抵抗伪造攻击。另外该方案可以简单有效地删除群成员,而不改变群公钥和其他群成员的...
  • 数字签名 类似在纸质合同上签名确认合同内容,数字签名用于证实某数字内容的完整性(integrity)和来源(或不可抵赖,non-repudiation)。 实际应用中,由于直接对原消息进行签名有安全性问题,而且原消息往往比较...

    数字签名

    类似在纸质合同上签名确认合同内容,数字签名用于证实某数字内容的完整性(integrity)和来源(或不可抵赖,non-repudiation)。

    实际应用中,由于直接对原消息进行签名有安全性问题,而且原消息往往比较大,直接使用RSA算法进行签名速度会比较慢,所以我们一般对消息计算其摘要(使用SHA-256等安全的摘要算法),然后对摘要进行签名。只要使用的摘要算法是安全的(MD5、SHA-1已经不安全了),那么这种方式的数字签名就是安全的。

    数字摘要

    顾名思义,数字摘要是对数字内容进行 Hash 运算,获取唯一的摘要值来指代原始数字内容。 数字摘要是解决确保内容没被篡改过的问题(利用 Hash 函数的抗碰撞性特点)。数字摘要是 Hash 算法最重要的一个用途。在网络上下载软件或文件时,往往同时会提供一个 数字摘要值,用户下载下来原始文件可以自行进行计算,并同提供的摘要值进行比对,以确 保内容没有被修改过。

    看一个具体场景:

    1,小明对外发布公钥,并声称对应的私钥在自己手上

    2,小明对消息M计算摘要,得到摘要D(digest)

    3,小明使用私钥对D进行签名,得到签名S(signature)

    4,小明将M和S一起发送出去

    接收方,验证过程如下:

    1,接收者先对消息M使用跟小明一样的摘要计算方法,得到摘要D‘

    2,使用小明的公钥对S进行解签,得到摘要D

    3,如果D和D’相同,那么证明M确实是小明发出的,并且没有被篡改过

    数字证书

    数字证书用来证明某个公钥是谁的,并且内容是正确的。

    对于非对称加密算法和数字签名来说,很重要的一点就是公钥的分发。一旦公钥被人替换(典型的如中间人攻击),则整个安全体系将被破坏掉。

    怎么确保一个公钥确实是某个人的原始公钥?

    这就需要数字证书机制。

    顾名思义,数字证书就是像一个证书一样,证明信息的合法性。由证书认证机构(Certification Authority,CA)来签发,权威的 CA 包括 verisign 等。

    数字证书内容可能包括版本、序列号、签名算法类型、签发者信息、有效期、被签发人、签发的公开密钥、CA 数字签名、其它信息等等,一般使用最广泛的标准为 ITU 和 ISO 联合制定的 X.509 规范。

    其中,最重要的包括 签发的公开密钥、CA 数字签名 两个信息。因此,只要通过这个证书就能证明某个公钥是合法的,因为带有 CA 的数字签名。

    接着上次的应用场景做假设:

    1,现在有第三者小红,小红想欺骗接收者,她偷偷使用了接收者的电脑,用自己的公钥换走了小明的公钥

    2,此时接收者实际拥有的是小红的公钥,但是还以为是小明的公钥,因此,小红就可以冒充小明,用自己的 私钥做成“数字签名”,发消息给接收者,让接收者用假的小明公钥进行解密

    3,后来,接收者感觉不对劲,发现自己无法确定公钥是否真的属于小明。他想到了一个办法,要求小明去“证书中心”(Certification authority, CA),为公钥做认证。

    4,证书中心用自己的私钥,对小明的公钥和一些相关信息一起加密,生成数字证书(Digital Certificate),小明再发消息,只要在签名的同事,再附上数字证书就可以了

    5,接收者收到消息后,用CA的公钥解开数字证书,拿到小明的真实公钥,然后就能证明“数字签名”是否真的是小明的。

    下面看一个应用“数字证书”的实例:https协议,这个协议主要用于网页加密。

    1.首先,客户端向服务器发出加密请求。

    2.服务器用自己的私钥加密网页以后,连同本身的数字证书,一起发送给客户端。

    3. 客户端(浏览器)的”证书管理器”,有”受信任的根证书颁发机构”列表。客户端会根据这张列表,查看解开数字证书的公钥是否在列表之内。

    4.如果数字证书记载的网址,与你正在浏览的网址不一致,就说明这张证书可能被冒用,浏览器会发出警告。

    5. 如果这张数字证书不是由受信任的机构颁发的,浏览器会发出另一种警告。

    6. 如果数字证书是可靠的,客户端就可以使用证书中的服务器公钥,对信息进行加密,然后与服务器交换加密信息。

    多重签名

    n 个持有人中,收集到至少 m 个(n≥1)的签名,即认为合法,这种签名被称为多重签名。

    其中,n 是提供的公钥个数,m 是需要匹配公钥的最少的签名个数。

    群签名

    1991 年由 Chaum 和 van Heyst 提出。群签名属于群体密码学的一个课题。

    群签名有如下几个特点:只有群中成员能够代表群体签名(群特性);接收者可以用公钥验证群签名(验证简单性);接收者不能知道由群体中哪个成员所签(无条件匿名保护);发生争议时,群体中的成员或可信赖机构可以识别签名者(可追查性)。

    Desmedt 和 Frankel 在 1991 年提出了基于门限的群签名实现方案。在签名时,一个具有 n 个成员的群体共用同一个公钥,签名时必须有 t 个成员参与才能产生一个合法的签名,t 称为门限或阈值。这样一个签名称为(n, t)不可抵赖群签名。

    环签名

    环签名由 Rivest,shamir 和 Tauman 三位密码学家在 2001 年首次提出。环签名属于一种简化的群签名。

    签名者首先选定一个临时的签名者集合,集合中包括签名者自身。然后签名者利用自己的私钥和签名集合中其他人的公钥就可以独立的产生签名,而无需他人的帮助。签名者集合中的其他成员可能并不知道自己被包含在其中。

    盲签名

    1983 年由 David Chaum 提出。签名者在无法看到原始内容的前提下对信息进行签名。

    盲签名主要是为了实现防止追踪(unlinkability),签名者无法将签名内容和结果进行对应。典型的实现包括 RSA 盲签名)。

    HMAC

    全称是 Hash-based Message Authentication Code,即“基于 Hash 的消息认证码”。基本过程为对某个消息,利用提前共享的对称密钥和 Hash 算法进行加密处理,得到 HMAC 值。该 HMAC 值提供方可以证明自己拥有共享的对称密钥,并且消息自身可以利用 HMAC 确保未经篡改。

    HMAC(K, H, Message)

    其中,K 为提前共享的对称密钥,H 为提前商定的 Hash 算法(一般为公认的经典算法),Message 为要处理的消息内容。如果不知道 K 和 H,则无法根据 Message 得到准确的 HMAC 值。

    HMAC 一般用于证明身份的场景,如 A、B 提前共享密钥,A 发送随机串给 B,B 对称加密处理后把 HMAC 值发给 A,A 收到了自己再重新算一遍,只要相同说明对方确实是 B。

    HMAC 主要问题是需要共享密钥。当密钥可能被多方拥有的场景下,无法证明消息确实来自某人(Non-repudiation)。反之,如果采用非对称加密方式,则可以证明。

     

    展开全文
  • 多重群签名是既具有群签名的性质,又具有多重数字签名性质的特殊的群签名。在基于中国剩余定理的群签名的基础上进行改进,引入椭圆曲线的Schnorr型广播多重数字签名,将动态群签名方案与多重数字签名理论巧妙地结合...
  • 群签名与环签名总结

    2020-06-14 19:42:53
    文章目录**1、群签名(group signature)**2、环签名(ring signature)3、群签名和环签名主要特性对比4、签名流程5、sig-service-client 基本功能5.1 群签名5.2 环签名6、应用场景6.1 群签名场景6.2 环签名场景 ...


    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 模型下,可将环签名算法应用于匿名交易,任何人都无法追踪转账交易双方

    展开全文
  • 为了解决签名方权限不同的问题, 出现了许多存在特权集门限群签名方案 。本文通过对一种ElGamal 类型存在特权集的门限群签名方案的分析研究, 发现该方案不满足群签名特性以及存在单签名不可区分的缺陷。针对上述不足 ...
  • 目前大部分本地验证者撤销群签名方案都是在随机预言模型下证明方案的安全性,但是这种理想的预言机在现实世界中是不存在的,构造标准模型下可证安全的群签名方案仍是当前研究的热点课题.本文在Boyen-Waters群签名方案...
  • 针对Camenisch-Stadler群签名方案中无法撤销成员的问题,提出了一种有效的群成员撤销方案,该方案可以灵活地增加和撤销群成员。当成员加入时,群主管向其颁发成员证书,其他成员无需更新成员密钥和证书;当成员撤销...
  • 为了研究群签名方案的前向安全性和后向安全性保证技术,基于哈希链实现了一种具备前向安全和后向安全的群签名方案,在密钥更新阶段采用门限方法与其他成员共享其每个时间周期内的子秘密,在签名生成阶段成员利用公开...
  • 想查看网上有没有开源的环签名算法实现,搜了一圈最终只发现 FISCO-BCOS(金链盟区块链底层开源平台) 有相关的开源代码且有详细的文档,并提供额外的开源库给用户体验与尝试群签名和环签名的服务,恰好符合我的需求...



    最近需要使用环签名算法实现签名与签名验证(群签名与环签名的介绍),想查看网上有没有开源的环签名算法实现,搜了一圈最终只发现 FISCO-BCOS(金链盟区块链底层开源平台) 有相关的开源代码且有详细的文档,并提供额外的开源库给用户体验与尝试群签名和环签名的服务,恰好符合我的需求,于是我开始着手部署这些开源项目。

    由于提供群签名和环签名服务的两个开源库已是两年前的项目了,并且该项目文档也存在一些纰漏,导致我在部署的过程中遇到了不少坑,浪费了很多时间,此处记录一下,希望能帮到有类似需求的朋友。

    如果和我一样,只想使用签名和验证签名的 RPC 而不需要上链和在链上进行验证的话,则只需配置部署以下两个项目的源码即可:

    1. Sig-service
    2. Sig-service-client


    我对这两个开源库的主要修改

    服务端:

    • README.md —— 2.1 部署依赖软件包:
      • ln -s /usr/bin/todos /usr/bin/unxi2dos 修改为 sudo ln -s /usr/bin/todos /usr/bin/unix2dos
      • ln -s /usr/bin/fromdos /usr/bin/dos2unix 修改为 sudo ln -s /usr/bin/fromdos /usr/bin/dos2unix
      • 添加 sudo apt install libjsonrpccpp-dev libjsonrpccpp-tools
    • README.md —— 2.3 使用说明:
      • 最后的启动示例,将监听端口修改为 8003,与客户端示例保持一致。
    • sig-service/devcore/ConfigParser.h :
      • 将文件中 第 73 行的<S>删除

    客户端:

    • README.md —— 2.1 依赖部署:
      • ln -s /usr/bin/todos /usr/bin/unxi2dos 修改为 sudo ln -s /usr/bin/todos /usr/bin/unix2dos
      • ln -s /usr/bin/fromdos /usr/bin/dos2unix 修改为 sudo ln -s /usr/bin/fromdos /usr/bin/dos2unix
    • sig-service-client/sig_client/src/main/executive/shell/runSigService.sh:
      • 添加将环签名字符串 json 格式化的命令
      • 添加环签名有效性验证的的命令示例

    实验环境

    • 操作系统:Ubuntu 18.04.3 LTS 64bit
    • 内存:2G
    • CPU: i7-9700 3.0Ghz * 2 (两核)
    • 硬盘:40G

    开始部署:

    1. 客户端与服务端都需要的环境部署

    (若客户端与服务端在同一台机器或虚拟机上,则部署一次就行)

    1.1 安装基础依赖软件

    部署群签名 && 环签名 RPC 服务之前,要安装 git, dos2unxi, lsof 等依赖软件:

    • git:用于拉取最新代码
    • dos2unix && lsof: 用于处理 windows 文件上传到 linux 服务器时,可执行文件无法被 linux 正确解析的问题;

    可用如下命令安装这些基础依赖软件(注意区分 centos 和 ubuntu 系统使用的命令):

    [centos]
    sudo yum -y install git
    sudo yum -y install dos2unix
    sudo yum -y install java
    sudo yum -y install lsof
    
    [ubuntu]
    sudo apt install git
    sudo apt install lsof
    sudo apt install tofrodos
    
    sudo ln -s /usr/bin/todos /usr/bin/unix2dos
    sudo ln -s /usr/bin/fromdos /usr/bin/dos2unix
    

    以上命令大约共耗时 5 分钟

    部署 dos2unix 后,调用 format.sh 脚本格式化可执行文件,使其可被 linux 系统正确解析:

    # 格式化format.sh脚本
    dos2unix format.sh
    # 执行format.sh脚本格式化其他可执行文件,使其可被正确解析执行
    bash format.sh
    

    2. 签名 RPC 服务端的部署

    2.1 安装 levelDB、gmp 等依赖软件

    拉取官方 git 代码

    git clone https://github.com/FISCO-BCOS/sig-service.git

    或拉取我个人修改过的 git 代码

    git clone https://github.com/yohstone/sig-service.git

    群签名&&环签名 rpc 服务,需要安装 levelDB, gmp 等依赖软件,sig-service 在 script 目录下提供了 install_deps.sh 脚本,执行以下命令安装这些依赖软件:

    # git 代码目录下进入 script 目录 && 执行 install_deps.sh 脚本
    cd script && sudo bash install_deps.sh
    

    此过程大约耗时 1 ~ 3 个小时,视网速而定,建议更改 Ubuntu 的软件源,下载会更快。
    更改软件源方法

    2.2 安装群签名算法依赖软件 pbc 和 pbc-sig

    群签名算法依赖 pbc 库和 pbc-sig 库,部署群签名&&环签名 RPC 服务前,首先要安装 pbc 和 pbc-sig 库,sig-service 在 script 目录下提供了 pbc 和 pbc-sig 一键安装脚本 install.sh,执行以下命令安装 pbc 和 pbc-sig:

    # 进入 script 目录,执行 install.sh 脚本安装 pbc 和 pbc-sig
    cd script && sudo bash install.sh
    # 或者 (注:执行下面命令前,需要先保证 install.sh 脚本可执行 :
    # chmod +x install.sh 可使其可执行)
    cd script && sudo ./install.sh
    

    此过程大约耗时1个小时(下载卡住很久时,建议按 ctrl + c 强行结束,然后重新运行命令)

    安装后提示:
    在这里插入图片描述

    2.3 编译安装群签名&&环签名 RPC 服务

    # 编译 sig-service
    # 方法一: 使用 compile 脚本编译
    cd sig-service && bash compile.sh
    # 或者: (注:执行下面命令前,需要先保证 compile.sh 脚本可执行 :chmod +x compile.sh 可使其可执行)
    cd sig-service && ./compile.sh
    
    # 方法二: 手动编译, 其中 -j4 表示用 4 个线程并发编译,
    # 用户可根据机器实际配置动态调整编译线程数
    ##(1)【Centos 系统】编译后,会在 build 目录下生成 rpc 服务程序 server
    cd sig-service && mkdir -p build && cd build && cmake3 .. && make -j4
    ###(2)【Ubuntu 系统】编译后,会在 build 目录下生成 rpc 服务程序 server
    cd sig-service && mkdir -p build && cd build && cmake .. && make -j4
    
    

    编译期间遇到问题:
    在这里插入图片描述
    可以看到报错提示是 JsonRpcCpp::Server 这个库路径不存在,库找不到,所以需要下载安装这个库:

    sudo apt install libjsonrpccpp-dev libjsonrpccpp-tools
    

    一般运行完以上命令就能继续编译了,若不行,可以继续运行以下的备用命令:

    sudo apt install libcurl3
    sudo apt install libmicrohttpd-dev
    sudo apt install libjsoncpp1
    sudo apt install libjsoncpp-dev
    sudo apt install libargtable2-0
    sudo apt install libargtable2-dev
    sudo apt install curl
    sudo apt install libcurl4-openssl-dev
    

    安装好后重新运行编译命令(建议每次重新编译前都将之前编译失败生成的 build/ 目录删掉);
    有可能会卡在类似下图的下载压缩包的过程,视你的网络状况而定
    在这里插入图片描述
    为了缩短编译过程的时间,建议先把所有的压缩包都下载好,然后放到一个目录下(我是放在 /home/test1/research/files_lib/ 目录下的),将源码中的对应下载路径直接修改为你存放压缩包的路径,如下:
    在这里插入图片描述
    修改示例:

    • cmake/ProjectBoost.cmake 中的 https://github.com/ethereum/cpp-dependencies/releases/download/cache/boost_1_63_0.tar.gz
      修改为:/home/test1/research/files_lib/boost_1_63_0.tar.gz
    • cmake/ProjectCryptopp.cmake 中的 https://github.com/weidai11/cryptopp/archive/bccc6443c4d4d611066c2de4c17109380cf97704.tar.gz
      修改为:/home/test1/research/files_lib/cryptopp-bccc6443c4d4d611066c2de4c17109380cf97704.tar.gz
    • cmake/ProjectJsonCpp.cmake 中的 : https://github.com/open-source-parsers/jsoncpp/archive/1.7.7.tar.gz
      修改为:/home/test1/research/files_lib/jsoncpp-1.7.7.tar.gz

    所有可能需要用的压缩包我已经上传至百度云,可自行下载:

    百度云
    链接:https://pan.baidu.com/s/1tLGDar3Lw1U3J2OK2nt4Jw 
    提取码:apf6
    

    然后重新编译(建议每次重新编译前都将之前编译失败生成的 build/ 目录删掉),
    此时编译到 55% 时遇到以下报错:
    在这里插入图片描述
    报错提示的是 /home/test1/research/sig-service/devcore/ConfigParser.h 文件中存在语法错误。

    解决办法:
    找到并打开改文件,将 /home/test1/research/sig-service/devcore/ConfigParser.h 文件中 第 73 行的 删除:在这里插入图片描述

    再次重新编译(建议每次重新编译前都将之前编译失败生成的 build/ 目录删掉);

    若编译结束显示 [100%] Built target server,并在 build 文件目录下生成 rpc 服务程序 server,则表示编译成功了,如下图:
    在这里插入图片描述
    此时签名 RPC 服务端部署配置完成。

    官方文档中提到的配置文件可以根据自己需要进行修改,也可以直接使用默认的设置(建议修改log.conf 中的日志文件路径)。
    最后,使用以下命令运行 RPC 服务测试一下:

    # 在 8003 端口启动群签名&&环签名 RPC 服务,日志配置文件路径是 bak/log.conf; 
    # 开启的 http 线程数目是 1000
    $ chmod +x build/server && ./build/server -p 8003 -n 1000 -l bak/log.conf 
    port:8003 thread:1000
    ADD HTTP CONNECTOR TO test_server
    start listening on port 8005
    
    ### 若要把 server 放到后台执行,则可借助 screen, tmux, nohup 等工具,
    # 用 nohup 将程序放到后台执行的命令示例:
    chmod +x build/server && nohup ./build/server -p 8003 -n 1000 -l bak/log.conf &
    
    

    如图是我的启动示例:
    在这里插入图片描述
    表示 RPC 服务端启动成功。
    到此签名服务端部署成功。
    此过程需要 3 个小时左右。

    3. 签名客户端的部署

    3.1 拉取 sig-service-client 代码
    • 从 git 上拉取代码
    • 若是 linux/unix 环境,安装依赖软件之后,执行 format.sh 脚本格式化 shell 脚本和 json 配置文件,使其可被 linux/unix 正确解析
    	# 拉取官方 git 代码
    	git clone https://github.com/FISCO-BCOS/sig-service-client.git
    	# 或拉取我个人修改过的 git 代码
    	git clone https://github.com/yohstone/sig-service-client.git
    	# 格式化 shell 脚本和 json 配置文件
    	$ bash format.sh
    

    3.2 编译群签名&&环签名客户端

    编译依赖软件如下:

    软件版本
    jdkjdk 1.8以上
    gradlegradle 4.6以上

    为了方便用户,sig-service-client 在 sig_client 文件夹下配备了自动化编译脚 compile.sh(针对centos/ubuntu运行环境,windows 环境下也可用 gradle 编译)

    用户通过运行该脚本编译客户端:

    	# 进入 sig_client 目录
    	[test1@ubuntu:~/research/sig-service-client]$ cd sig_client/    
    	[test1@ubuntu:~/research/sig-service-client/sig_client]$ ls
    	build.gradle  compile.sh  lib  src
    	# 调用 compile 脚本编译群签名&&环签名客户端
    	# compile.sh 脚本主要包括如下功能:
    	# (1) 判断系统 java 版本(jdk 版本必须大于 1.8)
    	# (2) 若系统 java 版本小于 1.8 或者系统没安装 java,则脚本从官网下载并安装 jdk1.8
    	# (3) 根据操作系统类型安装依赖包(目前支持 Ubuntu 和 centos/federa )
    	# (4) 下载并安装 gradle4.6 (首次编译时安装,之后再编译不会再安装)
    	# (5) 使用 grandle build 命令编译 java 工程,产生客户端 jar 包 sig_client.jar: 
    	#    会在 sig_client 目录下生成 sig_client_toolkit 目录,所有 jar 包都位于 sig_client_toolkit/lib 目录下
    	# 注:首次编译时,由于可能会安装 java 和 gradle,因此要用 root 权限执行 compile 脚本(执行时加 sudo)
    	#     之后如果再重新编译,则以
    	$ sudo bash compile.sh 
    

    我编译之后遇到的问题:

    在这里插入图片描述
    明显是因为 gradle 没安装,自己运行: sudo apt install gradle
    然后再次编译 bash compile.sh
    编译结束后显示:
    在这里插入图片描述
    至此,客户端编译部署完成。



    4. 群签名&&环签名客户端使用

    编译完 sig-service-client 后,sig-service-client/sig_client/sig_client_toolkit/bin 目录下会生成可执行文件 runSigService.sh,该文件封装了群签名&&环签名客户端所有接口,可在其中添加相应接口调用,然后运行该文件,进而使用客户端。

    (客户端接口列表详情可参考:群签名&&环签名客户端接口

    运行 runSigService.sh 前,需要先修改 sig-service-client/sig_client/sig_client_toolkit/bin 目录下的 conn.json 文件,将ip 和 端口修改为服务端的 ip 和 服务端监听的端口,如 8003 :
    在这里插入图片描述
    然后修改脚本文件 runSigService.sh,将想要调用的接口前的注释去掉,此处我以环签名为例:
    在这里插入图片描述
    将446 ~ 451 行代码的注释去掉,这些代码的作用分别是:
    初始化一个名为 ring1 的环;(第 446 行)
    在环中加入 4 个成员;(第 447 ~ 450 行)
    为环 ring1 在位置 0 处的环成员生成对消息 hello 的环签名,环签名中环成员数为 4;(第 451 行)

    然后运行 runSigService.sh : sudo bash runSigService.sh
    开始生成签名
    运行过程中可能会有一些 WARNING 提示,这是因为项目代码库使用的 jdk 是 1.8 的版本,然而我们安装的 jdk 有可能是最新版,有些代码以后可能会不兼容了,所以会给你提示,暂时不管。
    签名成功后,服务端会返回一个 json 字符串,其中会有环签名相关的信息,如下图:
    在这里插入图片描述
    然后验证签名:

    • 先修改 runSigService.sh 中的代码:
      添加命令 ring_verify "conn.json" "ring1" '' "hello" 到文件中,并将之前的代码注释掉。
      在这里插入图片描述
    • 然后复制返回的签名,如下图白色部分,即 “sig” 字段的值:

    在这里插入图片描述

    • 然后将该签名值粘贴到 命令 ring_verify "conn.json" "ring1" '' "hello" ring1 与 hello 之间的单引号中,如下图:
      在这里插入图片描述
      但如果此时你直接验证的话,会提示验证失败:
      在这里插入图片描述
      此时,若去看服务端的 log 日志的话,你就会发现服务端根本没有解析成功你发过去的签名。
      也就是说该签名不是服务端能验证的 json 格式。
      当初我在这个问题上卡了两个小时,经过不断尝试之后,我总结出服务端能接受的 json 格式为:
      除了要符合 json 字符串的基本格式外,还需要给每个符号添加转义符,同时字符串内不能有空格。
      所以,需要先对签名字符串进行处理,我写了以下这条命令进行处理:
      # delete space and \n , replace ',' with '\,' in the str
      echo '' | sed 's/[[:space:]]//g' | sed 's/\\n//g' | sed 's/,/\\,/g'    
      
      
      只要将签名字符串插入 echo 之后的单引号 ‘’ 里,然后运行该命令,输出的结果就是符合服务端要求的 json 字符串,直接复制到 ring verify 命令里就行了。
      这是正确的 json 格式字符串示例:
      在这里插入图片描述
      运行验证之后可以看到验证成功:
      在这里插入图片描述
      至此,客户端部署完成,并测试使用成功。
      整个过程大约耗时 3 个小时。

    结语

    若需要上链,并且在链上验证签名的话,还需要部署 FISCO-BCOS 项目的代码。
    我根据 sig-service-client 的文档,尝试部署了 FISCO-BCOS master-1.3 的版本,因为版本比较旧,文档也比较混乱,所以遇到了很多问题,目前节点间还没能正常相互连接。由于我的需求已经满足,就暂时不继续弄了,也没什么时间。

    倘若哪位朋友有上链并且在链上验证签名的需求的话,我推荐还是部署最新版的 FISCO-BCOS 项目代码,遇到的问题应该会少很多。

    以上,如有问题,欢迎指正哈~

    展开全文
  • 群签名的理解

    千次阅读 2019-10-09 16:32:37
    最近在做相关项目的时候接触到了一个名词叫:群签名 什么叫群签名呢,或者说群签名能够达到什么效果呢,我个人理解,如有不对,请批评指正: 群签名定义:假设有那么一群设备,他们属于一个群体,群签名达到的效果...
  • 龙源期刊网http://www.qikan.com.cn群签名和环签名在匿名通信中的应用作者:孙庆英来源:《电脑学习》2010年第06期摘要:设文介绍了群签名和环签名技术在匿名通信中的应用。并从匿名性、可追踪性、管理节点达几方面做...
  • 群签名和环签名

    2021-04-19 09:12:45
    群签名和环签名的对比 1.管理系统:环签名中没有管理者,群签名中存在管理者,为其他成员分发密钥; 2.匿名性:环签名中任何参与者都不知道签名者是谁,群签名中管理者可确定签名者的身份,实现群签名的可追踪性; 3...
  • 本文主要介绍论文《Short Group Signatures》群签名的go语言版本的具体实现。 本文是在参考 yunfeiyanggzq 的实现基础上,进行了进一步的改造加工,以此为基础进行的详细解释。其代码地址为: ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 24,932
精华内容 9,972
关键字:

群签名

友情链接: RoboCup.zip