Schnorr协议:非交互零知识身份证明和数字签名

本文首发公众号VenusBlockChain,VenusBlockChain致力于区块链技术研究,传播区块链技术和解决方案、区块链应用落地、区块链行业动态等。欢迎关注公众号VenusBlockChain

摘要:本篇文章介绍Schnorr的两大应用场景:从交互式零知识身份证明到非交互零知识身份证明、数字签名实现基本原理、菲亚特-沙米尔(Fiat-Shamir)变换。
在这里插入图片描述

1.Schnorr简介

Schnorr机制由德国数学家和密码学家Claus-Peter Schnorr在1991年提出,是一种基于离散对数难题的知识证明机制。Schnorr本质上是一种零知识的技术,即Prover声称知道一个密钥x的值,通过使用Schnorr加密技术,可以在不揭露x的值情况下向Verifier证明对x的知情权。即可用于证明你有一个私钥。

Schnorr中涉及到的技术有哈希函数的性质、椭圆曲线的离线对数难题。椭圆曲线的离线对数难题:已知椭圆曲线E和点G,随机选择一个整数d,容易计算Q=d*G,但是给定的Q和G计算d就非常困难。

2.技术价值

  • 证明你知道一个私钥,可用于身份识别中。
  • 数字签名。

本文中所有出现的变量,小写字母表示标量,即一个数字,在这里指整数;大写字母表示离散对数问题中的参数,例如:椭圆曲线中的点。

3.交互式Schnorr

在这里插入图片描述
原始的Schnorr机制是一个交互式的机制。在讲述其机制时,不得不请出密码学中的两个虚拟大人物Alice和Bob。注意,这两位可不是省油的灯,都存在作弊的可能性!

3.1场景描述

允许在任何拥有相同生成元(指在离散对数问题中)的协议参与者双方,证明某一方拥有私钥sk(sk=a)而不需要直接交换它。其中双方都拥有的生成元设为G,Prover(Alice)拥有私钥sk。Verifier(Bob)已经从Prover处取得Alice的公钥PK。简而言之,Bob要在不知道a的情况下验证Alice知道它。

3.1交互式Schnorr协议流程

  • Alice:随机地选择一个标量r,然后计算出R=r*G(椭圆曲线上的一点),将R发送给Bob;
  • Bob:回应一个随机标量c;
  • Alice:通过计算z=r+c*sk,将标量z回应给Bob;
  • Bob:将s转换为椭圆曲线上的点,即zG,然后验证zG?=c*PK+R。

3.2零知识解释

由于z=r+csk,等式两边同时添加相同的生成元可得:zG=c*PK+R。即可验证Alice确实拥有私钥sk,但是验证者Bob并不能得到私钥sk的值,因此这个过程是零知识的,且是交互式的。此协议也叫做Sigma protocol[1], Sigma protocol论文地址[2]。
安全性分析

由于椭圆曲线上的离散对数问题,知道R和G的情况下通过R=r*G解出r是不可能的,所以保证了r的私密性。但是,这也是在证明者和验证者在私有安全通道中执行的。这是由于此协议存在交互过程,此方案只对参与交互的验证者有效,其他不参与交互的验证者无法判断整个过程是否存在串通的舞弊行为,因为一旦两个验证者相互串通,交换自己得到的值,便可以推出私钥。因此,是无法公开验证的。

不妨来个数学理论推导:在公开验证的条件下,两个验证者分别提供两个不同的随机值c1和c2,并要求证明者计算z1 = r + c1sk,z2 = r + c2sk,即可计算出sk =(z1-z2)/(c1-c2)。因此,这个过程便无法公开验证。

进一步分析,为什么需要验证者回复一个随机标量c呢?防止Alice造假!

如果Bob不回复一个c,就变成如下一次性交互。由于椭圆曲线上的离散对数问题,知道PK和G的情况下通过PK = a * G接触a是不可能的,所以保证了a的私密性。但是这种方案是存在问题的,a和r都是Alice自己生成的,她知道Bob会用PK和R相加然后再与z * G进行比较。所以她完全可以在不知道a的情况下构造:R = r * G - PK 和 z = r。这样Bob的验证过程就变成:z * G ?== PK + R > r * G ? PK + r * G - PK。这是永远成立的,所以这种方案并不正确。
在这里插入图片描述

4.非交互式Schnorr

上述SchnorrScheme中存在的私钥泄露问题使得算法无法在公开的环境下使用。通过将原始的交互式协议转变为非交互式协议可以解决这个问题。
在这里插入图片描述

4.1非交互式Schnorr协议流程

  • Alice:均匀随机选择r,并依次计算

R=rG
c=Hash(R,PK)
z=r+c
sk
Alice:生成证明(R,z)

  • Bob(或者任意一个验证者):计算e=Hash(PK,R)
    Bob(或者任意一个验证者):验证zG?==R+cPK

4.2安全性分析与非交互式

为了不让Alice进行造假,需要Bob发送一个c值,并将c值构造进公式中。所以,如果Alice选择一个无法造假并且大家公认的c值并将其构造进公式中,问题就解决了。生成这个公认无法造假的c的方法是使用哈希函数。

看一下交互式Schnorr协议的第二步,Bob需要给出一个随机的挑战数c,这里我们可以让Alice用c=Hash(PK,R)这个式子来计算这个挑战数,从而达到去除协议第二步的目的。

此外,利用Hash算法计c的式子,这里还达到了两个目的:
第一个目的:Alice在产生承诺R之前,没有办法预测c,即使c最终变相是Alice挑选的。
第二个目的:c通过Hash函数计算,会均匀分布在一个整数域内,而且可以作为一个随机数。

