新型零知识证明漏洞剖析:算术运算后缺乏多项式标准化
1. 背景
在代码中,多项式被表示为向量的形式。即,多项式 a0+a1x+...+an-1xn-1+an*xn 被表示为[a0,a1,...,an-1,an]。在 ZK 证明系统中,需要对多项式进行标准化操作,即将多项式的最高次项的系数调整为非零。比如,将[1,2,0]调整为[1,2]才是标准化的多项式表示。
对多项式进行标准化操作是必要的。如果不进行标准化,系统会错误地存储多项式的最高次数,即它会大于其实际的最高次数。比如,对于[1,2,0],如果不进行标准化操作,它的最高次数会被错误地存储为 2,而实际是 1。 基于非标准化的多项式生成证明时,错误的多项式实现将会使得 ZK 证明系统 panic,导致无法生成证明。
2. 案例分析
add() 函数是用来对两个密集多项式(self 和 other)进行加法运算的,加法运算的结果(result)也是一个密集多项式,这需要进行标准化。然而,该函数仅在最后一个分支处对 result 进行了标准化操作(19-21 行)。该函数默认在前三个分支出计算得到的 result 就是标准化的,但这是不合理的。比如,当 self 是[1,2,3],other 是[1,2,-3],此时满足第三个分支(7-12 行),即 self 和 other 这两个多项式最高次数相等,都是 2。而在第三个分支处计算后的 result 是[2,4,0],并未对其进行标准化操作。
而且,在这段代码中,不只是在加法算法后缺乏多项式标准化。在加法运算前,self 和 other 作为 add() 函数的入参,也并没有检查他们是否是标准化的多项式表示。或者说,构造 self 和 other 的函数是否是按照标准化的方法进行构建的,也未可知。degree() 函数用来返回多项式的最高次项的指数。在 add() 函数中,非标准化的 self 和 other 在调用 degree() 函数时会引起 rust panic。
举个例子,self 是非标准化的多项式 1+2x+0x2,即向量[1,2,0],其最高次项的系数为 0。当 other 也不是零多项式时,满足 add() 函数的第三个分支,以 self 来调用 degree() 函数。在 degree() 函数中进入 else 分支。在 else 分支中有一个 assert! 宏,用来确保多项式的最高次数的系数不为 0。如果为 0,self.coeffs.last().map_or(false, |coeff| !coeff.is_zero()) 表达式结果为 false。即 self 向量的最后一个元素,即多项式的最高次项的系数为 0,返回 false。此时,assert! 宏会 panic。
3. 总结
针对此漏洞,Salus 团队提醒 ZK 项目方,在构建多项式时和执行多项式操作之后对其进行标准化,以免破坏 ZK 证明系统的完整性。同时,强烈建议项目方在项目上线之前,寻求专业的安全审计公司进行充分的安全审计,确保项目安全。
参考
https://github.com/0xPARC/zk-bug-tracker/pull/16
https://research.nccgroup.com/wp-content/uploads/2021/11/NCC_Group_ZenBlockchainFoundation_E001741_Report_2021-11-29_v1.2.pdf
https://github.com/HorizenOfficial/ginger-lib/blob/master/algebra/src/fft/polynomial/dense.rs#L151
https://github.com/HorizenOfficial/ginger-lib/blob/master/algebra/src/fft/polynomial/dense.rs#L87