---
# System prepended metadata

title: 零知識schnorr
tags: [blockchain]

---

###### tags: `blockchain`
# 零知識schnorr

https://mirror.xyz/0xaA567552e7FFE0a458C789AeA450eb98078AA3b4/DyNWFA4Z9J1oW_cf1Nm8peOjuLrUnqu4cyhk8MJmBy4


https://blog.csdn.net/jingzi123456789/article/details/104852469

https://github.com/ausaf007/zk-proof-demo/tree/master/src/zkp_demo

https://crypto.stanford.edu/cs355/19sp/lec5.pdf

![](https://i.imgur.com/SggN3bo.png)


https://github.com/adi2011/Schnorr_NIZK-for-discrete-log/blob/main/schnorr-NIZK.js#L2

驗證等式代表

(r+c) * G ?= R + (C * PK)

Alice持有私密資訊 SK = a
公開資訊 PK = a * G

alice 提供隨機數 r
運用r + c * sk = z 提供z
理論上是純數

Bob 提供隨機數 c 
持有 (R、PK、c)
獲得z後 驗證
z * G ?= R + (c * PK)

1）PK = a*G，因橢圓曲線的性質其很難解出a；

2）R = r*G，r隨機生成，和a沒什麼關係，且無法從R反推r的值；

3）c，Bob隨機生成，和a也沒什麼關係；

4）z = r+c*a，由於r不知，故無法從a = （z-r）/c中解出a的值。

![](https://i.imgur.com/xOanIRg.png)

---

NIZK 非交互式
透過將原先的c 改成hash(PK、R)產生 代表方程式強制使用了PK與R
c用到的參數都是公開資訊 任意驗證者都能執行這步驟 並進行認證

並且證明者無法提前預知c(因為hash的原因) 所以無法自行編造出c騙過驗證(例如自行找出PK與R能通過認證 應該是 實際要翻一下文章)


---

## 隨機數r的用途 以及 schnorr協議詳細介紹
https://github.com/sec-bit/learning-zkp/blob/master/zkp-intro/3/zkp-pok.md

這個數字的用途是為了保護密鑰不會被直接抽取
在r不洩漏的狀況 z = r + (c * sk)就是安全的
如果使用了同樣的隨機數r sk就會被人得知
跟z怎麼產生有關

第一步：为了保证零知识，Alice 需要先产生一个随机数，r，这个随机数的用途是用来保护私钥无法被 Bob 抽取出来。这个随机数也需要映射到椭圆曲线群上，rG。

第二步：Bob 要提供一个随机数进行挑战，我们把它称为 c。

第三步：Alice 根据挑战数计算 z = r + a * c，同时把 z发给 Bob，Bob通过下面的式子进行检验：

---

https://aandds.com/blog/schnorr-proof.html#25422915

![](https://i.imgur.com/Uhv70Za.png)

![](https://i.imgur.com/3cb5wOX.png)

---

## 非交互式 schnorr javascript

https://github.com/adi2011/Schnorr_NIZK-for-discrete-log/blob/main/schnorr-NIZK.js

https://github.com/guggero/bip-schnorr

私密訊息透過HASH轉換成私鑰 sk = a
私鑰輸入secp256k1產生公鑰pk = a * g 並儲存於智能合約上 
透過提出"證明" 去運算使用pk的計算式是否會是等式

證明的過程就是確實擁有正確的私鑰(個人訊息)  
能產生出對應到公鑰(答案)的運算
(詳細底下 等式相同 即可驗證Alice確實擁有私鑰sk)

透過 私密訊息 與 隨機數r 產生"證明" 
(隨機數r讓後端產生 因為每次必須是不同的r)

(私密訊息) -> 證明 -> 智能合約驗證 -> 使否與儲存的公鑰相同

證明方
R = r * g
c = keeack256 Hash(PK,R) 
z = r + c * sk
(R,z)

驗證方 智能合約上接收 (R,z)
使用pk、R 
Hash(PK,R) -> c
驗證 z * G ?= R + (c * PK)

因為 z = r + (c * sk) 等式兩邊同時乘相同的橢圓曲線G可得：
z * G = R + (c * PK) 

過程 :
{

z = r + (c * sk) 兩邊都乘G

z * G = (r * G) + (c * sk * G)
(1) r * G -> R 
(2) sk * G -> PK
z * G = R + (c * PK) 

}

等式相同 即可驗證Alice確實擁有私鑰sk
其他人若是持有錯誤的sk 
步驟(2)的sk * G 就不會變成 pk 
產生的z就是錯誤的 兩邊就不會相等

同時驗證的過程中 密鑰sk與r受到橢圓曲線的保護
所以證明過程沒有洩漏資訊
關於r看上方 **隨機數r的用途**

看程式z是怎麼隱藏的 原理上是因為sk與r無人得知

交互式的問題 因為是BOB自己提供c的 該方案便對其餘驗證者沒有效
因為無法辨認是否存在作弊行為
例如兩個不同的驗證者串通 交換自己得到的同一個R值 與不同的c 就能推出答案

在公开验证的条件下，两个验证者分别提供两个不同的随机值c1和c2，并要求证明者计算z1 = r + c1sk，z2 = r + c2sk，即可计算出sk =（z1-z2）/（c1-c2）。因此，这个过程便无法公开验证。

solidity ecc
https://asecuritysite.com/ecc/ethereum16

---

## schnorr 證明是zero-knowledge 引用
 The Schnorr identification protocol has been proven to satisfy the
   following properties, assuming that the verifier is honest and the
   discrete logarithm problem is intractable (see [Stinson06]).

   1.  Completeness -- a prover who knows the discrete logarithm is
       always able to pass the verification challenge.

   2.  Soundness -- an adversary who does not know the discrete
       logarithm has only a negligible probability (i.e., 2^(-t)) to
       pass the verification challenge.

   3.  Honest verifier zero-knowledge -- a prover leaks no more than one
       bit of information to the honest verifier: whether the prover
       knows the discrete logarithm.

https://www.rfc-editor.org/rfc/rfc8235

Fiat-Shamir 非交互式

---

## overflow

case
https://crypto.stackexchange.com/questions/52211/zero-knowledge-proof-of-data-ownership/52219#52219
醫院
https://crypto.stackexchange.com/questions/61624/searching-for-a-zero-knowledge-proofs/64643#64643
停車場 依據設備上的姓名牌照以及一些新的隨機值進行編碼
產生憑證
藉由輸入憑證經過驗證
https://crypto.stackexchange.com/questions/63838/zero-knowledge-proof-in-smart-parking-managment-systems/86574#86574

ZKP EXAMPLE
https://mathoverflow.net/questions/22624/example-of-a-good-zero-knowledge-proof

hide witness
https://crypto.stackexchange.com/questions/70549/schnorr-protocol-is-witness-hiding

schonrr醫療論文
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9252935
https://www.x-mol.com/paper/1330023760184647680/t