请注意:Alice绝不能在产生R之前预测到c,不然,Alice就等于变相具有了「时间倒流」的超能力,从而能任意愚弄Bob。而一个密码学安全Hash函数是「单向」的,比如SHA256等。这样一来,虽然c是Alice计算的,但是Alice并没有能力实现通过挑选c来作弊。因为只要Alice一产生R,c就相当于固定下来了。我们假设Alice这个凡人在「现实世界」中是没有反向计算Hash的能力的。

这样,就把三步Schnorr协议合并为一步。Alice可直接发送(R,z),因为Bob拥有Alice的公钥PK,于是Bob可自行计算出c。然后验证zG?=cPK+R。

4.3零知识解释

整个过程中Alice并未暴露自己的私钥,且Bob无法通过正常手段或作弊手段获取Alice的私钥,因此也是零知识的。

5.Schnorr用于数字签名

提出数字签名的出发点有二:
一是,当消息基于网络传输时,接收方希望证实消息在传递过程中没有被篡改;
二是,希望确认发送者的身份,可以理解为发送者有一个私钥,且私钥和这条消息进行关联计算。

首先要证明我的身份,那么这个简单,这正是Schnorr协议的功能,能够向对方证明「我拥有私钥」这个陈述。并且这个证明过程是零知识的:不泄露关于「私钥」的任何知识。

那么如何和这句唐诗关联呢?我们修改下计算c的过程:

m=“白日依山尽,黄河入海流”
c=Hash(m,R)

这里为了保证攻击者不能随意伪造签名,正是利用了离散对数难题(DLP)与Hash函数满足抗第二原象(Secondary Preimage Resistance)这个假设。

注:这里严格点讲,为了保证数字签名的不可伪造性,需要证明Schnorr协议满足「Simulation Soundness」这个更强的性质,这点请参考文献[5]。
在这里插入图片描述
上图就是Schnorr签名方案[6]。在这里还有一个优化,Alice发给Bob的内容不是(R,z)而是(c,z),这是因为R可以通过c,z计算出来。
注:为什么说这是一个「优化」呢?目前针对椭圆曲线的攻击方法有Shanks算法、Lambda算法还有Pollard’s rho算法,请大家记住他们的算法复杂度大约都是3,n是有限域大小的位数。假设我们采用了非常接近$2^256$的有限域,也就是说z是256bit,那么椭圆曲线群的大小也差不多要接近256bit,这样一来,把2256开平方根后就是2128,所以说256bit椭圆曲线群的安全性只有128bit。那么,挑战数c也只需要128bit就足够了。这样Alice发送c要比发送R要更节省空间,而后者至少需要256bit。c和z两个数值加起来总共384bit。相比现在流行的ECDSA签名方案来说,可以节省1/4的宝贵空间。现在比特币开发团队已经准备将ECDSA签名方案改为一种类Schnorr协议的签名方案——muSig[7],可以实现更灵活地支持多签和聚合。

6.菲亚特-沙米尔(Fiat-Shamir)变换

采用Hash函数的方法来把一个交互式的证明系统变成非交互式的方法被称为Fiat-Shamir变换[8],它由密码学老前辈Amos Fiat和Adi Shamir两人在1986年提出。

Fiat-Shamir变换,又叫Fiat-Shamir Heurisitc(启发式),或者Fiat-Shamir Paradigm(范式)。是Fiat和Shamir在1986年提出的一个变换,其特点是可以将交互式零知识证明转换为非交互式零知识证明。这样就通过减少通信步骤而提高了通信的效率!
菲亚特-沙米尔(Fiat-Shamir)启发式算法允许将交互步骤3替换为非交互随机数预言机(Random oracle)。随机数预言机,即随机数函数,是一种针对任意输入得到的输出之间是项目独立切均匀分布的函数。理想的随机数预言机并不存在,在实现中,经常采用密码学哈希函数作为随机数预言机。

下面是一个示例图,大家可以迅速理解这个Fiat-Shamir变换的做法。
在这里插入图片描述

7.声明

以上内容均来自于网络博客内容总结而得,主要用于个人对Schnorr协议的理解,其中主要观点和内容大部分参考自:「安比实验室SECBIT」https://blog.csdn.net/Secbit/article/details/102857503

[1]https://blog.csdn.net/mutourend/article/details/100708354
[2]https://www.cs.au.dk/~ivan/Sigma.pdf
[3]https://www.jianshu.com/p/0c0889d2a63a
[4]https://github.com/sec-bit/learning-zkp/blob/master/zkp-intro/4/zkp-rom.md
[5]Paillier, Pascal, and Damien Vergnaud.“Discrete-log-based signatures may not be equivalent to discrete log.” International Conference on the Theory and Application of Cryptology and Information Security. Springer, Berlin, Heidelberg, 2005.
[6]Schnorr, Claus-Peter.“Efficient signature generation by smart cards.” Journal of cryptology 4.3 (1991):161-174.
[7]Maxwell, Gregory, Andrew Poelstra, Yannick Seurin, and Pieter Wuille. “Simple schnorr multi-signatures with applications to bitcoin.” Designs, Codes and Cryptography 87, no. 9 (2019): 2139-2164.
[8]Fiat, Amos, and Adi Shamir. “How to prove yourself: Practical solutions to identification and signature problems.” Conference on the Theory and Application of Cryptographic Techniques. Springer, Berlin, Heidelberg, 1986.

发布了106 篇原创文章 · 获赞 253 · 访问量 38万+

猜你喜欢

转载自blog.csdn.net/jingzi123456789/article/details/104852469