阅读各种论文，看来EC-Schnorr并没有像ECDSA一样标准化。
例如，我在两个主要参与者的规范中发现了两个主要区别（在其他论文中也发现了其他较小的变体）；
根据BSI Schnorr签名的计算方式为：
$ k $随机
$ Q $ = $ kG $，
$ r = Q_x $
$ h = H（M \ mathbin \ Vert Q_x）$
$ s = k − h \ times d \ mod n $
输出$（h，s）$
并根据libsecp256k1 ：
$ k $随机
$ Q = kG $，
$ r = Q_x $
$ h = H（r \ mathbin \ Vert m）= H（Q_x \ mathbin \ Vert M）$
$ s = k-h \ times d \ mod n $
输出$（r，s） $。
差异位于：
步骤3：数据的哈希顺序
步骤5：值返回
当然，签名验证算法会因此而有所不同。
所以，我想知道：
规范比另一种更规范吗？
如果有几种标准，如何选择一个？
互操作性又如何？
安全性如何（例如：$ H（Q_x \ mathbin \ Vert M） $比我认为$ H（M \ mathbin \ Vert Q_x）$好）？
#1 楼
除了其他答案外，我注意到这两种方案都与ISO / IEC 14888-3：2016（非功能性预览版）中标准化的方案有关（但有明显不同）： BSI的EC-Schnorr原始规范类似于ISO / IEC 14888-3的EC-SDSA-opt，代表椭圆曲线Schnorr数字签名算法优化版本，但EC-Schnorr输出$ H（M \ mathbin \ | Q_x）$，但EC-SDSA-opt输出$ H（Q_x \ mathbin \ | M）$。ISO / IEC 14888-3还定义了EC-SDSA，其输出$ H（Q_x \ mathbin \ | Q_y \ mathbin \ | M） $。
BSI的当前规范现在与ISO / IEC 14888-3中的EC-SDSA定义相匹配。
问题的libsecp256k1（可能与此来源相匹配）与ISO / IEC 14888-3的EC-类似FSDSA（其中F代表完整），但libsecp256k1输出（和以后的哈希）$ Q_x $，其中EC-FSDSA使用$ Q_x \ mathbin \ | Q_y $。因此，EC-FSDSA的签名比libsecp256k1的签名大得多（对于$ b $位的安全性，它是$ 6b $位，而不是$ 4b $位）。
还有更多与libsecp256k1相关的变体。注释链接到BIP-Schnorr。
所讨论方案的摘要：
$$
\ begin {array} {l | rllr}
\ text {scheme}＆\ text {public}＆\，\，\，\ text {第一}＆\，\，\ text {第二}＆\ text {符号。 } \，\\
＆\ text {key} \，\，＆\ text {component}＆\ text {component}＆\ text {size} \，\，\，\\
\ hline
\ text {[Sc91]}＆-d \，G＆H（Q，M）＆k + d \; h＆b + 2b \\
\ text {EC-SDSA}＆-d \，G＆H （Q_x \ mathbin \ | Q_y \ mathbin \ | M）＆k + d \; h＆2b + 2b \\
\ text {EC-SDSA-opt}＆-d \，G＆H（Q_x \ mathbin \ | M） ＆k + d \; h＆2b + 2b \\
\ text {EC-FSDSA}＆-d \，G＆Q_x \ mathbin \ | Q_y＆k + d \; H（Q_x \ mathbin \ | Q_y \ mathbin \ | M） ＆4b + 2b \\
\ text {EC-Schnorr old}＆d \，G＆H（M \ mathbin \ | Q_x）＆k-d \; h＆2b + 2b \\
\ text {libsecp256k1}＆d \ ，G＆Q_x＆k-d \; H（Q_x \ mathbin \ | M）＆2b + 2b \\
\ text {BIP-Schnorr}＆d \，G＆Q_x＆k + d \; H（Q_x \ mathbin \ | \ text {Pub} \ mathbin \ | M）＆2b + 2b \\
\ end {array}
$$
$ M $是要签名的消息。
$ G $是组生成器。
$ k $是签名者在每个签名处（随机或伪随机）绘制的秘密。
$ Q = k \，G = \ underbrace {G + \ ldots + G} _ {k \ text {terms}} $。
$ Q_x $（分别为$ Q_y $）是$ Q $的$ x $（分别为$ y $）组成的字节串。
$ b $是预期的安全位；组大小$ n $，$ Q_x $和$ Q_y $约为$ 2b $位。
$ H $是哈希函数，而$ h $是哈希的结果，通常也是签名的第一个组成部分。对于$ \ text {[Sc91]} $，$ h $是$ b $位宽，$ H $的输入将$ Q $的未指定部分与$ M $相结合。在其他方案中，$ h $是$ 2b $位宽。
$ \ text {Pub} $是公钥。将其包含在散列数据中可以简化（也许加强）多用户配置中的安全性。
签名的第二个组件省略了隐式$ \ bmod n $。
省略了整数和双字符串之间的转换。 （尽管对于互操作性至关重要）。
$ \ text {[Sc91]} $是Claus-Peter Schnorr，《智能卡的有效签名生成》，1991年在《密码学杂志》上；
在$ \ text {EC-Schnorr} $中，签名的第一个组成部分是ASN.1整数，而不是字节串。
/> $ \ text {EC-Schnorr} $（分别为$ \ text {EC-SDSA} $，$ \ text {EC-SDSA-opt} $，$ \ text {EC-FSDSA} $）已注册对象标识符0.4.0.127.0.7.1.1.4.3（分别为1.0.14888.3.0.11、1.0.14888.3.0.13、1.0.14888.3.0.12）。
这7个方案不兼容；安德鲁·S·塔南鲍姆（Andrew S. Tanenbaum）的“关于标准的妙处是，您可以选择的东西太多了”，这是一种轻描淡写的说法。 TS 119312 V1.2.1（2017-05）加密套件指出：
由于互操作性的原因，本文档仅选择了ISO / IEC 14888-3中定义的EC-XDSA Schnorr变体的一个版本（EC-SDSA-opt）。优化版本的EC-SDSA具有智能卡最小数据传输的小优势。
，但据我所知，该原理仅适用于EC-FSDSA 。如果智能卡本身按应计算或验证签名，则所传递的是签名，即EC-SDSA-opt和EC-SDSA中的$ 4b $位。
散列$ M $首先是EC-Schnorr的特异性；我的猜测是，它是为诸如智能卡之类的受限环境而设计的，它允许在外部卸载$ M $的大部分散列（同样在多核CPU上，允许在单独的线程中对$ M $进行散列）。只要哈希是安全的，它就不会对安全产生任何影响。
评论
$ \ begingroup $
对于libsecp256k1来说，签名似乎是：$（Q_x，k + dH（Q_x || dG || M））$：github.com/sipa/bips/blob/bip-schnorr/…也在此处记录：github.com/sipa/bips/blob/bip-schnorr/…
$ \ endgroup $
–oleiba
19年6月3日在9:09
#2 楼
理论上，$（r，s）$版本比$（h，s）$更安全。 Bellare，Namprempre，2004年11月的论文“ IBI和签名方案的安全证明”显示，以（$，r）$形式的Schnorr签名（它们称为BNN签名）可以实现半强不可伪性（ss-euf） ;而$（h，s）$形式的签名只能实现正常的不可伪造性。可以找到ss-euf的安全性证明与Okamoto-IBI和BNN- IBI在本文中。将标准标识方案转换为IBI的转换框架未捕获这2个IBI方案。因此，他们需要通过考虑来自基础标准签名方案（即BNN签名）的额外安全性来提供直接证明。为了确保2 IBI的安全，底层签名必须至少是半强安全的，这就是为什么作者对签名显示半强安全性的原因。
回到Schnorr签名，在非EC版本中，$（r，s）$是$（Q，s）$，其大小明显大于$（h，s）的大小。 $，并且在实践中不建议使用。在EC版本中，两者的长度相同，但是我猜$（r，s）$在验证过程中会变慢。如果验证方面没有限制，由于安全性更强，我宁愿使用$（r，s）$。
评论
$ \ begingroup $
我看到了您所指的论文，确切地作者指出$（h，s）$比$（r，s）$更安全？
$ \ endgroup $
– 111
17 Mar 10 '17 at 12:07
$ \ begingroup $
在6.1节，第pg中。 39.可以证明BNN签名在ss-euf-cma中是安全的，因为伪造者仍然不知道消息的哈希值$ h $，即使伪造者知道了消息的签名$（r，s）$ 。如果签名是$（h，s）$，则不能使用相同的技巧。
$ \ endgroup $
–谭
17 Mar 11 '17 at 14:20
$ \ begingroup $
这是论文：iacr.org/archive/eurocrypt2004/30270269/bnn.pdf第39页上也没有6.1节。您能提供您正在讨论的论文的链接吗？
$ \ endgroup $
– 111
17年3月11日在22:04
$ \ begingroup $
完整版本在这里：eprint.iacr.org/2004/252.ps
$ \ endgroup $
–谭
17年3月13日在6:56
$ \ begingroup $
@Tan，回答以上评论：是的，$ 4 \ log_2（q）$位是使用两个坐标计算的，因为这是标准化EC-FSDSA的工作（请参见我的回答）。我同意$ r $可以仅使用x坐标加1位表示。而且似乎省略这1位（在问题的libsecp256k1描述中执行）似乎并没有增加很多安全性。
$ \ endgroup $
–fgrieu♦
17年7月17日在22:56
#3 楼
如今，在椭圆曲线组上部署最广泛的Schnorr型签名方案可能是EdDSA，其实例化是使用SHA-512在Curve25519上的Ed25519。公用密钥是椭圆形曲线$ E / \ mathbb F_q $的$ \ mathbb F_q $理性点中的点$ A $的编码，对于较大质数$ \ ell $而言，订单价为$ h \ ell $奇次幂$ q $的有限域；消息$ m \ in \ {0,1 \} ^ * $上的签名是点$ R \ in E（\ mathbb F_q）$和标量$ s \ in对的$（R，s）$对\ mathbb Z / \ ell \ mathbb Z $满足$$ [h \ cdot s] B = [h] R + [h \ cdot H（\下划线R \ mathbin \ Vert \下划线A \ mathbin \ Vert m）] A $$其中$ B \ in E（\ mathbb F_q）$是订单的标准基点$ \ ell $和$ H \冒号\ {0,1 \} ^ * \ to \ mathbb Z / \ ell \ mathbb Z $是统一的随机函数。签名者知道\ mathbb Z / \ ell \ mathbb Z $中的秘密标量$ a \ a，使得$ A = [a] B $;选择$ r = H（k \ mathbin \ Vert m）$和$ R = [r] B $，其中$ k $是一个长期秘密，签名者然后可以计算$$ s \ equiv r + H（\下划线R \ mathbin \ Vert \下划线A \ mathbin \ Vert m）\ cdot a，$$可以直接满足验证方程。 >$ k $是通过长期秘密从$ m $中伪随机选择的
$ Q = [k] G $
$ h = H（\下划线Q \ mathbin \ Vert \ underline {[d] G} \ mathbin \ Vert m）$
$ s \ equiv k + h \ times d \ mod n $
输出$（\ underline Q，s）$
在长期秘密下选择$ k $作为消息的伪随机函数可以消除在签名时对熵源的需求。将公钥$ [d] G $散列到$ h $中会限制公钥的可延展性，并为系统的多用户安全性提供信心。使用$ Q $而不是$ h $进行编码可以实现快速批处理验证，尽管我不确定我是否听说过有人在实践中关心此问题。由于$ H $不必具有抗冲突性，因此您可以遵循Schnorr最初的建议，使用较小的（例如128位）哈希值并传输$（h，s）$而不是$（\下划线Q，以节省签名中的空间，s）$，但是椭圆曲线设置的尺寸优势是适度的，并且多用户安全性的故事还不太清楚。
有关设计空间的更多讨论。
#4 楼
最初的Schnorr签名是使用Fiat-Shamir技巧的Schnorr id签名方案的副产品。该构造在CPSchnorr的论文中给出。在签名Scheme中，输出为$（h，s）$而不是$（r，s）$。
所以我希望第一个实现。
评论
“关于标准的好处是您有太多选择。” （安迪·塔南鲍姆）。只要在$ Qx $和$ M $之间的边界定义明确，我就看不到哈希顺序在安全性上有任何区别。看一下返回值的差异会更有趣。您忘记了另外两个变体。一些标准计算s = k + h d。某些标准要求将整个点Q放入哈希中，而不是仅将x坐标放入。