|
最近翻到一篇 19 年底 360 安全发布的一篇有关零知识证明安全的文章。这篇文章是 Zhiniang Peng 在 PacSec2019 大会发言的总结。文章框架性地介绍零知识证明 zk-SNARK 的知识，并给出了一些安全提示和思考。 原文链接如下： http://blogs.360.cn/post/Security-Risks-in-Zero-Knowledge-Proof-Cryptocurrencies.html 对整个PPT的内容感兴趣的小伙伴，可以直接查看原文链接。我摘录一些比较精彩的点，分享一下。 01zk-SNARK 总体流程 文章开头讲了讲 NIZK/zk-SNARK 的基本概念，给出了 zk-SNARK 的工作流程图： 
在这个流程图上，清晰的给出了“电路”，“R1CS”以及“QAP”的关系。一个 NP 问题，先拍平（Flatten）构成电路（若干个乘法门 / 加法门构成）。在电路的基础上，构造约束，也就是 R1CS。有了一个个的约束，就可以把 NP 问题，抽象成 QAP 问题。有了 QAP 问题的描述，Groth16 的算法就可以初始化，生成以及验证证明了。 整个流程从工程的角度，又可以“切分”成几个大块： 
设计阶段 (Design) - NP 问题，也就是业务的设计。 翻译 QAP(Translation) - 抽象并转化成 QAP 问题。 初始参数生成（Setup) - 生成可信参数，也就是传说中的 CRS(Common Reference String)。 构造证明 - 提供私有 / 公开信息，生成证明。 验证 - 采用公开信息，验证证明。
02zk-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 的小伙伴，可以留言。
 | 
立即注册
登录
