零知识证明 - 区块链应用中的风险

最近翻到一篇19年底360安全发布的一篇有关零知识证明安全的文章。这篇文章是Zhiniang Peng在PacSec2019大会发言的总结。文章框架性地介绍零知识证明zk-SNARK的知识，并给出了一些安全提示和思考。

原文链接如下：

http://blogs.360.cn/post/Security-Risks-in-Zero-Knowledge-Proof-Cryptocurrencies.html

对整个PPT的内容感兴趣的小伙伴，可以直接查看原文链接。我摘录一些比较精彩的点，分享一下。

01

zk-SNARK总体流程

文章开头讲了讲 NIZK/zk-SNARK的基本概念，给出了zk-SNARK的工作流程图：

在这个流程图上，清晰的给出了“电路”，“R1CS”以及“QAP”的关系。一个NP问题，先拍平（Flatten）构成电路（若干个乘法门/加法门构成）。在电路的基础上，构造约束，也就是R1CS。有了一个个的约束，就可以把NP问题，抽象成QAP问题。有了QAP问题的描述，Groth16的算法就可以初始化，生成以及验证证明了。

整个流程从工程的角度，又可以“切分”成几个大块：

1. 设计阶段(Design) - NP问题，也就是业务的设计。

2. 翻译QAP(Translation) - 抽象并转化成QAP问题。

3. 初始参数生成（Setup) - 生成可信参数，也就是传说中的CRS(Common Reference String)。

4. 构造证明 - 提供私有/公开信息，生成证明。

5. 验证 - 采用公开信息，验证证明。

02

zk-SNARK的工具链

文章中也比较细心地给出了目前zk-SNARK开发的各种高级语言以及相互的依赖关系。

大家可以看出，目前，R1CS->QAP的这条链上，相对其他来说是最健壮的。如果开始入门的小伙伴，可以从Zokrates/libsnark/Bellman入手：

零知识证明 - libsnark源代码分析

零知识证明 - bellman源码分析

零知识证明 - 深入理解ZoKrates

03

应用风险总结

开发实现的风险

零知识证明的开发（所有的软件开发）常见的安全风险：内存污染，逻辑上的漏洞。加密的东西，没有时间的挑战都感觉有隐患。新的加密的实现存在新的风险。

文章举例，Zcash中的Faerie Gold攻击。在Zcash生成commitment的时候，发送方有意采用同样的随机数(rho)发送多笔交易。接受者只能消费其中的一笔交易。

去年7月份，暴露出来另外一个双花的Bug：

零知识证明 - zkSNARK应用的Nullifier Hash攻击

初始设置的风险

zk-SNARK一直被诟病，就是因为需要Trusted Setup。这个初始设置涉及到人为因素，虽然可以采用MPC多方计算加强安全性，但是始终不是绝对安全。

信息泄露

虽然ZCash提供了隐私交易，但事实上截止2019年9月份，整个Zcash的交易中只有5%的交易是隐私交易：

并且，从进行隐私交易的交易地址，金额，交易时间以及用户习惯，也可以推断出一些有用信息。

密码学本身安全问题

Groth16发表在2016年，2017年就大规模应用。没有得到充分的时间验证。Zcash之前有些零知识证明相关的漏洞，都是很晚才公布。文章列举了一些之前公布的漏洞，感兴趣的小伙伴可以看看。

其他问题

文章给出了自己的一些安全思考，并列举了一些其他问题。

文章最后给出了如何使用ZKP构造协议来进行数据的交易。对这部分感兴趣的小伙伴，可以自己查看原文。

感谢360安全的Zhiniang Peng，分享零知识证明和相关安全问题。大会发言用的完整版PPT，也分享给我了。需要原始完整PPT的小伙伴，可以留言。