[ewillbefull]

> 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.

[petertodd]

What my blog actually said about that was:

"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.

[ewillbefull]

> 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.

[amluto]

> employed grsec

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.

[ewillbefull]

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.

[the_stc]

What is Peter referring to when he says there's no reproducible builds?

[petertodd]

I didn't say that.

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.