1. 程式人生 > 實用技巧 >零知識證明libSnark中Groth16演算法的優劣——可加工性攻擊問題

零知識證明libSnark中Groth16演算法的優劣——可加工性攻擊問題

Groth16相比於PGHR13和GM17實現,具有一定的時間和空間優勢,具體可參考:
libsnark中有對snark的不同實現方法做了效能對比:
在這裡插入圖片描述

ZoKrates中採用的是Ethereum支援的ALT_BN128曲線,同時也對這三種方法做了實現,預設採用的是Groth16(已用Rust語言重寫,若需使用--proving-scheme pghr13--proving-scheme gm17,則需使用C++語言 的libsnark庫,編譯時需指定相應的features cargo -Z package-features build --release --package zokrates_cli --features="libsnark"

)。同時,在其指導網頁中也指出,Groth16演算法存在可加工性攻擊問題——即攻擊者可利用已知的valid proof再加工出不同的valid proof,詳細描述如下:

G16 malleability
When using G16, developers should pay attention to the fact that an attacker seeing a valid proof can very easily generate a different but still valid proof. Therefore, depending on the use case, making sure on chain that the same proof cannot be submitted twice may not be enough to guarantee that attackers cannot replay proofs. Mechanisms to solve this issue include:

1.signed proofs
2.nullifiers
3.usage of an ethereum address as a public input to the program
4.usage of non-malleable schemes such as GM17

注意:
若使用非預設的g16演算法,則在./zokrates setup --proving-scheme pghr13,./zokrates generate-proof --proving-scheme pghr13./zokrates export-verifier --proving-scheme pghr13

等命令中均需指定相同的演算法,否則會報panic錯誤。

另,也可檢視proof.json檔案驗證,groth16演算法所生成的proof檔案中所含的field elements數量要比pghr13演算法少一半多。

在這裡插入圖片描述

在這裡插入圖片描述