There's no absolute requirement for using Facebook to communicate with others over the Internet, so there's no sensible reason why they (or anyone else) should be compelled to host content they don't like.
Just because certain platforms are popular doesn't really change things from a legal or a moral perspective, and it might be because of their editorial discretion that they are popular in the first place.
These are bad examples in a discussion about speech protections... those businesses are providing services, not just engaging in speech.
Also, those businesses _do_ act to arbitrarily refuse to serve people. My bank sent me a letter last year saying that in ~10 days my account will be closed and they'll send me a check with the account contents. No reason, no appeals.
Only due to ignorance. It is well known that the bases of a Pedersen commitment can and should be sampled randomly; a trusted setup is only subverting the security of the primitive.
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.
The protocol scales linearly with respect to the number of participants, but as you can tell, each participant needs to do a lot of time-consuming computations.
Each participant needs to maintain custody of the hardware during the process of the ceremony, and then destroy the hardware afterward. If it was your turn, you'd do some stuff for an hour, and then it's the next person's turn in a round-robin circle. You had to wait maybe ~8 hours before it was your turn again. The protocol involved three rounds of this.
Nobody can abort (players commit to their moves in advance to defend against adaptive attacks) and so there needs to be a time when all N participants are available for the entire duration of the ceremony. This makes it very sensitive to scheduling problems.
If you want to do your own MPC, you also need to perform very expensive fast-fourier transforms in between round 1 and 2. In our ceremony that required a very beefy 128-core server and it still took over an hour.
I actually just found a log file from the ceremony's coordinator server (not a privileged server, just handles messages and archives them) which shows the timings of everything, which is kind of fun:
> 2^80 is not very weak. That's the level of brute forcing a SHA-1 collision. It's low for a new system, but not very weak.
Note that the 2^80 figure from Peter's blog post is really unsubstantiated. There's another curve in libsnark (which we don't use) that has 80-bits of security. I suspect what happened is whoever Peter was consulting with just repeated this number to him. We've spoken to many cryptographers who are experts on these curves, and none of them think that figure is reasonable. I actually don't believe there are _any_ cryptographers that have publicly made such a claim about the security.
2^96 was the original conservative estimate when the NFS attack was discovered, but subsequent analysis showed concrete security closer to 2^110 (and that's ignoring the unrealistic memory costs of the specific attack.)
> How can they not have the basics of a secure toolchain?!?
We provided participants with a reproducibly built and stripped down version of Alpine Linux, employed grsec, wrote all of our crypto software in pure Rust, etc. All of our software is reproducibly built, hashed and signed. There is nothing (software-wise) that cannot be caught in post-hoc review. All of it is open-source: https://github.com/zcash/mpc
Several academic papers regarding our protocol have been published since then. We wrote a full security proof of the crypto. We hired NCC group to audit the ceremony as well: https://z.cash/blog/ceremony-audit-results.html
More auditing can always be done but this is a continuing process. The primary goal is to make it difficult for someone to undetectably compromise the ceremony.
"I’ve had some experts tell me they thought the security level was 2^80 operations (very weak), while others (including Zooko himself) thought it was [more like 2^96](https://moderncrypto.org/mail-archive/curves/2016/000742.htm...). I’m not sure which figure is right, but the fact that there’s disagreement is a bad sign."
I made it very clear that it is an unsubstantiated figure, and linked to Zooko's analysis. To both yourself and the person you're replying too, please don't put words in my mouth.
> We provided participants with a reproducibly built and stripped down version of Alpine Linux, employed grsec, wrote all of our crypto software in pure Rust, etc. All of our software is reproducibly built, hashed and signed. There is nothing (software-wise) that cannot be caught in post-hoc review. All of it is open-source: https://github.com/zcash/mpc
I agree. But that's not what I said; what I said is that post-hoc review hasn't been done, even a year after the fact.
> To both yourself and the person you're replying too, please don't put words in my mouth.
What words did I put in your mouth? I cited the 2^80 figure in your blog post and a reasonable theory for why you would bring up such a figure. "Regurgitated" came across as snide so I apologize for that.
Note that you used this unsubstantiated figure to say "the fact that there’s disagreement is a bad sign." If there isn't actually any disagreement and the figure is unsubstantiated, why is it not baseless FUD? (BTW I notified you of this error in your blog post some time ago but never heard back.)
> what I said is that post-hoc review hasn't been done, even a year after the fact.
I know, I wasn't replying to you. As I said, I believe more auditing is needed. I also don't believe some kind of one-and-done audit of the software/deterministic builds would satisfy either of us.
> "Regurgitated" came across as snide so I apologize for that.
That's the thing, it didn't just come across as snide, it made it sound like I repeated the number uncritically, when in fact I made it clear to the reader where it came from and that there was disagreement.
> If there isn't actually any disagreement and the figure is unsubstantiated, why is it not baseless FUD?
The fact that competent experts could be unfamiliar with Zcash's crypto to the degree that they could disagree on basic facts like that is a sign of concern, precisely because it's yet another strong sign that the crypto is quite new. If this were "tried and tested" crypto, there wouldn't be any disagreement. Note that Zooko himself was unsure of the exact strength due to a recently found attack - tried and tested crypto wouldn't have recently found attacks.
> BTW I notified you of this error in your blog post some time ago but never heard back.
Where did you notify me? For that matter, who are you anyway? I probably know you by name from elsewhere; I don't by handle.
> I also don't believe some kind of one-and-done audit of the software/deterministic builds would satisfy either of us.
Well, I was just discussing the trusted setup with Matthew Green, and I think there's some fundamental disagreement on what kinds of vulnerabilities exist and what the risks of them are. So I really need to write a blog post on it.
I'm Sean from Zcash, I coordinated the MPC and wrote the software. I messaged you on twitter or emailed you or something about this last year.
> it made it sound like I repeated the number uncritically
I didn't say you regurgitated it. I said the person you talked to did, presumably after looking at libsnark or an unrelated paper.
> The fact that competent experts could be unfamiliar with Zcash's crypto to the degree that they could disagree on basic facts like that is a sign of concern, precisely because it's yet another strong sign that the crypto is quite new.
I claim the person you talked to was looking at the wrong curve construction. 2^80 is quite a torch to carry into an argument and no experts that we know have ever suggested a security level less than 2^96. The only "disagreements" about security were far more subtle and reasonable than what your blog post suggested.
This is one situation in which I think that using grsec is absolutely the wrong choice. Grsec mitigates a lot of kernel bugs, but it also adds bugs. More importantly, it isn't particularly well audited, and it is unlikely to have many eyeballs on it at all in the future, given it's not-really-open-source status.
In our case, the use of grsec was one of the simplest counter-measures that achieved an almost purely additive security improvement. That's even when accepting the risk that grsec has security bugs in it.
If the participant did everything right, one of the only remaining ways that the secrets could be exfiltrated from the machine was by exploiting a theoretical vulnerability in xorriso, the software we use to read/write DVDs for airgapped communication in the ceremony. Even then, it was likely to leave an evidence trail on the DVDs for post-hoc review.
As an extra precaution, we needed to impose strict policies on the xorriso process. Grsec was trivial to employ using off-the-shelf Alpine Linux tools, and didn't require any dependencies which would increase the cost of auditing afterward. Grsec was also not likely to introduce bugs we couldn't catch in post-hoc review due to the evidence trail left on the DVDs.
The hope was to force an adversary to exploit both xorriso and grsec in practice. One important question is: was grsec likely to introduce a category of bugs that would not otherwise exist in Linux already? I think the answer to that question is no. Funny enough, just a day or two before the ceremony the Dirty COW vulnerability was patched in the Linux kernel, and we just managed to update our OS before the scheduled ceremony.
What I said was those builds hadn't been properly audited; just being reproducible isn't enough unless people actually reproduce them, and additionally, audit the dependencies that go into those builds.
That's not an explanation. It's just an assertion they'd not do bad stuff, ignoring what he previously tweeted. Neither is his stuff about it being compatible with law enforcement. A real explanation would follow through the thought and say exactly how they can make zCash "too traceable for criminals".
Especially when Green has his own quote saying they're OK building backdoors for police.
Or maybe that is their entire plan. Say something slightly sketchy, knowing any real criminal will be too paranoid to trust it. Worked for me.
I want to rely on a cryptosystem which means that at a protocol level, the designers can't build in backdoors for police even if they want to. Then I don't have to worry about their public statements. Maybe they're firmly ideologically opposed today and get a court order tomorrow. (This is exactly what happened with well-intentioned scam artist Ladar Levison: he built a system that didn't have the cryptographic properties he promised, and the government called his bluff. He didn't particularly desire to help the government, but he had no choice.)
The question is, do we believe that there's room in the Zcash protocol for a cryptographic back door?
I am unable to judge zcash and must rely on other cues. So when the founders seem to be saying they're OK with backdoors, it makes me think hey, given the chance maybe there's something they could do.
Anyways once they get mandatory shielded transactions I'll look at it in more depth and see if I can get comfortable.
- Aren't zerocoin and zerocash two different currencies? Did you mean to say zerocash in your previous comment?
- If what Matt Green is saying is true, is there a way to create a backdoor in Monero or any other new crypto that comes along?
- One of the reservations that I have around z-cash is the "don't roll your own crypto" mantra even if you are an experienced, academic cryptographer? Is z-cash inherently more risky because its using newer crypto?
I know, but it's the history of the person I'm looking at. Monero could well have weaknesses. That's why I don't rely on it. In fact, I know it has weaknesses. Monero's problem is they do not adequately tell people how to use it safely. The marketing is all about how Monero is safe, not about its limitation. Dangerous game for them to play.
It's not about rolling own crypto. My understanding is that zcash is more risky due to the newer concepts involved.
This is all theoretical right now anyways. Without more support for shielded transactions, it isn't feasible to use zcash to clean Bitcoin or other cryptocurrencies. Exchange volumes of XMR-ZEC are also too small from what I can see to make stacking them useful.
That said, we are reconsidering things. We will probably add zcash as a payment method sometime this week.
Why start up world wide? Why not start only in jurisdictions where what you're doing is legal? Wouldn't that give yourselves an opportunity to build and test all the layers of your company in a relatively safe environment before moving into markets like the US?
Not starting worldwide. Launch city Toronto. There are essentially no jurisdictions where we'd be legal. Places that have legal sex work usually make surrounding activities legal. Places where it's fully legal have regulatory issues we wouldn't pass.
US targeted for mid-2018 after we have a few cities smoothly operating.
> I am unable to judge zcash and must rely on other cues. So when the founders seem to be saying they're OK with backdoors, it makes me think hey, given the chance maybe there's something they could do.
This approach is vulnerable to an easy attack: get government funding, design a cryptosystem with lots of backdoors, and proudly proclaim that you will never add one and you will absolutely stand up to the government.
I think you should find a better way to evaluate cryptosystems.
Ring signatures with small anonymity sets have very serious privacy drawbacks, but they have more sensible assumptions for protecting the monetary base integrity.
zk-SNARKs are the opposite: they don't compromise on privacy at all, but require stronger assumptions to protect the monetary base.
ZCash has unsolveable issues, Monero has solveable issues. I don't see that as a tradeoff.
zk-SNARKS have no privacy issues, but to trust ZCash you require absolute trust in the zcash ceremony. This is an issue for many, including me. This ceremony has happened, there is no way for me to prove to myself that the private keys were not stored somewhere. Although I can prove to myself it is decentralised and private, I can't see how I could ever prove to myself that noone can cheat and generate coins with minimal effort, thus devaluing mine. I just have to trust the founders.
Monero's Ring signatures require no trust, but they have privacy problems in the case of small rings. This is solveable by restricting to large rings (as a hard fork will enforce this September[1]), and at that point, I can see how to convince myself that the system is decentralised, private, and noone can generate coins without appropriate mining effort.
Zcash's zk-SNARKs are totally private even if that ceremony failed and even if the cryptographic assumptions underlying zk-SNARKs fall apart.
I find the comparison with Bitcoin perfect. The same people trusting PoW cartels to keep their system operational are complaining that zk-SNARKs require a parameter setup for proof soundness? That doesn't really make sense to me.
Zero-knowledge proofs for a given statement, by definition, reveal nothing about its witness. zk-SNARKs (used by Zcash) are statistically zero-knowledge; there are no cryptographic assumptions involved.
As a slight aside, I always wondered if zero-knowledge proofs really reveal "slight" knowledge.
That is, if I ask 1 billion questions about a resource, and get true, verifiable answers, can't I find out something about it? For example, some projection onto a linear subspace or something.
Just because certain platforms are popular doesn't really change things from a legal or a moral perspective, and it might be because of their editorial discretion that they are popular in the first place.