The Dark Side of Zero Knowledge: Masking the initial setup in Zk-SNARK(blog.smartdec.net)
blog.smartdec.net
The Dark Side of Zero Knowledge: Masking the initial setup in Zk-SNARK
https://blog.smartdec.net/the-dark-side-of-zero-knowledge-undetectable-backdoor-in-zk-snark-a9093ffe49bf
29 comments
> Zcash used a multiparty setup of 6 people
That's true of the original (Sprout) SNARK, but the newer (Sapling) SNARK used a much more scalable MPC ceremony, which they called Powers of Tau: https://z.cash.foundation/blog/powers-of-tau/
There was a public call for participation at the time, so if you wanted to be sure that the ceremony was not corrupted, you could just participate yourself.
For backwards compatibility, the Sprout SNARK can still be used, so if the original ceremony was compromised, an attacker could still create coins "out of thin air". But converting a Sprout account to a Sapling account requires making the amount public, so if the number of coins converted exceeded the intended currency supply, that would be detected. Worst case scenario, a hard fork could be arranged to disable the Sprout SNARK.
That's true of the original (Sprout) SNARK, but the newer (Sapling) SNARK used a much more scalable MPC ceremony, which they called Powers of Tau: https://z.cash.foundation/blog/powers-of-tau/
There was a public call for participation at the time, so if you wanted to be sure that the ceremony was not corrupted, you could just participate yourself.
For backwards compatibility, the Sprout SNARK can still be used, so if the original ceremony was compromised, an attacker could still create coins "out of thin air". But converting a Sprout account to a Sapling account requires making the amount public, so if the number of coins converted exceeded the intended currency supply, that would be detected. Worst case scenario, a hard fork could be arranged to disable the Sprout SNARK.
The original Sprout SNARK has been disabled and replaced with a new implementation based on the powers of tao ceremony. You can still spend Sprout coins, but not with the old parameters.
Note that the technical problems made it more complicated and messy to reproduce the build, but didn't outright prevent it. Mainly the executable binaries were reproducible, but other metadata in the disk image changed each time. https://github.com/zcash/mpc/issues/2
As you know, my complaints with regard to the reproducible build were not that the scripts themselves didn't work - indeed I fixed an issue related to that - but that the direct dependencies of the build were both high entropy (e.g. very specific nightly builds of a niche Linux distribution) and themselves not at all reproducible.
Your reply here is highly misleading, even lying by omission.
Your reply here is highly misleading, even lying by omission.
Check out this podcast about the Zcash ceremony: https://www.wnycstudios.org/story/ceremony
[deleted]
This discusses a weakness with all zero knowledge proofs which require a trusted setup.
Zero knowledge proofs which don’t require a trusted setup include BCCCGP[1], Bullet Proofs[2], ZKBOO++[3], Ligero[4], Hyrax[5], ZK-STARKs[6], and Aurora[7].
[1]https://eprint.iacr.org/2016/263.pdf
[2]https://eprint.iacr.org/2017/1066.pdf
[3] https://eprint.iacr.org/2017/279.pdf
[4] https://acmccs.github.io/papers/p2087-amesA.pdf
[5] https://eprint.iacr.org/2017/1132.pdf
[6] https://eprint.iacr.org/2018/046.pdf
[7] https://eprint.iacr.org/2018/828.pdf
To clear up confusion in the comments, the new ZCash release, sappling, used a trusted setup with 87 people up from the original six[8].
[8] https://z.cash/blog/completion-of-the-sapling-mpc/
Zero knowledge proofs which don’t require a trusted setup include BCCCGP[1], Bullet Proofs[2], ZKBOO++[3], Ligero[4], Hyrax[5], ZK-STARKs[6], and Aurora[7].
[1]https://eprint.iacr.org/2016/263.pdf
[2]https://eprint.iacr.org/2017/1066.pdf
[3] https://eprint.iacr.org/2017/279.pdf
[4] https://acmccs.github.io/papers/p2087-amesA.pdf
[5] https://eprint.iacr.org/2017/1132.pdf
[6] https://eprint.iacr.org/2018/046.pdf
[7] https://eprint.iacr.org/2018/828.pdf
To clear up confusion in the comments, the new ZCash release, sappling, used a trusted setup with 87 people up from the original six[8].
[8] https://z.cash/blog/completion-of-the-sapling-mpc/
As the article states, but is a confusing in the title, this isn't a problem with all Zero Knowledge Protocols (ZKP) but is a problem with a specific ZKP, namely zk-Snarks.
You can do ZKPs without a trusted setup, they are less performant than zk-Snarks. It seems likely that in the next few years these performance problems will be overcome. Most people I've talked to in the field are very confident that protocols like zk-snarks can be done without trusted setup.
You can do ZKPs without a trusted setup, they are less performant than zk-Snarks. It seems likely that in the next few years these performance problems will be overcome. Most people I've talked to in the field are very confident that protocols like zk-snarks can be done without trusted setup.
ZK-Starks already do this.
https://medium.com/coinmonks/zk-starks-create-verifiable-tru...
https://medium.com/coinmonks/zk-starks-create-verifiable-tru...
It looks like there's nothing new here, making the title clickbait-y. One of the first things anyone learns about Zcash is that there was a trusted ceremony.
Wrong.
"One of the first things anyone learns about Zcash" is that at least one of the ceremony's participants must be trusted to have securely destroyed his toxic waste.
This article is about the fact that there could be a backdoor, whose absence can only be proven by revealing all participants' toxic waste.
You'll note that these two things are at odds with each other.
"One of the first things anyone learns about Zcash" is that at least one of the ceremony's participants must be trusted to have securely destroyed his toxic waste.
This article is about the fact that there could be a backdoor, whose absence can only be proven by revealing all participants' toxic waste.
You'll note that these two things are at odds with each other.
There is nothing new about this article. The article is pointing out that in addition to the trapdoors of the proving system, it's possible to subvert the arithmetic circuit used as well. The ceremonies used by Zcash have the property that the parameters are perfectly bound to the circuit.
Not sure why this isn't mentioned in the article.
> This article is about the fact that there could be a backdoor, whose absence can only be proven by revealing all participants' toxic waste.
This is incorrect, as stated above. Instead of revealing their toxic waste, we reveal proofs-of-knowledge so we can use pairings to ensure the parameters encode the circuit correctly.
Not sure why this isn't mentioned in the article.
> This article is about the fact that there could be a backdoor, whose absence can only be proven by revealing all participants' toxic waste.
This is incorrect, as stated above. Instead of revealing their toxic waste, we reveal proofs-of-knowledge so we can use pairings to ensure the parameters encode the circuit correctly.
I stand corrected. Thank you for the clarification!
I still learned something "new" from the article, I was only aware of the ceremony issue that "everbody knows" of.
I still learned something "new" from the article, I was only aware of the ceremony issue that "everbody knows" of.
That's great! There are many issues with trusted setups that people aren't paying enough attention to.
You're right, I removed misleading information from the article. Thank you for your comment.
I don’t think that’s true. The article seems to be saying that you can sneak a backdoor into the circuit. You can also verify that the parameters implement the circuit, and you don’t need the toxic waste to do that.
Thank you for your comment. Unfortunately I made a mistake. I have removed misleading information from the article.
This is an attempt to explain the details of the trusted ceremony, why it was needed, and what is being trusted.
I like that it describes two different levels of trust required — trust in both the destruction of the initial secrets and in the original formulation of the problem. Were both levels of trust established, in the case of ZCash?
I like that it describes two different levels of trust required — trust in both the destruction of the initial secrets and in the original formulation of the problem. Were both levels of trust established, in the case of ZCash?
Does this apply to monero as well?
No. Monero uses RingCT for transaction privacy. RingCT employs Borromean ring signatures, Pedersen Commitments and Bulletproofs (for range proofs). It does not use the zkSNARK construction. The Bulletproof (and the Pedersen Commitments) can be seen as another zero knowledge proof system.
Monero's backdoor was the development team releasing a severely weakened version of the mining app during the phase where 25% of the supply was minted, along with a production curve that released 80% of the supply in less than half the time of Bitcoins minting production time.
https://old.reddit.com/r/MoneroMining/comments/6fixnr/monero...
https://old.reddit.com/r/MoneroMining/comments/6fixnr/monero...
That was bytecoin, not Monero. Monero is a code fork of Bytecoin. Bytecoin is considered a scam. Monero was a fair launch with no backdoors.
> I woke up on May 28th, 2014 [one month after Monero launched], on vacation with my family in the middle of the desert, to find a copy of my private source code plastered across the bitcointalk message board. Announced as a "new optimized version" of the Monero currency miner, it was enthusiastically adopted by cryptocurrency miners across the world. And in the process of doing so, my daily profit from the Monero Mining Project dropped by over five thousand dollars per day.
...
> [Monero] was a fork of Bytecoin designed to not have the 80% premine. But its initial developer either didn't know, didn't care, or wanted to profit from the de-optimized hashing. That initial developer was pretty quickly given the boot by the community, and in came an unrelated group of developers who took it over---who were, as far as I can tell, completely unaware of the deoptimization. So things sat there for a few weeks in the same state as Bytecoin.
...
> This was a brilliantly designed proof-of-work function targeting the strengths of modern CPUs -- native AES encryption and fast 64 bit multipliers -- tuned to use a scratchpad exactly the size of the per-core L3 cache on Intel CPUs (about 2MB) that someone then wrapped in such a thick blanket of crap it was nearly unrecognizable until you started jumping in, tearing it apart, and putting it back together again.
https://da-data.blogspot.com/2014/08/minting-money-with-mone...
...
> [Monero] was a fork of Bytecoin designed to not have the 80% premine. But its initial developer either didn't know, didn't care, or wanted to profit from the de-optimized hashing. That initial developer was pretty quickly given the boot by the community, and in came an unrelated group of developers who took it over---who were, as far as I can tell, completely unaware of the deoptimization. So things sat there for a few weeks in the same state as Bytecoin.
...
> This was a brilliantly designed proof-of-work function targeting the strengths of modern CPUs -- native AES encryption and fast 64 bit multipliers -- tuned to use a scratchpad exactly the size of the per-core L3 cache on Intel CPUs (about 2MB) that someone then wrapped in such a thick blanket of crap it was nearly unrecognizable until you started jumping in, tearing it apart, and putting it back together again.
https://da-data.blogspot.com/2014/08/minting-money-with-mone...
This is false.
I don't know that Monero uses ZK-SNARKS for anything, do they? Don't they solve their similar problem with ring signatures?
Isn't zero knowledge crypto relatively new? Seems like we're going through the normal decades long growing pains of any new type of crypto.
If so, how did other types of crypto in the early adoption years deal with these types of issues?
If so, how did other types of crypto in the early adoption years deal with these types of issues?
The prominent Bitcoin developer, Peter Todd was invited to participate, too. You can read his entertaining blogpost about the setup procedure at here.
https://web.archive.org/web/20161114214233/https://petertodd...
The funny and alarming story is, after he finished the setup, he became increasingly suspicious about the security of the procedures, especially casted doubts on some technical problems that prevented reproducible build (!!!) of the setup programs. And he later had withdrawn his blogpost and all the claims of security altogether. To me, it's alarming, in the end, we'll never get solid security guarantees.